Method for authentication and signature of a user in an application service using a mobile telephone as a second factor in addition to and independently from a first factor

Translation of description of equivalent WO 2009112693 A2

p0001Auttientification process and signing of a user from an application service using a mobile phone as a second factor in addition to and independently of a first factor

p0002The present invention relates to a method for using a mobile phone to authenticate a strong way of user to a service application and to digitally sign a transaction with the application service.

p0003Exemplary be taken in the following description if the application service is a remote banking service, but it must be understood that this example is by no means limiting, and any other application service accessed by a user may be secured using the method according to the invention.

p0004In the current state of the art, auttientification a user from an application service is performed using a single factor autiTentification, typically consisting of a password (or PIN ) assigned by the application service to the user after its registration with the service. At this point, the user can therefore authenticate to the application service providing his user ID and password code.

p0005The communication password to application service is supposed to demonstrate that is well attended by the legitimate user.

p0006But we know that it remains a low autiientification for several reasons:

p0007- The password is necessarily short enough to allow the user to memorize

p0008- If more, the user is free to choose his own password, it often knows he made a simple choice, that is to say, relatively easy to guess

p0009- Such an authentication process is finally vulnerable to attack by "spyware" (Spyware installed llnsu of the user on his workstation and that captures the source password when the user enters the ) or to attacks "phishing" where the user believes communicate their password the legitimate application service so that it has actually been in contact with a hostile service or compromise - Finally, if the password had to be compromised in one way or another, it is not obvious that the user noticing in time to prevent fraud or even repeated fraud.

p0010Hence the well-known idea of ​​using in addition to a first factor of authentication, password, a second authentication factor supposed to demonstrate that a hardware device in the possession of the user effectively participate in each transaction authentication or signature. In this context, the password is often a decimal number, typically 4 to 8 digits, and it is then called a PIN.

p0011The user is thus able to protect itself against the usurpation of identity risk in perceiving that it is in possession of the hardware device in question. She may then block its identifier

p0012We see that the choice of the type of hardware device is not indifferent as to the safety achieved: Ideally, the device should be used frequently and the user has to relinquish the least frequently.

p0013With the rate of mobile telephony equipment reached today, one aspect of the invention provides for silent user's mobile phone device that constitutes the second factor of authentication.

p0014But this is not enough: it must also move from a static authentication where it is given the same authentication that is used every time a dynamic authentication when given auttientification is used once .

p0015The question here is how to generate such a dynamic authentication and how it demonstrates the effective involvement of the mobile phone user.

p0016The state of the art shows that there must be a secret specific to each mobile phone and an application to generate your dynamic credentials after entering the PIN, by use of secrecy and a diversification data, typically a clock a counter or a Challenge from the application service.

p0017However, this raises several issues that do not yet seem to have found a global response:

p0018- What to do to be in position to resist abusive objections of users (non-repudiation)? - How do users may reasonably rely on the application mentioned and how is it installed on users' mobile phones?

p0019- Where does the mentioned secret and how is it protected?

p0020Moreover, it is interesting to see how we can build a signature solution from a single authentication solution. In fact, the issue of the signing is in two parts:

p0021- Are we sure that the signature comes from the intended user?

p0022- How to materialize the consent of the user by connecting to the terms of the deal signed?

p0023The first part is reduced to the authentication of the user by the application service that will take to process the transaction.

p0024The state of the art shows that to treat the second part, we must present the terms of the transaction to the user and get a response from him, agreement or signature, which will depend on the terms and process of authentication. This functional requirement is called by the Anglo-Saxon "what you see is what you sign" fate "what sign is what we see." In other words we could say that a signature is a contextual authentication.

p0025An object of the present invention is therefore to provide a method of authentication and signature capable of meeting all of the problems described above and thus to significantly increase the security of transactions in relation to mechanisms known in the prior art.

p0026The principle of the invention is not only to use the mobile phone user to implement a second factor of authentication of a user from an application service, but also to implement a reliability application loaded by Escrow aboard the user mobile phone or a SIM card in the mobile phone user. This will result in strong user authentication, and will also sign safely transactions made by that user.

p0027The full description of the process will show that sharing responsibility provided between the application service on one hand and the third party on the other trust to keep within the requirement of non-repudiation, any affected party being in the position of being "judge and jury"

p0028- Each application service is responsible for the user πdentité ( "know your ingredient"), assigns an ID and PIN, the PIN being the first aijthentification factor in the sense of the present invention, and register with the Escrow the mobile number of the user, according to the declaration of the latter,

p0029- The Escrow manages the second authentication factor and as such is responsible for the reliability application.

p0030It is true that the requirement of non-repudiation is even stronger in the case of the signing of a transaction by a user in the case of a simple authentication thereof. We will see that the signature method of the present invention effectively meet this increased demand by preventing validates the generation of a signature in case of "browning" of the Application of confidence and own secret to the mobile phone of the user, c that is to say in the event of copy reproduction of these elements in other mobile phone.

p0031Of course, to implement the prindpe of the invention, it will be necessary to adapt the mobile phone and in particular the internal logidel, and to provide the server running the application service specific complementary software including writing from described process id will be accessible to the skilled person.

