WO2013034865A1

WO2013034865A1 - Authentication method

Info

Publication number: WO2013034865A1
Application number: PCT/FR2012/052009
Authority: WO
Inventors: Jean-Jacques Schwartzmann; Celia SCHUTZ
Original assignee: France Telecom
Priority date: 2011-09-08
Filing date: 2012-09-07
Publication date: 2013-03-14
Also published as: FR2980063A1; EP2754262A1

Abstract

The invention concerns an authentication method for authenticating between a user having a first and second device (20, 21) and a remote authentication entity (22), said method comprising: a step (E20) of sending, from the first device, at least a first piece of user authentication data to the authentication entity, a step (E22) of receiving, by the first device, a request for a second piece of authentication data coming from the authentication entity, a step (E25) of generating, on the second device, the second piece of authentication data, subsequent to the step of receiving a request, a step (E26) of sending, to the authentication entity, by the second device, the second piece of authentication data generated, via a communication channel of a cellular network.

Description

Authentication method

The invention relates to a method for authenticating a user when accessing personal or professional data via the Internet. More specifically, the invention relates to strong authentication of the user, or two-factor authentication.

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"). 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. However, 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. Thus, the use of 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.

Strong authentication consists of an identification procedure that requires the concatenation of at least two authentication elements or factors. The goal of strong authentication is to overcome the weaknesses of password-based single sign-on, which no longer provides the level of security required to protect sensitive IT assets. The main weakness of a password lies in the ease with which it can be found, thanks to different attack techniques, for example a brute force attack or dictionary. Strong authentication consists of mixing two different authentication strategies. Only the combination of these elements or factors supposed inviolable is then supposed to ensure real strength for authentication. To perform strong authentication, the factors used must come from two different authentication classes, including:

what the entity to be authenticated knows, a password 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,

- that the entity is, in the case of a user, a fingerprint or other biometric element.

Thus, to ensure strong multi-factor authentication, in addition to the classic login / password pair that represents what the user knows, authentication can also be based on something that the user holds, a physical element called a token. . We are particularly interested in single-use passwords, or "OTP" (or "One Time Password"), or a one-time password generated on a token held by the user and used in combination with the login / password to perform strong authentication. By providing a valid OTP password generated by a token held by the user, it proves that it owns the said token.

A known example of a strong authentication flow is illustrated by the solution

"Google Authenticator" offered by Google ™, 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. During this registration procedure 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.

Thus, the user has a mobile phone 10 adapted to generate and transmit to the server 1 1 a validation code, in this case a one-time password, necessary for the authentication of the user, and a terminal 12 of type "PC" (of the English "Personal Computer"), adapted to access Internet services such as messaging, etc., and subject to access control. The server 1 1 is adapted to authenticate the user according to the "Google Authenticator" solution and thus allow access to a required service when the authentication has succeeded.

During user access to a service, during a first authentication request step E10, an authentication request is transmitted by the user from his terminal 12 to the server 11. For example, 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. 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. In a request step E12 of OTP, the server 1 1 sends the terminal 12 a request for OTP. In a next generation step E13, the user triggers the generation of a one-time password on his mobile phone 10. For this purpose, the user triggers the application previously installed on his telephone 10 and intended to calculate and displaying a one-time password on the screen of his telephone 10. The application for calculating one-time passwords consists of the same cryptographic algorithm that the one used by the server 1 1 during the step E1 1, parameterized by the secret key K _s . In a subsequent step E14 input OTP, the user enters on the keyboard of his terminal 12 the password generated and displayed on the screen of his mobile phone 10. In a step E15 OTP sending, the one-time password is sent to the server 1 1 by the terminal 12. In 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.

However, in this example, proof of possession of the mobile phone 10 is questionable. Indeed, the secret key K _s used by the mobile phone 10 during the generation of the one-time password can be stolen by a malicious person and installed on another mobile phone or other equipment, so as to generate a word one-time password from that other phone or equipment. Thus, if the malicious person succeeds in obtaining the login and word password of the legitimate user, she can access the account of the legitimate user. It is thus not guaranteed with this method that the password has been generated by the mobile phone of the user.

