+

WO2013034865A1 - Procede d'authentification - Google Patents

Procede d'authentification Download PDF

Info

Publication number
WO2013034865A1
WO2013034865A1 PCT/FR2012/052009 FR2012052009W WO2013034865A1 WO 2013034865 A1 WO2013034865 A1 WO 2013034865A1 FR 2012052009 W FR2012052009 W FR 2012052009W WO 2013034865 A1 WO2013034865 A1 WO 2013034865A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
user
entity
authentication data
request
Prior art date
Application number
PCT/FR2012/052009
Other languages
English (en)
Inventor
Jean-Jacques Schwartzmann
Celia SCHUTZ
Original Assignee
France Telecom
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 filed Critical France Telecom
Priority to EP12767048.7A priority Critical patent/EP2754262A1/fr
Publication of WO2013034865A1 publication Critical patent/WO2013034865A1/fr

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

Definitions

  • the invention finds a particularly interesting application in securing access to computer systems based on a cloud computing architecture (the term usually used is the term "cloud computing").
  • cloud computing the term usually used is the term "cloud computing”
  • Such an architecture relies on dematerialized computer resources, made available to a large number of users who access them remotely and in an evolutionary manner. More and more companies are migrating their applications to such Cloud Computing environments.
  • these approaches in cloud computing are not without risk, since they rely mainly on the internet to work. It is therefore necessary in Cloud Computing offers to correctly address security issues such as access, data protection and transaction security.
  • so-called strong authentication solutions tends to develop when resources internal to the company, such as applications, files, are no longer exclusively held in the company, but stored in the database. outside and sometimes even shared.
  • authenticator for example, what the entity has such a physical element called authenticator (the term usually used is the term "token"), for example a smart card, or a mobile terminal,
  • the entity is, in the case of a user, a fingerprint or other biometric element.
  • authentication can also be based on something that the user holds, a physical element called a token. .
  • a token a physical element
  • OTP single-use passwords
  • a one-time password generated on a token held by the user and used in combination with the login / password to perform strong authentication.
  • Google Authenticator offered by Google TM, which allows a previously registered user to access services offered by Google using two-factor authentication.
  • This solution is presented in connection with FIG.
  • a pre-registration procedure has made it possible to configure a mobile phone 10 of a user (not shown) to generate a one-time password on demand and to configure a user account by means of a password. a login and a password.
  • a secret key K s shared with a server 1 1 and a one-time password generation application have been installed on the mobile phone 10.
  • an authentication request is transmitted by the user from his terminal 12 to the server 11.
  • this request includes a login and a password specific to the user.
  • the login and the word pass constitute the first factor of authentication. They correspond to something that the user knows.
  • the server 1 1 In a case where the data transmitted by the user in the authentication request is correct, that is to say in a case where the password is the one that is associated with the entered login, then in a next step Disposable password generation E1 1, the server 1 1 generates a one-time password by means of a cryptographic algorithm parameterized by the secret key K s specific to the mobile phone 10.
  • the server 1 1 sends the terminal 12 a request for OTP.
  • a verification step E16 the server 1 1 verifies that the one-time password received from the terminal 12 corresponds to the password it generated during the generation step E1 1. If the one-time passwords received and generated are identical, then the authentication has succeeded and the server 11 sends the terminal 12 a successful authentication message during a step E17. In the case where the passwords are identical, it means that the user is in possession of the mobile terminal suitable for generating one-time passwords according to "Google Authenticator".
  • the second authentication factor here is the possession of the mobile terminal 10 which has been previously configured to generate the same disposable password as that generated by the server 1 1. Thus, by checking the one-time password generated from the mobile phone 10, the server verifies that the mobile phone 10 is in the possession of the user.
  • SIM Subscriber Identity Module
  • Cryptographic SIM cards are crypto-processor cards that have capabilities to execute cryptographic algorithms other than the basic algorithms defined to access the network.
  • not all SIM cards have such capabilities and distributing such cards to all users would be expensive and would also take a lot of time.
  • the invention solves the disadvantages described above by providing an authentication method between a user having a first and second devices and a remote authentication entity, the method comprising:
  • the authentication method according to the invention is a strong authentication during which the user proves with a first authentication data that he knows something, in this case a login and a password and that he holds something, in this case a mobile terminal.
  • the proof of possession of the mobile terminal is difficult to contest in the sense that, since the second authentication data is transmitted from the telephone to a signaling channel of the mobile network, this transmission implies prior authentication of the SIM card by the network. and the transmission in the signaling of a mobile phone identifier, the MSISDN number. So, even if a malicious person stole the secret key installed on the mobile phone of the user, she could not prove that an authentication data generated on her own phone comes from the user's phone.
  • the method thus offers an advantage that is not offered by known solutions.
  • the authentication method offers a more secure solution than known solutions, which propose to transmit the second authentication data by the same channel used to transmit the first authentication data.
  • the second data is transmitted on a channel of the mobile network, different from the channel used to transmit the first data.
  • access to this channel is subject to network authentication.
  • the implementation of the authentication method does not require a heavy infrastructure. Indeed, when the process is operated by the mobile internet operator, it has the network infrastructure and information that allow easy implementation of the process. This information is for example the mobile subscription data and the Internet subscription data. Furthermore, the transmission infrastructure of the second authentication data, a signaling channel of the mobile network is also already existing.
  • the authentication method according to the invention is particularly suitable for cloud computing architecture offers. Indeed, such architectures allow users to access resources, sometimes sensitive, via the Internet. In order to gain the trust of users in such offers, it is important to display a good level of security. Strong authentication of the method object of the present invention meets this need.
  • the communication channel is in accordance with the USSD standard.
  • the USSD channel requires only basic GSM access and the services that use this channel are accessible from any mobile terminal, without adding specific code on the terminal.
  • the advantage of this channel is to be always available and very responsive. It is also generally associated with real-time telephony or instant messaging services.
  • the second authentication data is a one-time password.
  • the request for a second authentication data comprises a challenge.
  • This exemplary embodiment corresponds to asynchronous one-time passwords.
  • the request for a second authentication data item received from the authentication entity comprises a request for a one-time password.
  • This exemplary embodiment corresponds to synchronous single-use passwords.
  • the authentication method according to the invention comprises, prior to the generation step, a reading step during which the challenge displayed on the first device is scanned by the second device.
  • the method according to the invention comprises the following preliminary recording steps:
  • the invention also relates to a user entity comprising first and second user devices, the first device comprising:
  • reception means arranged to receive from the authentication entity a request for a second authentication data item, the second device comprising:
  • generation means arranged to generate on the second device the second authentication datum, following the step of receiving a request
  • the invention also relates to an authentication entity comprising a server and a portal, the server comprising:
  • means for receiving the second authentication data arranged to receive the second authentication data of a second user device via a communication channel of a cellular network
  • means for sending messages arranged to construct and send a message to the server, said message comprising the second authentication data received and an identifier of the user.
  • the invention also relates to an authentication system comprising:
  • FIG. 2 describes the steps of a strong authentication method according to an exemplary embodiment of the invention
  • FIG. 4 represents a user device implementing the steps of the method, according to an exemplary embodiment
  • the authentication method according to the invention described here is a strong authentication method.
  • a strong authentication is a procedure that requires the combination of at least two authentication factors, here something that a user knows, in this case a login and a password, and something that the user holds, an authenticator (the English term "token” is usually used), here a mobile phone.
  • the user will have to prove to a server that he knows his login and password, and that he owns the mobile phone he has previously declared as belonging to it and configured to implement the authentication procedure. This configuration is performed during a prior registration procedure described in detail in connection with FIG.
  • the user has a terminal 20, for example a terminal type "PC" (of the English “Personal Computer") and a mobile phone 21.
  • An authentication entity 22 comprises at least one server 22-1 and an "USSD >>22-2" portal (of the "Unstructured Supplementary Service Data") capable of implementing the USSD protocol.
  • the server 22-1 is intended to authenticate the user when the latter wishes to access from his terminal 20 via a network (not shown), for example the Internet, to a service to which he has previously subscribed.
  • a service to which the subscribed user is for example a messenger service, or an online betting service.
  • the mobile phone 21 and the server 22-1 share a secret key K s , specific to the mobile phone 21.
  • the key K s is installed on the mobile terminal 21.
  • the USSD 22-2 gate is adapted to receive from the telephone 21, via a channel of a mobile telecommunications network (not shown), for example the "GSM” network (for "Global System for Mobile Communications"), a USSD code comprising a one-time password generated by the mobile phone 21, and to retransmit the 22-1 server the one-time password in a language understandable by the server 22-1 and an identifier associated with the phone mobile 21 which sent the USSD code.
  • GSM Global System for Mobile Communications
  • the USSD channel is a basic feature of the GSM standard; it can convey information above the signaling channels of the GSM network, in the form of USSD codes.
  • the USSD channel requires only basic GSM access and the services that use this channel are accessible from any mobile terminal, without adding specific code on the terminal.
  • a USSD service is in the form of a USSD code.
  • the USSD service "# 123 #", offered by several mobile operators to allow access to monitoring consumption, prepaid account or not.
  • # 123 # code offered by several mobile operators to allow access to monitoring consumption, prepaid account or not.
  • the server 22-1 In a step E21 generating a challenge, the server 22-1 generates and stores a challenge in association with an identifier of the user.
  • the challenge is a random sequence of numbers, intended to be used when generating a one-time password, or "OTP" (one time password), or a one-time password. .
  • OTP one time password
  • the challenge size is preferably greater than 8 characters.
  • the user's identifier is for example a number "MSISDN” (for "Mobile Station ISDN Number”) which is the number of the telephone 21 "known to the public" thanks to which the user can be reached on his telephone. mobile 21, or / and an "IMEI" number (of the "International Mobile Equipment Identity >>) which uniquely identifies each of the mobile telephone terminals associated with the telephone 21.
  • MSISDN and IMEI numbers can be obtained by the 22-1 server during the registration process.
  • a password request step E22 the server 22-1 sends the terminal 20 a one-time password request.
  • the request comprises the challenge generated by the server 22-1 during the previous step E21.
  • the challenge is displayed on the screen of the terminal 20.
  • the generation of the password consists in applying an encryption algorithm, parameterized by the secret key K s shared with the server 22-1, to the challenge recovered during the previous step E24.
  • An example of an algorithm used for OTP generation is the HMAC-SHA1 algorithm (for "Hash-based Message Authentication Code - Secure Hash Algorithm").
  • the generated one-time passwords have a size of at least 6 characters.
  • a step E26 for sending the password the one-time password generated on the telephone 21 during the previous step E25 is sent to the authentication entity 22 on the USSD channel. More specifically, a USSD code is sent from the telephone 21 on the USSD channel.
  • the code specifies the USSD service concerned, in this case the sending of a password and it includes the password to send.
  • the USSD code is of the form " * # 151 # 981256 #", where the value "151" represents the service of sending a password, and "981256" the password of use unique generated during step E25. Since the USSD channel is a basic feature of the GSM network, the sending of the USSD code on this channel benefits from the authentication inherent to GSM network access. Thus, transmitting the code on the USSD channel is guaranteed that it is sent from a mobile phone whose SIM card has been authenticated.
  • the USSD code is received on the USSD signaling channel by the USSD 22-2 portal of the authentication entity 22.
  • the gate 22-2 extracts from the signaling message the word of passes, and constructs a new message including the password extracted and a user identifier of the telephone 21 he obtained in the USSD signaling.
  • the USSD 22-2 gate transmits this new message to the server 22-1.
  • This new message is for example transmitted using the HTTPS ("HyperText Transfer Protocol Secured") protocol; it is for example encoded in the "XML" format (of the English “Extensible Markup Language”), according to an interface previously defined between the USSD 22-2 portal and the server 22-1.
  • the phone identifier 21 is for example the number "MSISDN", possibly supplemented with the number "IMEI", transported in the signaling.
  • the exemplary embodiment describes the generation of an asynchronous single-use password, that is to say based on a challenge that is transmitted from the server to the telephone 21, via the terminal 20.
  • the invention It is not limited to the generation of asynchronous OTPs and in another embodiment a password is generated synchronously.
  • the server and the phone are synchronized by the current date or a counter, or by a combination of the current date and a counter.
  • the authentication request transmitted from the server to the terminal 20 during the step E22 is a predefined one-time password request that does not include a challenge.
  • the recovery step of the challenge E24 is therefore not executed, as is the step E21 for generating the challenge by the server 22-1.
  • the password is generated when the generation application is triggered on the telephone 21 during the triggering step E23.
  • the service is accessible from the server 22-1.
  • the server 22-1 is dedicated to the authentication of the user, the service as such being offered by another server (not shown) dedicated to the service.
  • a method for registering the user will now be described in relation to FIG. 3. Such a registration is necessary for a subsequent implementation of the authentication method according to the invention. Indeed, such a record is intended to distribute a material to the user, necessary for the generation of one-time passwords that will be used to access a service / to which / to which the user has subscribed. Specifically this registration step will install on the phone 21 of the user's secret key Ks shared with the server 22-1, which will be used when generating passwords for single use. It is assumed that the password generation application is already installed on the phone. Such an installation can be done by downloading on the telephone 21, by sending "SMS" (short message service) containing the application, or when the application is intended to be installed on the SIM, according to an "OTA" (over the air) procedure.
  • SMS short message service
  • the user enters his login and password on his terminal 20 and sends these two data to the server 22-1.
  • the login and the password correspond to subscription data of the user's mobile Internet account associated with his telephone 21.
  • a verification request step E303 the server 22-1 transmits the two data to the identity server 23.
  • the identity server 23 verifies the login and the password of the user and if successful, transmits to the server 22-1 in a step E304 of the result of the verification a message of success of the authentication.
  • the server 22-1 requests the identity server 23 for the MSISDN telephone number associated with the user's account, and possibly the associated IMEI identification number.
  • a step E308 of generating a challenge the server 22-1 generates a challenge for the current procedure for registering the user. This challenge is stored in association with the MSISDN number of the phone 21 of the user.
  • the server 22-1 sends the derived key K s to the terminal 20.
  • the secret key is transmitted securely to the terminal 20.
  • the key is transmitted encrypted to the terminal 20 by means of a session key negotiated prior to sending.
  • the key secret is transmitted in an HTTPS session.
  • the secret key K s is transmitted to the user by mail.
  • a challenge sending step E310 the server 22-1 sends the terminal 20 the challenge generated during the step E308 for generating a challenge.
  • the user installs the secret key K s on the telephone 21.
  • the user scans the value of the secret key K s displayed on the screen of the terminal 20 for example in the form of a flashcode and saves it on the telephone 21.
  • access to the key K s is protected, for example by means of a PIN code for unlocking (for "Personal Identification Number").
  • an application triggering step E312 the user triggers the execution of an application previously installed on the telephone 21 and intended to generate a one-time password.
  • This application can be downloaded from the phone 21. In an alternative embodiment, it can be sent to the telephone for example in the form of one or more short messages (the term "SMS is usually used).
  • a next step E313 of entering the challenge the user scans the value of the challenge displayed on the screen of the terminal 20, for example in the form of a flashcode, by means of his telephone 21. In another embodiment, he enters the value of the challenge on the keypad of his telephone 21.
  • This input step E313 is executed as part of the application triggered during the previous step E312.
  • a one-time password is generated on the phone 21.
  • the generation step E314 is executed as part of the application triggered during step E312.
  • the generation consists in applying to the challenge obtained during the step E313 of input an encryption algorithm parameterized by the secret key K s .
  • the terminal 21 sends the authentication entity 22 a USSD code comprising the password generated during the step E314. More precisely, the USSD code is sent on the USSD channel.
  • the secret key K s is installed on the telephone during step E31 1 by scanning the key displayed with the telephone 21.
  • the invention is not limited to this example.
  • the user enters the value of the secret key K s on the keypad of his telephone 21 and records it on the telephone 21.
  • a Bluetooth link is established between the terminal 20 and the telephone 21, and the secret key is transmitted from the terminal 20 to the telephone 21 via this link.
  • the challenge transmitted during the step E310 can also be transmitted from the terminal 20 to the telephone 21 via this link.
  • the first device 20 also comprises:
  • the authentication entity 22 comprises a server 22-1, and a USSD 22-2 portal. These two entities cooperate to implement, on the network side, the authentication and registration methods described above.
  • the server 22-1 conventionally comprises:
  • sending means 22-23 arranged to construct and send to the server 22-1 a message comprising the second authentication data received via the communication channel of the cellular network, as well as an identifier of the user, such as than the MSISDN number.
  • the first and second receiving means 22-12, 22-14, the sending means 22-13 of the server 22-1, and the receiving means 22-22, the sending means 22-23 of the gateway 22- 2 are preferably software modules comprising software instructions for executing some of the steps of the authentication and recording methods described above.

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 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 « 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 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 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 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 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 Google™, 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 1 1 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 1 1 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 1 1 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 1 1 . 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 E1 1 de génération de mot de passe jetable, le serveur 1 1 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 1 1 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 1 1 au cours de l'étape E1 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 1 1 par le terminal 12. Dans une étape E16 de vérification, le serveur 1 1 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 E1 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 1 1 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 1 1 . 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 œuvre 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 œuvre 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 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 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 œuvre les étapes du procédé, selon un exemple de réalisation ;
- la figure 5 représente une entité d'authentification mettant en œuvre 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 œuvre 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 œuvre 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 Télécommunications 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 œuvre 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 œuvre 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 E31 1 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 E31 1 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 œuvre 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 œuvre, 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 œuvre 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 Ks 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 21 1 , 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 œuvre 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 œuvre 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 22- 2. Ces deux entités coopèrent pour mettre en œuvre, 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-1 1 , 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.

Claims

REVENDICATIONS
1 . 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. Procédé d'authentification selon la revendication 1 , dans lequel le canal de communication est conforme à la norme USSD.
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. 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. 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. 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. 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 (Ks) 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. 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. 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. 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.
1 1 . 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 un message au serveur, ledit message comprenant la deuxième donnée d'authentification reçue et un identifiant de l'utilisateur.
12. Système d'authentification comprenant :
- au moins une entité utilisateur selon la revendication 9 ou la revendication 10, et
- une entité d'authentification selon la revendication 1 1 .
PCT/FR2012/052009 2011-09-08 2012-09-07 Procede d'authentification WO2013034865A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP12767048.7A EP2754262A1 (fr) 2011-09-08 2012-09-07 Procede d'authentification

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO2013034865A1 true WO2013034865A1 (fr) 2013-03-14

Family

ID=46968277

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/052009 WO2013034865A1 (fr) 2011-09-08 2012-09-07 Procede d'authentification

Country Status (3)

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

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3013475A1 (fr) * 2013-11-19 2015-05-22 Oberthur Technologies Procede et dispositifs d'authentification pour acceder a un compte utilisateur d'un service sur un reseau de donnees
CN105474600A (zh) * 2013-03-15 2016-04-06 谷歌技术控股有限责任公司 使用链接到存储所需密码的另一个通信装置的通信装置来访问基于云的服务
US20220166769A1 (en) * 2020-11-25 2022-05-26 Samsung Electronics Co., Ltd. Electronic device for verifying a user's identity
US11627463B2 (en) * 2019-08-09 2023-04-11 Critical Ideas, Inc. Authentication via unstructured supplementary service data

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 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105474600A (zh) * 2013-03-15 2016-04-06 谷歌技术控股有限责任公司 使用链接到存储所需密码的另一个通信装置的通信装置来访问基于云的服务
US10284493B2 (en) * 2013-03-15 2019-05-07 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
US10623332B2 (en) 2013-03-15 2020-04-14 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
CN105474600B (zh) * 2013-03-15 2020-06-30 谷歌技术控股有限责任公司 用于访问基于云的服务的方法、通信装置和存储介质
FR3013475A1 (fr) * 2013-11-19 2015-05-22 Oberthur Technologies Procede et dispositifs d'authentification pour acceder a un compte utilisateur d'un service sur un reseau de donnees
US9633221B2 (en) 2013-11-19 2017-04-25 Oberthur Technologies Authentication method and devices for accessing a user account of a service on a data network
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
US12355761B2 (en) * 2020-11-25 2025-07-08 Samsung Electronics Co., Ltd. Electronic device for verifying a user's identity

Also Published As

Publication number Publication date
EP2754262A1 (fr) 2014-07-16
FR2980063A1 (fr) 2013-03-15

Similar Documents

Publication Publication Date Title
EP2220840B1 (fr) Procédé d'authentification d'utilisateurs dans des systèmes de traitement de données
US20180295121A1 (en) Secure element authentication
US9338163B2 (en) Method using a single authentication device to authenticate a user to a service provider among a plurality of service providers and device for performing such a method
EP1502383B1 (fr) Procede d'autentification et de verification de communications par sms
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
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
US20050138365A1 (en) Mobile device and method for providing certificate based cryptography
EP2023262A2 (fr) Système d'authentification et son procédé
US11777743B2 (en) Method for securely providing a personalized electronic identity on a terminal
EP2567502A2 (fr) Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
CN109145628B (zh) 一种基于可信执行环境的数据采集方法及系统
EP2509025A1 (fr) Procédé d'accès à une ressource protégée d'un dispositif personnel sécurisé
WO2013034865A1 (fr) Procede d'authentification
WO2003107587A1 (fr) Procede et dispositif d’interface pour echanger de maniere protegee des donnees de contenu en ligne
JP7079528B2 (ja) サービス提供システム及びサービス提供方法
EP3673633B1 (fr) Procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification
EP3899765B1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
WO2008081150A2 (fr) Procede et systeme d'autorisation d'acces a un serveur
WO2016156737A1 (fr) Procede d'obtention d'une liste d'au moins une donnee sensible
WO2012022856A1 (fr) Procédé d'authentification d' un utilisateur du réseau internet
Suganya et al. Secure user authentication using biometrics in mobile banking
EP2630746B1 (fr) Procede et systeme d'authentification
WO2025109113A1 (fr) Procédés, dispositifs et système de transmission et d'acquisition d'une donnée
EP3503500A1 (fr) Procédé pour créer une signature électronique à distance au moyen du protocole fido
HK1078708B (en) Method for authenticating and verifying sms communications

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12767048

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2012767048

Country of ref document: EP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载