p0032The invention therefore relates to an authentication method and a signature method as defined in the claims which are incorporated by reference id.

p0033In detail, the invention particularly relates to an authentication method to two factors of a user from an Application Service running on an application server, ca acterized in that the first authentication factor is a code PIN authentication known only to the user of the Business Service, and that the second authentication factor is the mobile communication terminal of the user which has installed a reliability application obtained from a third party trust or certified by him, said reliability application being able to generate with said Gode PIN authentication and a shared secret key only with the Escrow, an authentication code for single use OTP for each authentication of the user to the application service. Gr✠the means used in œ airtrientification method, it is possible to authenticate a strong interface between user with an application service, by proceeding according to the following steps:

p0034- Following the entry of a PIN code authentication by the user, a step of generating an authentication code OTP disposable using the trusted application installed on the mobile communication terminal of the user ;

p0035- A step of communicating the passcode disposable OTP thus obtained to the application service;

p0036- A step of transmission by the application service authentication code for single use in a reduced form to Escrow;

p0037- A step of checking the single-use authentication code OTP by the Escrow;

p0038- A notification step of rauthentification result by the Escrow Service to the application.

p0039According to a first variant of the method, the first authentication factor, namely the PIN code authentication is provided to the user by the application service securely. But it is also possible that the PIN code authentication is selected by the user and transmitted to the application service securely.

p0040Similarly, the secret key can are created by the Escrow and communicated securely to the Application of confidence, but it is also possible to be generated by the application of confidence itself and communicated to the Third to securely confidence.

p0041According llnvention, the reliability application is obtained from a trusted third party or certified by him, and it is installed on the Terminal User's Mobile Communications prior to any user authentication.

p0042According to one aspect of the invention, the secret key is shared with the reliability application that runs on the mobile communication terminal, and the Escrow, but it is not accessible to the Service application, which guarantees the independence between the two factors of authenticity used.

p0043The single-use authentication code OTP is a unique code to each transaction, dynamically-generated Application of confidence and then communicated by the user application service without being communicated to the Escrow. It is generated by the reliability application after entry by useR PIN authentication code on the Mobile Communication Terminal.

p0044Before using the authentication method in a user authentication specific transactions, it is necessary to include this user with the Escrow. This registration stage is broken down as follows:

p0045- Register the user to the server Escrow;

p0046- Download and install the trusted Application in Mobile Communication Terminal;

p0047- Finally, activating said reliability application to make it functional for subsequent authentication operations from the user to the application server.

p0048In more detail, the stages from the registration of the user activation can be performed via an application service and then include the following steps:

p0049- A step dédaration his mobile number by the user to the application service;

p0050- A step by the application service request registration of the user with the Escrow by communicating the mobile number of the user;

p0051- A step of assigning to the user by the Escrow authenticity of a Code followed by a step of sending this Gode of authenticity to the application service;

p0052- A communication step of authenticity to the user code from the application service;

p0053- A step of sending by the reliable third party of an SMS type message to the user, said SMS message type that contains the settings for loading and installing the reliability application on the terminal of Mobile Communication;

p0054- A step of loading and installing the reliability application on the mobile communication terminal of the user;

p0055- A stage of activation of the reliability application after checking the authenticity code,

p0056- A generation step by the trusted application of a secret key;

p0057- A step of secure transmission of a secret key and said parameters of the Third œnfianœ server; - A step of checking the information received by the Escrow and initialization of the user registers;

p0058- A step of sending by the Escrow an activation confirmation message to the reliability application.

p0059But the stages from user registration to acrjvation can also be performed directly from a reliable third party, and they then comprise the following steps:

p0060- A user registration step with the Escrow;

p0061- A declaration of stage of mobile number by the user to the Escrow and validation thereof;

p0062- A stage of communication to the user by the Escrow an authenticity code;

p0063- A step of sending by the reliable third party of an SMS type message to the user containing the parameters of load and enable it to install the trusted application on his terminal Mobile Communication;

p0064- A step of loading and installing the reliability application on the mobile communication terminal of the user;

p0065- A stage of activation of the reliability application after checking the authenticity code;

p0066- A generation step by the trusted application of a secret key;

p0067- A secure transmission step of the secret key and said parameters to the server Escrow;

p0068- A step of checking the information received by the Escrow and initialization of the user registers;

p0069- A step of sending a message confirming activation of the reliability application by Escrow.

p0070In a first embodiment of the invention, the reliability application is loaded and installed in a memory of Mobile Communication Terminal, so make it executable by a microprocessor of Mobile Communication Terminal. Alternatively, the reliability application is loaded and installed in the SIM card memory, so as to make it executable by the microprocessor of the SIM and Mobile Communication Terminal.

p0071The invention also relates to a method of signing a transaction between an application server and a previously registered users and authenticated to said application server. This signature method comprises the following steps:

p0072- A step to prepare the application server a "Good to execute" (BAE) representative of the deal to sign, followed by the transmission of "Good to execute" and Mobile User Number in the Third server of confidence;

p0073- A step of generating at the server of the Escrow random challenge and a step of preparing and sending to the mobile communication terminal of the user "Good to execute" and the Challenge;

p0074- After acceptance of the "good for execution" by the user and its PIN code entry, a step of calculating the level of confidence a Response Application (R4) the transmission of "Good to run" by the Trusted third party ;