In order to overcome this security problem, an obvious improvement of this method would be to use a cryptographic "SIM" card (of the English "Subscriber Identity Module") on the mobile terminal and to install the secret key K _s shared by the phone and the server and used to generate the one-time passwords in a protected area of the SIM card, not accessible for reading. Cryptographic SIM cards are crypto-processor cards that have capabilities to execute cryptographic algorithms other than the basic algorithms defined to access the network. However, 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:

a step of sending from the first device at least a first authentication data of the user to the authentication entity,

a step of reception by the first device of a request for a second authentication data item from the authentication entity,

a generation step on the second device of the second authentication data, subsequent to the step of receiving a request,

- A step of sending to the authentication entity by the second device of the second authentication data generated via a communication channel of a cellular network.

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. Here, 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.

Moreover, 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. Indeed, the second data is transmitted on a channel of the mobile network, different from the channel used to transmit the first data. In addition, access to this channel is subject to network authentication.

Moreover, 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.

According to an exemplary embodiment, 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.

In an exemplary embodiment, the second authentication data is a one-time password.

It is known that one-time passwords are only valid once and are only valid for a short time. This makes this type of data a non-critical data that can be transmitted over an unsecured channel, such as the USSD channel.

In an exemplary embodiment, the request for a second authentication data comprises a challenge.

This exemplary embodiment corresponds to asynchronous one-time passwords.

In another exemplary embodiment, 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.

Advantageously, 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 embodiment of scanning the challenge displayed on the screen of the terminal with the mobile phone avoids the user manual entry, which simplifies the use of the authentication service. Thus, the user only has to launch the generation application on his phone, once the challenge scanned. In addition, this avoids possible input errors.

The method according to the invention comprises the following preliminary recording steps:

a step of sending from the first device of the first authentication data of the user to the authentication entity,

a step of receiving the authentication entity of a secret key generated from at least user identification data, and installing said key on the second device,

a step of reception by the first device of a request for a new second authentication data, originating from the authentication entity,

a generation step on the second device of the new second authentication data, subsequent to the step of receiving the request,

- A step of sending to the authentication entity by the second device of the new second authentication data generated via a communication channel of a cellular network.

The registration phase is quite similar to the authentication process and therefore simple for the user. This phase allows to distribute to the user the key secret for the generation of the second authentication data and this distribution is confirmed during the registration phase by sending a new second authentication data that uses, for its generation secret key newly transmitted.

In an exemplary embodiment, the authentication method according to the invention further comprises:

a step of receiving the second authentication data sent via the communication channel of the cellular network by a portal of the authentication entity, and

a step of sending by the portal to a server a message comprising said second authentication data and a user identifier obtained from the signaling of the cellular network.

The invention also relates to a user entity comprising first and second user devices, the first device comprising:

sending means, arranged to send at least a first authentication data of the user to the authentication entity,

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,

means for sending, arranged to send the authentication entity the second authentication data generated via a communication channel of a cellular network.

According to an exemplary embodiment of the user entity, the second device further comprises reading means, arranged to scan a challenge displayed on the first device.

The invention also relates to an authentication entity comprising a server and a portal, the server comprising:

first reception means, arranged to receive a first authentication data from a first user device,

means for sending a request, arranged to send a request for a second authentication data, second reception means, arranged to receive a message comprising the second authentication data and an identifier of the user, the portal 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:

at least one user entity according to the invention, and

an authentication entity according to the invention.

Other characteristics and advantages of the present invention will appear on reading the following detailed description, and the appended drawings among which:

- Figure 1, already commented, describes the steps of a known strong authentication method, called "Google Authenticator";

FIG. 2 describes the steps of a strong authentication method according to an exemplary embodiment of the invention;

FIG. 3 describes the steps of a recording 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;

FIG. 5 represents an authentication entity implementing the steps of the authentication method, according to an exemplary embodiment.

An authentication method according to the invention will now be described in relation to FIG. 2.

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 (not shown) 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. In this embodiment, 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. 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. For example, we know the USSD service "# 123 #", offered by several mobile operators to allow access to monitoring consumption, prepaid account or not. When a user enters and sends the # 123 # code on the network from their mobile phone, the consumer tracking information is displayed back on their phone screen.

In an initial access request step E20, the user sends the server 22-1 from its terminal 20 an authentication request that includes at least a first authentication data item. For example, the authentication request includes a login name of the user (the term commonly used is the term "login") and a password, specific to the user. This first authentication data, in this case the login pair, password, is the first factor of the authentication method according to the invention. This factor represents something that the user knows. Of course, it is assumed here that the first authentication data is correct, that is to say that the login corresponds to a login account of the user previously created, and that the password is the one that validates access to this account. Thus, it is assumed that a verification of this first data performed by the server 22-1 at the end of step E20 is positive.

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. . For security reasons, and especially to guarantee the uniqueness of the challenges, 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. The MSISDN and IMEI numbers can be obtained by the 22-1 server during the registration process.

In a password request step E22, the server 22-1 sends the terminal 20 a one-time password request. In this exemplary embodiment, the request comprises the challenge generated by the server 22-1 during the previous step E21. Thus, at the end of step E22, the challenge is displayed on the screen of the terminal 20.

In an application triggering step E23, the user triggers the execution of an application previously installed on the telephone 21 and intended to generate the one-time password.

In a next challenge recovery step E24, executed as part of the application triggered in the previous step, the user scans the challenge displayed on the screen of his terminal 20 by means of his mobile phone 21. In another exemplary embodiment, the user manually enters the challenge displayed on the screen of his terminal on the keypad of his telephone 21. This step E24 recovery challenge is intended to have the challenge received by the terminal 20 on the mobile phone 21. In a step E25 of generating password on the telephone side, following steps E23 and E24, a one-time password is generated on the mobile phone 21. The step E25 of generation of password is executed within the framework of the application triggered during the step E23. In an exemplary embodiment, the generation step is executed automatically after having scanned the challenge during step E24. In another embodiment, it is executed on command of the user, after having scanned the challenge. 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"). In this embodiment, the generated one-time passwords have a size of at least 6 characters.

In 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. For example 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.

In a receiving and retransmitting step E27, 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.

In a server-side password generation step E28, the server 22-1 generates the one-time password from the challenge that it itself generated and stored during the generation step E21. challenge. Of course, the server 22-1 uses the same password generation algorithm that the one used by the telephone 21 during the step E25, parameterized by the secret key K _s that it shares with the telephone 21.

In a verification step E29, the server 22-1 verifies that the one-time password received from the telephone 21 via the USSD 22-2 gate is equal to the password it generated during the step previous E28. If so, the user authentication was successful. The one-time password constitutes the second factor of the authentication according to the invention. Thus, the method according to the invention performs a strong authentication of the user, based on the verification of two combined factors: the knowledge by the user of a login and a password, and the proof of possession of the user. phone 21. Indeed, with regard to the latter, the USSD code which contains the expected one-time password is transmitted from the telephone 21 via a channel of the GSM network and the password is thus associated with an identifier of the user by an entity independent of the user, in this case the USSD portal. This provides increased security since a malicious person can not modify this information himself to pretend to be the legitimate user.

If the verification performed in step E29 is positive, the server 22-1 sends the terminal 20 a message indicating that the authentication was successful during a confirmation step E30. The user can then access the service for which he needed access.

Here, the proof of possession of the phone is less questionable than if the password, once generated on the mobile phone had been entered on the keyboard of the terminal 20 of the user. Indeed, the sending of the password via the USSD channel assumes a GSM authentication between the SIM card inserted in the terminal and the network, as well as the transmission via the signaling of at least one identifier of the user's telephone. Thus, the USSD 22-2 portal that receives the OTP is sure that it has been generated on a terminal that includes the user's SIM card. A priori it is therefore the user's terminal. With the sending of this OTP by the phone, it is proved that the user is in possession of the phone. 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. Of course, the invention It is not limited to the generation of asynchronous OTPs and in another embodiment a password is generated synchronously. It is known that in the case of synchronous OTPs, 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. In this exemplary embodiment, 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. In this case, the password is generated when the generation application is triggered on the telephone 21 during the triggering step E23.