p0075- After entering the response (R4) by the user on the application service, calculated by the application server of a reduced response (Resp_r);

p0076- Transmission by the application server of the mobile number and the previously calculated reduced response in the Server Escrow;

p0077- At the Server Escrow, calculating a result (R6) and depending on the value of the result (R6), tell the application server if the user has properly signed the "Good to execute" or not.

p0078Note that the user's prior authentication step to implement this method of signature can be rauthentification two independent factors of the present invention, or another type of auttientification.

p0079The invention will be better understood by reference to the following description and the figures, in which:

p0080- Figure 1 shows a flowchart of a user registration process and its Terminal Mobile Communication with the application service; - Figure 2 shows a flow chart of the process of authenticating a user previously registered with the application service, implementing a reliable third party and the mobile communication terminal of the user, according to the invention;

p0081- Figure 3 shows a flowchart of a signature method according to the invention;

p0082- Figure 4 shows a flowchart of a user re-registration process with the application service, where prior registration has been compromised;

p0083- Figure 5 shows a flowchart of a method désinsαiption a user with an application service.

p0084Before describing the invention in more detail, it is useful to define a number of terms used in the following description.

p0085application service: Service wishing to use the invention for authenticating users in a strong way. It can especially be a Bank online service, for example through dintemet and / or via other channels. This application service is running on a server that hosts the application, and which users are connecting.

p0086PIN for "Personal Indentification Number" in English terminology: this is an authentication code from an application service which is unique to each user. This is therefore a secret, known only to the user and the application service, and is the first of the two factors of strong authentication of this solution. This PIN is managed entirely by the application service and not by the Escrow.

p0087User ID: ID of the user with an application service. This is typically a string of alphanumeric characters.

p0088Mobile number: number through which the mobile communication terminal or mobile user is uniquely identified on mobile networks (specifically, the mobile number is associated with one and only one SIM card when the -ci is inserted into a mobile, it can be attached by means of the mobile number, for an incoming call or text message for example). This number also serves didentifiant user with the Escrow. This is typically the telephone number when the Terminal Mobile Communications is a mobile phone.

p0089Mobile Communication Terminal or Mobile: the sense of the present application, the term terminal Mobile or Mobile Communication, any portable electronic device having at least a microprocessor, a memory, a device display and can connect to a digital telephone network wireless, including GSM, CDMA, UMTS or another, and accessible via a mobile number. In practice, it will usually a mobile terminal having code execution capabilities java type and data communication capabilities. As will appear below, the Mobile equipped with the confidence and a secret key application is the second strong authentication factor of the present solution.

p0090Application of confidence: it is an application, typically java type installed on the mobile or on the SIM card of it, and that allows the user to authenticate and / or sign a transaction according to the present solution. Note that this trust application requires a secret key that is stored on the mobile and is available only to the reliability application.

p0091secret key: it is a very secret randomly generated on the mobile and transmitted securely in Escrow. We'll see at the end of the installation process and activation of the reliability application on the mobile, trust and Application Escrow share the same strong secret Note that this strong secret might be generated by the Escrow and forwarded to the Application securely confidence. Also note that the word "strong" means that the entropy of secrecy is sufficient to withstand any brute force attack (which is not the case for a small secret, like a password classic). Escrow: Service manager registered Mobiles and as such manage the installation process and activation of the reliability application and contributing to the verification of OTP (for "One Time Passwond" in English terminology) Signatures and confirming in particular the involvement of the second factor that is the mobile. The Escrow is an independent entity from offering the application service.

p0092SMS (for "Short Message Service" in English terminology): short message sent to the mobile identified by the mobile number. The security of mobile digital telephone network (closed network type), guaranteed by the operators, ensures that only the mobile with a SIM card connected to SMS recipient mobile number will receive the message.

p0093SMS WAP push type: SMS with a specific descriptive message and a download URL Upon receipt of such SMS, Mobile displays a request to the user with an invitation to download the resource (eg a game or any application) on his mobile.

p0094withdrawal ID or ID withdrawal: technical identifier, aka transient mobile number, indicated in iurl parameter sent to Mobile via SMS message type or SMS WAP push.

p0095Enabling Trusted Application: it is a stage after downloading and installing the reliability application on the mobile communication terminal, which completes the installation process and activation the reliability application during its first run on the mobile. During this activation, a secret ae (Ks) is generated by the application of confidence, stored locally in the mobile and transmitted securely in Escrow. Alternatively secret ae (Ks) can be received securely from Escrow and installed in the Trusted Application.

p0096authenticity code: differentiating element; whose goal is to empower the user to verify that the installed reliability application actually comes from the Third Party trust. This code is provided to the user at the time of declaration Escrow Mobile number by the user and is displayed when Enable Trusted Application. If this code does not match or is absent, the user has the responsibility not to use the Application of confidence and contact the Application server, because there is a suspicion of fraud.

p0097OTP or "One Time Password" in English terminology: dynamic authentication code or dynamically generated by the trusted Application of this solution after entering his PIN by the user on the mobile. The code OTP is unique for authentication and shall be communicated by the user to authenticate to the application service.