In the exemplary embodiment described here, it is assumed that the service is accessible from the server 22-1. Of course, the invention is not limited to this example and in another embodiment, 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.

The invention is described here with access via the GSM network. The invention is not limited to this network since the USSD channel is also accessible from the "GPRS" (for "General Packet Radio Service") or "UMTS" (for "Universal Mobile Telecommunications System") networks. . Thus, the invention also applies to these networks.

In the exemplary embodiment described here, the secret key K _s shared with the server 22-1 is installed on the mobile telephone 21. In another embodiment, the secret key is installed on the SIM card of the telephone 21, in a non-readable zone. In this case, the security of the process is increased since it then becomes impossible for an ill-intentioned person to steal the secret key K _s . In an exemplary embodiment, the code instructions that implement the authentication method according to the invention on the telephone 21 are in the form of an applet installed in the SIM card and executed by the SIM card. It is understood that this embodiment is more advantageous in terms of security.

In the embodiment described here, the challenge is entered on the telephone 21 during the recovery step E24 by scanning the value displayed on the terminal 20 by means of the telephone 21. The invention is not limited to this example. In a second exemplary embodiment, the user enters the value of the challenge on the keypad of his telephone 21. In a third exemplary embodiment, a Bluetooth link is established between the terminal 20 and the telephone 21, and the challenge is transmitted from the terminal 20 to the telephone 21 via this link. The use of a Bluetooth link increases the security of the authentication method because it ensures that the terminal 20 is always used in association with the telephone 21 of the user.

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.

In this embodiment, it is assumed that the user has a subscription to a mobile network operator (not shown) for its mobile and Internet access. The operator therefore has subscription data to a mobile account of the user, such as a MSISDN number and an IMEI number. It also has as a data access to the Internet a login / password that allow the user to also access his mobile account from the internet. This data is managed by the operator for all the subscribed users by means of an identity server 23. Of course, if the user has several mobile terminals, he accesses several mobile accounts and has a login for each one. / password and associated MSISDN and IMEI IDs. It is assumed here that the operator also manages the authentication entity 22.

When a user subscribes to the authentication service according to the invention, he sends in a subscription request step E300, a subscription request from his terminal 20 to the server 22-1. In an authentication request step E301, the server 22-1 sends the terminal 20 an authentication request. Typically, the request includes a login and password request.

In an input step E302, 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.

In 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.

In a data request step E305, 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.

In a response step E306, the identity server 23 sends to the server

22-1 the MSISDN number and possibly the IMEI number of the user.

In a step E307 for generating a key, the server 22-1 generates a secret key K _s on behalf of the user, more specifically for the mobile phone 21 of the user. This secret key is obtained by derivation of a master key K _M by means of a key derivation algorithm. This algorithm, parameterized by the master key K _M , is applied to at least one identifier of the telephone 21 of the user, for example the number MSISDN, and possibly to the number IMEI. The key derivation is assumed to be known to those skilled in the art and will not be detailed here. The server 22-1 stores the secret secret key K _s in association with the MSISDN number and possibly the IMEI number specific to the telephone 21 of the user. Using the IMEI number for the key derivation makes it possible to associate the secret key K _s also with the telephone 21 as a device.

In 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.

In a step E309 for sending the secret key, the server 22-1 sends the derived key K _s to the terminal 20. The secret key is transmitted securely to the terminal 20. In an embodiment, the key is transmitted encrypted to the terminal 20 by means of a session key negotiated prior to sending. For example, the key secret is transmitted in an HTTPS session. In another embodiment, the secret key K _s is transmitted to the user by mail.

In a challenge sending step E310, the server 22-1 sends the terminal 20 the challenge generated during the step E308 for generating a challenge.

In an installation step E31 1, the user installs the secret key K _s on the telephone 21. In an exemplary embodiment, 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. In an exemplary embodiment, access to the key K _s is protected, for example by means of a PIN code for unlocking (for "Personal Identification Number").

In 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).

In 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.

In a step E314 generation of password by the phone, following the steps E312 and E313, 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 .

In a sending step E315, 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.

In a receiving and retransmitting step E316, the USSD code is received by the USSD 22-2 gate. The one-time password is extracted from the USSD code and then sent to the server 22-1 by the USSD 22-2 portal, in association with an identifier of the telephone 21, for example the MSISDN number and possibly the IMEI number. The MSISDN number is retrieved by the USSD 22-1 portal in the USSD signaling. The message is for example an HTTPS request.

In a step E317 for generating a password by the server, the server 22-1 generates a one-time password from the challenge that it generated during the step E308. For this purpose, the server applies the same encryption algorithm as that applied by the telephone 21 during the step E314, parameterized by the secret key K _s .

In a verification step E318, the password generated during step E316 is compared with the password received by server 22-1 during step E315.

If the passwords are the same, then this means that the registration procedure was successful. This means that the secret key K _s has been correctly installed on the telephone 22 and that the generation of password has been done correctly. In this case, the server 22-1 sends the terminal 20 in a confirmation step E319 a message indicating that the subscription to the authentication service has succeeded.

Once the authentication service registration procedure has been performed, the user who wishes to access a service whose access is conditioned by a strong authentication according to the invention performs the steps of the authentication method described in connection with the figure 2.

In the example described here, 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. In a second exemplary embodiment, 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. In a third exemplary embodiment, 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.

In another embodiment, the secret key K _s and the application for generating one-time passwords are installed on the SIM card during the recording phase. Such an installation can be performed according to an OTA procedure, implemented by the mobile operator.

A user entity according to the invention will now be described in relation to FIG. 4. The user entity 40 comprises two devices: a PC type computer 20 as the first device and a mobile phone 21 as the second device. These two devices are used together to implement, on the user side, the authentication and registration methods described above.

In a conventional manner, the computer 20 comprises:

a processing unit 200,

a set of memory, including a volatile memory 201, or "RAM" (for "Random Access Memory") used to execute code instructions, store variables, etc.,

a screen 202, adapted to display data, for example an authentication request and a challenge received from the remote authentication entity 22 (not shown in FIG. 4). The challenge is received in a request for a second authentication data,

a keyboard 203, adapted to enter data, for example a first authentication data comprising for example a login and a password.

The first device 20 also comprises:

sending means 204, arranged to send at least the first authentication data of the user to the authentication entity 22. The sending means 204 are arranged to implement the request step E20 of the authentication method described above, and the subscription request steps E300 and E302 for entering the registration method previously described,

reception means 205, arranged to receive from the authentication entity 22 a request for a second authentication data item and a message indicating that the authentication has been successful. The reception means 205 are also arranged to receive the secret key K _s sent by the authentication entity during the registration procedure, as well as a message indicating that the subscription has proceeded correctly.

In a conventional manner, the mobile telephone 21, as the second device comprises:

a processing unit 210,

a set of memory, including a volatile memory 21 1, or RAM used to execute code instructions, store variables, etc., The second device 21 also includes:

input means 212, arranged to recover the challenge displayed on the screen of the terminal 20. In an exemplary embodiment, the input means comprise an application for scanning the challenge displayed on the screen. In another exemplary embodiment in which the challenge is entered manually by the user, the input means consist of the keypad of the telephone 21,

generation means 213, arranged to generate the second authentication data. The generation means 213 are arranged to implement the password generation step E25 of the authentication method previously described, as well as the step E314 for generating the password of the recording method previously described,

sending means 214, arranged to send to the authentication entity 22 via the USSD channel of a cellular network the second authentication data generated. The sending means 214 are arranged to implement the step E26 for sending the password of the authentication method previously described, as well as the sending step E315 of the recording method previously described.