p0098HMAC: a Message Authentication Code (or MAC, for "Message Authentication Code"), such as HMAC-Shal algorithm, but other secure MAC calculation algorithm is also suitable. The notation C = HMAC (M, K) is the authentication code of the message M, generated using the de K. The C code can be generated from M if we know the key K this therefore ensures both the integrity of M and authenticity. Conversely, we can not go back to the familiar key K M and C.

p0099Counter: internal variable, stored in the Mobile (Compteur_mobile) and the server Escrow (Compteur_base) and to diversify the generated OTP. When OTP is generated, the mobile counter value is incremented and when enabled, the counter value is updated on Escrow.

p0100Challenge code randomly generated by the Escrow during the signing process. As discussed later, the Challenge is sent with the "right to carry" or BAE to the trusted Application llntermédiaire by an SMS message type. It avoids replay signatures, but it also acts as a temporary secret because even an attacker who successfully steal the two-factor authentication will need more Challenge in order to generate a valid response. Answer: response calculated by the trusted application from BAE, PIN, secret ae and Challenge. Providing a correct answer by the Mobile proves the implementation of the two factors authentrfication in the presence of BAE, and thus manifest the consent of the user on the contents of the BAE. Note that the response is not repeatable, because the Challenge diversifies Answers.

p0101Good to execute or BAE: A set of data on which the application service requests the user to engage in the signature process. OEA will, as appropriate, be sent directly to the user using an SMS message type, or can be retrieved directly on a server by the trusted application using a URL retrieved from the SMS sent by the application service. Where the OSA is presented to the user using SMS, it will be limited in size.

p0102Description of the solution proposed by the invention:

p0103The method according to the invention will now be described in more detail with reference to FIGS. The overall process involves several processes, namely a prior user registration process (Figure 1) for it to use the invention, operating processes that help authenticate the user (Figure 2) and sign transactions with the application service (Rgure 3).

p0104The overall process also includes a re-registration process (Rgure 4) with the application service, in case a previous registration was canceled, and a désinsαiption process (Rgure 5) when the user no longer wishes to use his mobile to conduct transactions with the application service.

p0105Referring to Rgure 1 to describe the user registration process with the application service. This registration process includes a Mobile registration phase with the application service, an installation phase of a trusted application on the mobile, and a phase of activation of the reliability application. Registration process: Mobile registration phase

p0106We assume that each user is already registered with any application server that was assigned a user ID and PIN, as is the case the most commonly used terms in authentication processes

p0107At this point, the user can auttientifier to the application server by providing its user ID and PIN. But this is a weak authentication based on a single factor, the PIN.

p0108To complete this first factor, known secret of one user per second blandness, based on a user in possession of the hardware device, the registration process provides the user formally declares its Mobile Server with the number 5 application.

p0109This declaration will allow the application server to associate the Mobile to the user in a step indicated by reference 4. Application server 5 does not necessarily have the means to ensure that the user is the holder of the number of said mobile, so the user is responsible for his statement. That is why, it is preferably provided that the user sign this declaration online via an electronic signature of sufficient reliability, or traditional way (letter or form signed face to face).

p0110Based on this statement, the Application server 5 registered (step 6) Mobile declared to the Escrow.

p0111In step denoted 8, the Trusted Third server checks whether the mobile is already registered and activated in its database. If the Mobile is not already activated, the Escrow assigns an authenticity code which is transmitted (step 10) and application service dédenche the installation phase of the reliability application on the mobile, which will be her -even survival through activation of the reliability application phase.

p0112The application server 5 from the user confirms the recognition of its declaration and communicates to the user the authenticity code by warning that he will receive on its Mobile SMS message type, eg SMS wap push type allowing it to install a trusted application on his mobile that display this authenticity code during its first run. If once installed application does not display the User mobile number and the authenticity code announced, the user will have the responsibility not to proceed with the activation.

p0113Registration process: installation phase of the Implementation of Confidence:

p0114Following the registration of mobile number by the application server, the Escrow 7 emits a type of SMS WAP push or another (step 14 in Figure 1) for newly registered Mobile SMS containing a URL with a particular ID removal, temporary and confidential alias of the user's mobile number and disposable.

p0115By the arrival of this SMS, the user is prompted with an alert (step 16) to download the trusted Application to the URL conveyed by the SMS.

p0116A reception (18) of the user agreement, sending (20) the mobile communication terminal of a download-granted message for the Application of confidence Server Escrow.

p0117The Escrow solicited via this URL by Mobile (step 22):

p0118- I recovers¹ID checks and a withdrawal Activation is well underway for the corresponding Mobile;

p0119- Dynamically generates a personalized version and preferably signed by the trusted application with the mobile number, I¹ID withdrawal and authenticity code. The customized version of the reliability application also depends possibly the type of Mobile.

p0120Once downloaded on the mobile (step 24), the reliability application is then installed in the Mobile (step 26) after checking the integrity and code signing this Application component of trust.

p0121If the application is already installed, it should be reinstalled by purging all data previously created locally in the mobile by this application.

p0122For the reliability application can be signed and that the mobile operating system properly takes into account, it is better to rely at least on the MIDP 2.0 standard or equivalent Registration process: phase of Enabling Trusted Application:

p0123The activation occurs during the first run of the reliability application and used to generate a secret key Ks which will firstly be communicated securely in Escrow and also stored locally in the Mobile (3) with a counter at Mobile (noted Compteur_mobile) initialized to O.

p0124The Adivation the reliability application involves a voluntary act and therefore responsible for the user: to complete the activation, it will start by entering the authenticity code, which has the merit of force in take an active knowledge, which promotes alertness.

p0125Thus, at the first performance, reliability application indicates that is in phase of activation, displays the mobile number and the authenticity and prompts the user code (step 28) to proceed with the confirmation Activation by entering the authenticity code (step 30) if the data displayed on the mobile comply, namely that:

p0126- This is actually the mobile number he had declared to the application server (step 4);

p0127- It is expected authenticity code (step 12).

p0128If it does not, the user is prompted to not proceed with activation and report this anomaly or attempted fraud to the application server.

p0129When done before (step 30) by the user matches the authenticity code, the reliability application draws a random number that will serve as secret key Ks for the subsequent operations of authentication and / or signature, as described further. This secret key must be communicated so sour to trusted third party.

p0130To this end, the application of confidence:

p0131- Is a message containing the ID withdrawal, the authenticity code, the secret key and a possible "padding" or jam

p0132- Figure this message with the public key of Escrow, which information is contained in hard in the code of the Application of confidence,

p0133- And post or communicate by other means the encrypted message obtained at Escrow (step 32).

p0134Upon receipt of the encrypted message (or encrypted block), the Escrow (step 34): - Decrypts the received message using its private key, to extract the secret key Ks generated in the Mobile, and share the same secret key between the Mobile Server and Escrow;

p0135- Verify that I¹ID withdrawal corresponds to a current Mobile Activation;

p0136- Verify the authenticity code extract the decrypted message;

p0137- Initializes a counter to O, noted Compteurjbase, at the server of the reliable third party;

p0138- Retrieves and stores the secret key Ks and Compteur_base in case of positive verification;

p0139- Responds positively to appropriate the reliability application (step 36), passing the mobile communication terminal a message of good end of the activation of the reliability application.

p0140In case of positive response, the reliability application stores locally in the Mobile secret Qe and Compteur_mobile initialized to O. User is finally informed (step 38) that the reliability application is activated and the service authentication is now open

p0141A method of authenticating

p0142Referring to Figure 2 to describe the operation phase of the authentication process according to the invention, the activation of the trusted application that has already been made.

p0143Users of Mobile 3 wishes to authenticate to an application service 5 for which he knows his user ID and PIN.

p0144Taking into account that the Application services may not store the PIN in the clear in the same protected database, we hereafter introduce a function H which gives the stored value instead of the PIN from the PIN (and possibly other data known to the application service, but they will not be detailed in order not to unnecessarily burden the text). Typically H is a hash function (hence the rating), it is desirable not to be able to easily perform the inverse function H but can also be the identity function so the application server can access the user's PIN in dair in its database (identity function means that H (x) = x). G-after, PIN designates the PIN value as entered by the user, H (PIN) is the result of the function H applied to PIN and HPIN represents the replacement value of the PIN as stored by the application service (except input error, should have HPIN same value as H (PIN)).

p0145The user starts (step 40) the reliability application on his mobile, asking him his PIN code (step 42), and in response the user enters his PIN (step 44).

p0146The Application of confidence in the step referenced 46:

p0147- Calculates an OTP in an Fl function taking into account (Gompteurjnobile,

p0148H (PIN), ae secret Ks)

p0149- Increments the Compteur_mobile

p0150- And displays the OTP (step 48) on the mobile screen.

p0151The user enters (step 50) the user ID and OTP on the application service, through the user interface of the application service, which is a type of Internet connection interface, a voice server, or other appropriate interface.

p0152Based on the user ID already stored in its database (step 4), the application service determines (step 52) the mobile number and HPIN.

p0153Then the application service calculates an OTP reduces, denoted OTP_r = F2 (HPIN OTP), which is obtained according to a function F2 applied to HPIN and OTP as transmitted by the user in step 50.

p0154The application service then submits (step 54) the mobile number and the server rθTP_r Escrow.

p0155Compared to the previously registered mobile number (step 6, Figure 1), the Escrow determines the value of Compteur_base. Moreover, he finds the secret Qe Ks, recorded in step 34, Figure 1.

p0156Then (step 56), the Escrow:

p0157- Calculates an increment value, equal to the result of a function applied to F3

p0158(Gompteur_base, secret key Ks, OTP_r)

p0159- Compteurjbase increments of increment value

p0160- And returns (step 58) the application service message "OK" if Increment> O, meaning that the user has been authenticated by both the PIN and the OTP generated in the Mobile and transmitted as reduced Trusted third party. In Otherwise, a message "Not Ok" or NOK, is transmitted to the application service, which relays it OK or NOK message to the user (step 62).

p0161Example of an embodiment of the functions Fl, F2 and F3:

p0162A WBS is calculated from two elements:

p0163- An indicator, denoted Ind

p0164- And a discriminant, noted Dis.

p0165The indicator is an integer strictly smaller than maxlnd setting and actually equal to modulo Compteur_mobile maxlnd.