The sending means 204 and the receiving means 205 of the first device 20, and the inputting means 212, generation 213 and sending 214 of the second device 21 are preferably software modules comprising software instructions for executing certain steps of authentication and registration methods described above.

An authentication entity according to the invention will now be described in relation to FIG.

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:

a processing unit 22-10,

a set of memory, including a volatile memory 22-1 1, or RAM used to execute code instructions, store variables, etc., The server also includes: first reception means 22-12, arranged to receive a first authentication datum of the first user device 20 (not shown in FIG. 5),

sending means 22-13, arranged to send to the first user device 20 a request for a second authentication data item,

- Second receiving means 22-14, arranged to receive the second authentication data, and an identifier of the user.

Gate 22-2 conventionally includes:

a processing unit 22-20,

a set of memory, including a volatile memory 22-21, or RAM used to execute code instructions, store variables, etc. Portal 22-2 also includes:

- Reception means 22-22, arranged to receive the second user device 21 (not shown in Figure 5) via a communication channel of the cellular network the second authentication data of a message. The channel is for example the USSD channel,

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.

Claims

1. An authentication method between a user having a first and a second device (20, 21) and a remote authentication entity (22), the method comprising:

a step (E20) of sending from the first device at least a first authentication data of the user to the authentication entity,

a step (E22) of reception by the first device of a request for a second authentication data item from the authentication entity,

a step (E25) of generation on the second device of the second authentication datum, following the step of receiving a request,

- A step (E26) of sending to the authentication entity by the second device of the second authentication data generated via a communication channel of a cellular network.

2. Authentication method according to claim 1, wherein the communication channel is in accordance with the USSD standard.

3. Authentication method according to claim 1, wherein the second authentication data is a one-time password.

4. Authentication method according to claim 1, wherein the request for a second authentication data comprises a challenge.

The authentication method of claim 1, wherein the request for a second authentication data item received from the authentication entity comprises a one-time password request.

6. Authentication method according to claim 4, comprising, prior to the generation step, a reading step (E24) during which the challenge displayed on the first device is scanned by the second device.

The authentication method according to claim 1, comprising the following preliminary registration steps: a step of sending (E302) from the first device of the first authentication data of the user to the authentication entity,

a step of receiving (E309) the authentication entity of a secret key (K _s ) generated from at least user identification data, and installing said key on the second device,

a step of reception (E310) by the first device of a request for a new second authentication data, originating from the authentication entity,

a generation step (E314) on the second device of the new second authentication data, following the step of receiving the request,

- A step of sending (E315) to the authentication entity by the second device of the new second authentication data generated via a communication channel of a cellular network.

The authentication method according to claim 1, further comprising:

a step of receiving the second authentication data sent via the communication channel of the cellular network by a portal (22-1) of the authentication entity (22),

User entity (40) comprising first and second user devices (20, 21),

the first device (20) comprising:

sending means (204), arranged to send at least a first authentication data of the user to an authentication entity,

reception means (205), arranged to receive from the authentication entity a request for a second authentication data item, the second device (21) comprising:

generation means (213), arranged to generate on the second device the second authentication data, following the step of receiving a request, sending means (214), arranged to send the authentication entity the second authentication data generated via a communication channel of a cellular network.

10. User entity according to claim 9, wherein the second device further comprises reading means (212), arranged to scan a challenge displayed on the first device.

1 1. Authentication entity (22) comprising a server (22-1) and a portal (22-

2)

the server (22-1) comprising:

first receiving means (22-12), arranged to receive a first authentication data from a first user device,

means (22-13) for sending a request, arranged to send a request for a second authentication data,

second reception means (22-14), arranged to receive a message comprising the second authentication data and an identifier of the user,

the portal (22-2) comprising:

means (22-22) 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 (22-23) 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.

12. Authentication system comprising:

at least one user entity according to claim 9 or claim 10, and

an authentication entity according to claim 1 1.