p0166If a user has at least a number of OTP maxlnd without them validated positively with the Escrow then counter it, Compteur_base, finds himself out of sync with the clock, Compteur_mobile, the trusted application: no new OTP can be validated without having previously retimed the counter Escrow compared to the reliability application.

p0167The discriminant discriminant is part of the OTP, ie that it is impossible to generate without knowing both the counter, the PIN and the secret key Ks.

p0168Ultimately, OTP = + Ind maxInd * Say

p0169In the variant described below, based on a "cipher" basic (but sufficient) by XOR (the XOR), it is necessary that the discriminant can take all possible values ​​of an integer N bits.

p0170Example: If we want the OTP held on 7 decimal digits, it may be wise to reserve 18 bits discriminant:

p0171- Maxlnd will then 38 (above, an OTP generated may not fit on 7 decimal digits and below, is not used optimally entire capacity of this solution)

p0172- MaxDis, maximum value of the discriminant will be 262144 (or 2 to the power

p017318).

p0174Fl function Fl (Compteur_mobile, H (PIN) secret key): Ind = Gompteur_mobile modulo maxlnd

p0175two messages Ml is calculated as M2:

p0176Ml = HMACflnd, H (PIN))

p0177M2 = HMAC (Compteur_mobile, Shared Key)

p0178Then calculated Ml and M2 defined by:

p0179M'1 = Ml modulo maxDis

p0180M2 = M2 modulo maxDis

p0181This has the effect of shortening the length of Ml, M2;

p0182And calculate M3 = M2 M'1 XOR

p0183Then it returns Ind + M3 * maxlnd

p0184Function F2: F2 (HPIN OTP):

p0185Ind = OTP modulo maxlnd

p0186A3 = OTP / maxlnd

p0187We calculate Al = HMAφnd, HPIN)

p0188Then Al = A1 modulo maxDis

p0189A3 and A4 = XOR Al

p0190Back then Ind + A4 * maxlnd.

p0191F3 Function: F3 (Compteur_base, secret Oé, OTP_r)

p0192Ind = OTP_r modulo maxlnd

p0193T4 = 0TP_r / maxlnd

p0194Calculating an increment = Ind - (modulo Compteur_base maxlnd)

p0195If Increment <= O So increment = increment + maxlnd

p0196We calculate T2 = HMAC (Compteur_base + increment, secret key)

p0197T2 and T2 = modulo maxDis

p0198If T2 T4 ≠ Then increment = 0

p0199Return increment. Signature method

p0200Referring to Figure 3 to describe the signature method according to the invention.

p0201Assume that the mobile user wants to validate a set of data generated by the application service and make a request to execute (step 64) to the application service. This data may include a payment order or a contract auttientification The two factors mentioned in the preceding paragraph to demonstrate that it is in the presence of a reliable user, but can not demonstrate that user has viewed and validated one or more specific data; it is the object of the signature process. For the implementation of the signature process, it is assumed that the Acrjvation User's Mobile has already been carried out prior

p0202In addition, throughout the signing process, the user is considered to be already properly authenticated to the application service (by the authentication process of the solution or by another method of authentication or identification by a simple without authentication), and it is assumed that he wishes to validate a set of data.

p0203In the step referenced 66, the application service prepares the data set to validate based on the items he knows (eg identity, user address, account number, rate, tariff ...) and elements that asks the user (amount, duration, ...) and derives a good run in (BAE) with essential data on which asks the user to engage. It is also possible that BAE indurated in an original document hash containing all the data.

p0204The application service transmits to the Escrow and BAE user's mobile number (step 68).

p0205The Escrow determines (step 70) a random data called Challenge. D sends to the reliability application an SMS (step 76) containing the BAE and the Challenge or communicate to the reliability application components that will allow it to recover the BAE and the Challenge. Once the BAE presented to the user (step 80), he is asked sil wants to sign it or not.

p0206It may choose not to sign the BAE, or it can choose to sign. In the latter case, the user enters the PIN (step 82) and the Application of confidence, in step 84:

p0207- Calculates Answer = F4 ([3AE, Challenge, H (PIN) secret key Ks),

p0208- Response and displays to the user.

p0209The user enters the response application service (step 88). The application service determines in relation to the user ID and its current validation request BAE and HPIN.

p0210The application service calculates (step 90) a reduced response such as: Resp_r = F5 (BAE, Response, HPIN).

p0211In step 92, the application service submits your mobile number and the Resp_r Escrow.

p0212Compared to the previously registered mobile number (step 4, Figure 1), the Escrow determines the challenge and the secret key Ks.

p0213The Escrow (step 94):

p0214- Calculates profit = F6 (Challenge, Resp_r, secret key Ks),

p0215- Result returns the application service,

p0216- Clears the Challenge in case of positive result.

p0217In case of a negative result, a failure signature is inscribed opposite user lidentifiant, and we can provide a blocking any signature after 3 failures for example.

p0218Note that result is a boolean indicating whether the validation is correct or not. Thus, proper validation indicates:

p0219- That it has been good entering the correct PIN code of the user,

p0220- AND that it has been well implemented the secret key Ks of the reliability application installed on the mobile,

p0221- AND that it has indeed been using the Challenge sent to Mobile,

p0222- And that all of these are related to the BAE.

p0223Based on this result the application service can consider that it has been very effective and explicit will of the user to validate the contents of the BAE and express consent on its content. Embodiment of the F4 function, F5 and F6:

p0224Unlike OTP generation functions there this time using a Challenge / Response mechanism, and it does not involve notion counter.

p0225The only parameter is the maximum response, which is an integer strictly smaller than maxResp parameter.

p0226[Example: If we want the response takes about 6 decimal digits, is maxResp 1000000.

p0227F4: F4 (BAE, Challenge, H (PIN) secret key):

p0228Ml is calculated as M2: Ml = HMAC (BAE, H (PIN)) M2 = HMAC (DER-I-BAE, secret key) is then calculated Ml, M2 such as M'1 modulo Ml = M2 = maxResp M2 modulo maxResp Return XOR M2 Ml.

p0229F5 Function: F5 (BAE, Response, HPIN)

p0230We calculate Al = HMAC (BAE, HPIN) Then A'1 = A1 modulo maxResp Return XOR Al Response.

p0231F6: F6 (Challenge, BAE, Resp_r, secret key):

p0232T2 = + HMAQDéfi BAE is calculated secret Oe) = T2 PuisT2 modulo maxResp

p0233Return the boolean (T2 == Resp_r). This Boolean is set to "TRUE" if and Réponse_r T2 are equal, and takes the "FALSE" value otherwise. Process management life Cyde

p0234For Cyde of life, the process for setting up and operational use of the solution have been described (Figures 1 and 2), it remains to describe some other related cases Cyde life.

p0235The following cases may occur:

p0236- Loss, forgetfulness PIN user

p0237- Change of Mobile with conservation of Mobile Number

p0238- Uninstall the reliability application by mistake or acddent

p0239- Changing the mobile number

p0240- Loss or theft of the Mobile (and assodée SIM card)

p0241- Error on the mobile number during initial renregistrement

p0242- Voluntary termination of service by the user.

p0243Immediately treat cases related to PIN: this solution does not properly manage this bet PIN entire life Cyde related PIN is the responsibility of the application service, as already known. The application service must implement a process associated with the loss and forgetting the PIN (or reference PIN reset). Most often, this issue is already addressed by the application service to the extent that the PIN could be used previously as weak means of authentication (single factor).

p0244To answer the other case, two particular methods are defined: re-registration and désinsσiption user.

p0245The repeat is described in relation to Figure 4, which is similar to Figure 1 corresponding to the registration. Therefore the same steps have been designated by the same reference numerals.

p0246Re-registration for a mobile number given is to place at the Escrow Mobile in a state corresponding to the initial registration, as indicated by step 108: the secret key is deleted from the server, a new Code authenticity is generated (step 10) and communicated to the application service, the Compteur_mobile is reset (step 26), and an SMS WAP PUSH type ID with a new withdrawal is sent (step 14) to trigger the mobile resettlement. Only the mobile number is not deleted from the trusted server.

p0247The désinscriprjon is described with respect to Figure 5. IBE is for a mobile number given transmitted by the application service (step 144), delete the server Escrow all data related to Mobile (step 146) . The latter finds herself in an unknown state or not registered

p0248H Note that the possession of the Mobile Application on which the trust is installed and enabled allows us to draw CFTP that are valid as long as the entered PIN is good and as long as the Escrow has not received an application for reinstatement or désinsαiption.

p0249But beware the fact that a request for re-registration may result if the mobile is always provided with the SIM card and the mobile number is still active for this SIM card. In case of loss or theft of the SIM card, it is recommended to seek désinsαiption. In other cases, a re-registration may be sufficient, and avoids having to go through the registration phase (cumbersome because you have to provide the reliable mobile number of the application service).

p0250On this basis, it is possible to propose the following rules regarding the process to be adopted depending on the case:

p0251<img id="imgf000027_0001" he="100" wi="149" file="imgf000027_0001.tif" img-format="tif" img-content="table" orientation="portrait" inline="no" />_^

p025226

p0253<img id="imgf000028_0001" he="32" wi="149" file="imgf000028_0001.tif" img-format="tif" img-content="table" orientation="portrait" inline="no" />

p0254It should be noted that in the description above, the reliability application is stored in a memory of the mobile. In an alternative implementation of the invention, one can still install the trusted application on the SIM card (for "Subsαiber Ideπtity Module") of Mobile, where it can then execute.

p0255Advantages of the invention:

p0256The invention can meet the specified goals, by providing a method of autrientification strong and signature from an application server, based on the use of two independent factors, namely a PIN from the user the responsibility the application service, as already known in the state of the art and user's Mobile Application with a confidence and a secret key, both of which are under the responsibility of an Escrow.

p0257The state of the art provides for the implementation of an application and a seσet in the mobile user but as already mentioned questions remain:

p0258- Where does the secret, and how is it protected?

p0259- How to ensure the integrity of the application?

p0260The registration process in the phase of activation of the present invention provides that the secret key playing the generic role of the mentioned secret is drawn randomly by the trusted application and communicated to the Escrow, encrypted with a public key of the Third of confidence. From fors that the integrity of the reliability application is ensured (œ that is the subject of the question), this prevents any interception of the secret ae in its communication to the Escrow. Moreover, respect for the MIDP 2.0 standard or equivalent enables the reliability application to store data on the mobile while prohibiting in principle any access to anyone outside of the Application of trust itself (note despite any risk at least theoretical access to such data by intervening in the Mobile operating system: we will return later citing the risk of "gold plating").

p0261The integrity of the reliability application is provided as part of the present invention through the following caracbéristiques:

p0262- It is still possible to install an application may attempt to play the role of the Application of confidence but it will not impersonate the user by ignorance of the secret key; Moreover, assuming that the installation of such malicious application comes as the mobile user has been registered with the Escrow before and Enabling Trusted Application by the user: the malicious application that would have been installed in place of the trusted application will not be able to accept secret key to Escrow through ignorance of ITD withdrawal (provided the only Mobile user SMS wAP push or equivalent) and / or code autnenticité (communicated to the user via the application service, so via a channel other than Mobile).

p0263- After installation and activation and unless it is signed by the Escrow, it is possible to change the trusted Application except by deleting and replacing the application (safe intake of the standard MK⁾P 2.0 JAVA), but in this case, the secret key is deleted, which render inoperative the new vis-à-vis the Escrow application.

p0264Other issues relating to the state of the prior art, it raises the requirement of non-repudiation.

p0265The sharing of responsibility between or Application Services and Third to expected confidence by the present invention ensures that no party may be in a position to "judge &amp; Party"

p0266- Or an application service that knows your PIN (or HPIN) of each of its users as it will not know the secret key required for generating OFTP or Signatures (in fact, even a brute force attack will not allow him to deduce the secret key from observations of OIIP and / or Signatures); Moreover, any more than anyone else, an application service is capable of undermining the integrity of the trusted Application (changing the Application confianœ could directly help recover the secret key and the installation of a false confidence application could have to make a Activât-on and thus indirectly retrieve the secret key)

p0267- Nor the Escrow who certainly knows the secret key of each user as it will not know the PIN (or HPIN) thereof to the various Application Services (indeed, it does not directly receive your (JTP and Signatures produced by the application of confidence, he receives only a reduced form of the data precisely where the influence of the PIN has been cleared); it nevertheless assumes that the third party confianœ can not afford to install a Application confianœ deliberately with a well and backdoor trick demonstrably the confianœ made to him, the Application Services with a right of audit

p0268With those features, the invention provides a solution authentjfication able to withstand any challenge abusive attempts users. It is seen that the invention provides a seal between your actual data managed respectively by your Application Services and Escrow: where real independence between your two factors authenUfication.

p0269To support the signature function, we saw the need to ensure that "we œ œ sign is seen" ( "what you see is what you sign".)

p0270One aspect of the present invention provides for the dispatch by the Third Party confianœ an SMS to the user's Mobile signatory œ SMS with a BAE and Challenge. The application of this confianœ BAE you the user who signs by entering the PIN, the confianœ application then generates the signature or technically Response to the Challenge. This makes an effective solution to the exigenœ "œ œ that sign is seen". Indeed; although anyone can send a SMS to the user signatory:

p0271- Or the application of Confianœ woke up and supports the treatment but on the one hand the user will agree to sign if he presented valid BAE you, thus preventing œ to sign anything without the knowledge of the user, and secondly, if the SMS is not sent by the Third Party confianœ it nV no chance to generate a valid signature does not know since then challenge you positioned yourself Tiers confidence and sent by SMS to one mobile user - Or another application is thereby awakened: lîiypotfièse even where the latter is malicious, it can not generate a valid signature because it has no access to the secret key.

p0272Return here to the theoretical risk of "cloning" of the reliability application.

p0273We realize that trust donated Application with data including secret QE on a mobile other than the legitimate user will still fail to generate a valid signature: the Challenge is indeed necessary or it is sent by SMS by Escrow only Mobile user (actually, the user's mobile is the one that contains the SIM card and it is not givable).

p0274Finally on a practical level and not just for the safety of the process, we see that the present invention has the advantage of being binding to deploy. Indeed through limited modifications, it is possible to strengthen an existing authentication system to a single factor authentication (password) by turning it into an authentication system to two factors according to the present invention, and this preserving renregistrement already users ( "know your ingredient" with assigning a username and a password). To do this, it suffices that the application service manager of the initial authentication system:

p0275- Subscribes to the Escrow adapting somewhat its computer processing

p0276- Full renregistrement users through the implementation of the registration process for the mobile recording phase.

p0277In this context, it is nevertheless recommended that the application service requires users to renew their passwords (that become on this occasion PINs) because the old passwords may have been previously compromised.

p0278Note that several different and independent Application services, potentially managed by different sodétés, may well strengthen each of them their existing authentication system side as shown above and d ced without conflicts between them:

p0279- The first application service that registered the Mobile a user with the Escrow entails installing and Acϋvation of the confidence in the Mobile Application User, - The following benefit directly from the installation and activation already done.

p0280Finally, it should be noted that in a variant of the present invention, the confidence Applicattan can be installed in the SIM card of the user, which then brings even greater security. But it is not essential to achieve ample security (nV there is no "absolute security") and used directly without the SIM card thus obtaining a deployable solution completely independently of mobile operators.