Mobile device user validation method and system

Abstract

A system including a mobile device, a user of the mobile device, a computer system having a telecommunication module for telephonically communicating with the mobile device, a user of the computer system, and a security server is provided. Also provided is a method, at a mobile device, of authenticating a user of the mobile device during a telephone call having the steps of obtaining a user authentication input, obtaining validation of the user authentication input, initiating a telephone call with, or receiving a telephone call from, the computer system, and if the user authentication input is successfully validated, sending a token generated for the telephone call with the computer system via data-over-voice frequency signaling during the telephone call thereby providing an indication that the user authentication input has been successfully validated to the computer system.

Claims

1. A method implemented at a mobile device for authenticating a user of the mobile device during a telephone call, the mobile device in communication with a security server and a third party computer system, the method comprising: obtaining, at the mobile device, a user authentication input from the user of the mobile device, the user authentication input including at least one of a biometric input, fingerprint, face photo, eye photo, pattern, and PIN; validating the user authentication input; upon successful validation of the user authentication input, generating interaction data associated with one or more past interactions between the mobile device and the security server by obtaining, from the security server, a record of a predetermined number of past operations between the mobile device and the security server, the record being obtained as a token; in response to generating the interaction data associated with the one or more past interactions, encrypting, using an encryption scheme common to the mobile device and the third party computer system, the token by encrypting the user authentication input and the record of the predetermined number of past operations; initiating a telephone call with the third party computer system via a telecommunications channel; generating a dual-tone multi-frequency (DTMF) signal including the encrypted token; and during the telephone call, sending the DTMF signal via the telecommunications channel to the third party computer system, thereby enabling the third party computer system to validate the encrypted token by communicating with the security server and applying the encryption scheme, such that the identity of the user of the mobile device is validated.

2. The method according to claim 1, wherein obtaining validation of the user authentication input comprises validating the user authentication input at the mobile device.

3. The method according to claim 2, further comprising generating the token at the mobile device using information stored in a secure memory of the mobile device, if the validation of the user authentication input at the mobile device is successful.

4. The method according to claim 1, further comprising generating at least one of a cryptographic key, and a cryptographic key pair at the mobile device, or receiving at least one of the cryptographic key and the cryptographic key pair.

5. The method according to claim 1, further comprising identifying a communication failure with the security server.

6. The method according to claim 1, wherein the token is encrypted before being sent to the third party computer system.

7. The method according to claim 1, wherein the token is uniquely generated for the telephone call.

8. The method according to claim 1, further comprising, at the third party computer system, retrieving a user record corresponding to the user of the mobile device, if the token is successfully validated.

9. The method according to claim 1, further comprising, at the third party computer system, identifying a communication failure with a security server, wherein obtaining validation of the token comprises validating the token at the third party computer system using at least one of a cryptographic key and an algorithm common to the third party computer system and the mobile device, when a communication failure with the security server is identified.

10. The method according to claim 1, further comprising, at the third party computer system, receiving data relating to at least one past interaction between the security server and the mobile device via data-over-voice signaling during the telephone call and comparing the received data to a record obtained by the third party computer system or stored at the third party computer system, thereby validating the identity of the mobile device.

11. The method according to claim 1, further comprising, at the mobile device: upon successful validation of the user authentication input, generating, using a one-way hash function, a token request by encrypting the user authentication input; establishing a connection with the security server; in response to establishing the connection with the security server, transmitting the token request to the security server for validation at the security server; and in response to the validation of the encrypted user authentication input included in the token request, receiving a token from the security server, the token generated using at least one of a cryptographic key, cryptographic key pair, and an algorithm common to the security server and the third party computer system.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which:

(2) FIG. 1 depicts a representation of the components in a system;

(3) FIG. 2 is a flow diagram depicting the method steps carried out at the system of FIG. 1;

(4) FIG. 3 shows an alternative system;

(5) FIG. 4 is a flow diagram depicting the method steps carried out at the system of FIG. 3;

(6) FIG. 5 shows an alternative system;

(7) FIG. 6 is a flow diagram depicting the method steps carried out at the system of FIG. 5;

(8) FIG. 7 shows an alternative system;

(9) FIG. 8 is a flow diagram depicting the method steps carried out at the system of FIG. 7; and

(10) FIG. 9 depicts components of the mobile device shown in FIGS. 1, 3, 5, and 7.

DETAILED DESCRIPTION

(11) FIG. 1 depicts a representation of the components in, and users of, a system suitable for carrying out the method described herein. The system includes a mobile device 102 suitable for making telephone calls, a user 104 of the mobile device 102, a third party computer system 106 having a telecommunication module for telephonically communicating with the mobile device 102, a third party user 108 who uses the third party computer system 106, and a security server 110.

(12) There are three connections between the components of the system depicted in FIG. 1. A first connection 1 between the mobile device 102 and the computer system 106 is a telephone connection. The first connection 1 could also be via any network suitable for transmitting data via DTMF signaling. A second connection 2 is between the mobile device 102 and the security server 110. The second connection 2 may be via a telecommunications network, such as the internet. Finally, a third connection 3 is between the computer system 106 and the security server 110. The third connection 3 may also be via a telecommunications network, such as the internet.

(13) The security server includes a relational database in which user details are stored. The user details include an identification number associated with the user known as a user ID. The user details further include a record of one or more user authentication inputs associated with the user 104 and any other information about the user 104 in the form of a user record. The user ID may also be stored on the mobile device 102, alongside the record of one or more user authentication inputs associated with the user 104.

(14) FIG. 9 depicts components of the mobile device 102 shown in FIG. 1.

(15) The mobile device 102 includes a processor 902 which is in communication with a memory 904, a user authentication input receiving module 906, a telecommunication module 908, a DTMF signaling module 910, and a security server communication module 912, all of which are in communication with the processor. The mobile device also includes a graphical user interface (GUI) (not shown) in communication with the processor.

(16) The processor 902 controls the operation of the mobile device by issuing commands to the various components of the mobile device to perform operations.

(17) The memory 904 is a secure memory for securely storing data, such as the record of user authentication inputs associated with the user 104 and a cryptographic key.

(18) The user authentication input receiving module 906 is configured to allow the user 104 to input user authentication data such as a biometric input, fingerprint, pattern, face photo (i.e. for face recognition purposes), eye photo (i.e. for eye recognition purposes), or PIN at the mobile device 102. The user authentication input receiving module 906 may be integrated with the GUI.

(19) The telecommunication module 908 is suitable for establishing the first connection 1 shown in FIG. 1, either by making a telephone call from the mobile device 102 or receiving a telephone call from the computer system 106.

(20) The DTMF signaling module 910 is in communication with the telecommunication module 908 and is configured to automatically generate DTMF signals which are sent to the computer system 106 via the telecommunication module 908 and via the first connection 1.

(21) Although the detailed embodiment described herein makes use of DTMF signals generated by a DTMF signaling module 910, the methods and processes of the detailed embodiment described herein could equally be carried out by using different signals.

(22) In an alternative embodiment, a data-over-voice signaling module is provided, in place of the DTMF signaling module 910, which is in communication with the telecommunication module 908 and is configured to automatically generate data-over-voice signals which are sent to the computer system 106 via the telecommunication module 908 and via the first connection 1.

(23) The data-over-voice signaling module may make use of a known mechanism for transmitting data during a telephone call. For example, the audio-frequency tones used by fax machines may be utilized or the audio frequency signals used by dial-up modems. Other known types of multi-frequency signaling may also be utilized, of which DTMF signaling is but one example.

(24) It will be understood that the steps of all of the methods and processes described herein which are carried out by the DTMF signaling module 910 may, in the alternative embodiment, be carried out by the data-over-voice signaling module with data-over-voice signals being used in place of DTMF signals.

(25) The security server communication module 912 is configured to establish the second connection 2 between the security server 110 and the mobile device. The security server communication module 912 is also configured to detect when a connection with the security server 110 is not available.

(26) FIG. 2 is a process flow diagram. At step 201, the user authentication input receiving module 906 of the mobile device 102 obtains a user authentication input. The authentication input may be one or more of a biometric input, face photo, eye photo, fingerprint, pattern, PIN, or personal ID number.

(27) At step 202, the security server communication module 912 of the mobile device 102 sends a token request to the security server 110 via the second connection 2. The token request includes an encrypted version of the user authentication input obtained at step 201. The token request is encrypted using a one-way hash function and, optionally, a nonce added to the token request before the hash function is generated.

(28) At step 203, the security server 110 then receives the token request with the encrypted user authentication input. The security server 110 decrypts the user authentication input. The security server 110 validates the user authentication input by comparing it to a record of user authentication inputs associated with the user 104, provided in the user account, which are stored on the security server 110.

(29) At step 204, if the validation of the user authentication input at the security server 110 is unsuccessful, the process is terminated.

(30) At step 205, if the validation of the user authentication input at the security server 110 at step 203 is successful, a token is generated at the security server 110, which is then sent to the mobile device 102. The token is generated using a cryptographic key or key pair, or an algorithm common to the security server 110 and the computer system 106, such that the token can be validated at the computer system 106.

(31) Alternatively, the token may be generated using a cryptographic key or an algorithm stored only on the security server 110 such that the token may only be validated at the security server 110.

(32) At step 206, the security server communication module 912 of the mobile device 102 receives the token generated by the security server 110 via the second connection 2.

(33) At step 207, the telecommunication module 908 of the mobile device 102 either initiates a telephone call with, or receives a telephone call from, the telecommunication module of the computer system 106 via the first connection 1.

(34) At step 208, the DTMF signaling module 910 of the mobile device 102 generates a DTMF signal corresponding to the token and the token is sent by the telecommunication module 908 to the computer system 106 via DTMF signaling, during the telephone call, along with the user ID. This provides an indication that the user authentication input has been successfully validated to the computer system 106. This is because the DTMF signaling of the token only occurs if the user authentication input has been successfully validated. As such, the computer system 106 can determine that the user has been validated upon receiving a token and once validation of the token has been obtained by the computer system 106.

(35) At step 209, the telecommunication module of the computer system 106 receives the token generated at the security server 110 along with the user ID from the mobile device 102 as a DTMF signal during the telephone call and a DTMF signal receiving module of the computer system 106 extracts the token from the received DTMF signal.

(36) In the aforementioned alternative embodiment, the DTMF signal receiving module is replaced by a data-over-voice signal receiving module adapted to extract a token from a received data-over-voice signal.

(37) At step 210, a token validation module of the computer system 106 obtains validation of the token. The token is validated at the computer system 106 using a cryptographic key or key pair, or an algorithm common to the mobile device 102 and the computer system 106.

(38) Alternatively, where the token is generated using a cryptographic key or an algorithm stored only on the security server 110, the token validation module of the computer system 106 obtains validation of the token by contacting the security server 110 using a security server communication module of the computer system 106 which contacts the security server 110 via the third connection 3. The computer system 106 either sends the token to the security server 110 for validation and receives notification of the outcome from the security server 110, or it receives data from the security server 110 so as to enable validation to be performed at the computer system 106.

(39) Once validation of the token has been obtained by the computer system 106, the computer system 106 can determine that the user authentication input has been successfully validated. Therefore, the computer system 106 can determine that the identity of the user 104 has been successfully validated. This can be indicated to the third party user 108 via any suitable means.

(40) At Step 211, if the validation of the token is unsuccessful, the process is terminated and the computer system 106 either ends the call or attempts to authenticate the identity of a user 104 via other means.

(41) At step 212, if the validation of the token is successful, the security server communication module of the computer system 106 uses the user ID to retrieve the user record corresponding to the user 104 of the mobile device 102 from the security server 110, via the third connection 3. The user record provides additional information about the user 104 to provide context to the call. For example, it can provide the computer system 106 with an indication of what the purpose of the call may be.

(42) FIG. 3 shows an alternative system in which the third connection 3 is not available, i.e. the computer system 106 is not connected to the security server 110 and is working offline. When such an issue arises, the method may be automatically adapted, as shown in FIG. 4 and as shall now be described.

(43) FIG. 4 is a process flow diagram. The processes carried out at steps 401 to 404 mirror the processes carried out at corresponding steps 201 to 204, as described above, as the first and second connections 1 and 2 are still available.

(44) At step 405, the token is generated at the security server 110 using a cryptographic key, cryptographic key pair or algorithm which has already been shared with the computer system 106, such that the computer system 106 is able to validate the token itself without needing to access the security server 110 as the third connection 3 is unavailable.

(45) The processes carried out at steps 406 to 409 mirror the processes carried out at corresponding steps 206 to 209.

(46) At step 410, the security server communication module of the computer system 106 detects that no connection with the security server 110 is available and the token validation module of the computer system 106 validates the token at the computer system 106. The token is validated using a cryptographic key, cryptographic key pair or algorithm which has already been shared with the computer system 106. As such, the computer system 106 is able to validate the token itself without needing to access the security server 110. If the validation is successful, the third party user 108 may continue with the call knowing that the identity of the user 104 has been validated.

(47) The process carried out at step 411 mirrors the process carried out at corresponding step 211.

(48) FIG. 5 shows an alternative system in which the second connection 2 is not available, i.e. the mobile device 102 is not in communication with the security server 110 and is working offline. When such an issue arises, the method may be automatically adapted, as shown in FIG. 6 and as shall now be described.

(49) FIG. 6 is a process flow diagram. At step 601, the user authentication input is obtained by the mobile device 102 in the same manner as is in step 201, detailed above.

(50) At step 602, the security server communication module 912 of the mobile device 102 detects that no connection with the security server 110 is available and the user authentication input is validated at the mobile device 102. The mobile device 102 validates the user authentication input by comparing it to a record of user authentication inputs associated with the user 104 which are securely stored on the mobile device memory 904. The memory 904 is a secure memory, for example it may be a secure element.

(51) At step 603, if the validation of the user authentication input at the mobile device 102 is unsuccessful, the process is terminated.

(52) At step 604, if the validation of the user authentication input at the mobile device 102 is successful, the mobile device 102 generates data relating to a past interaction, or past interactions, between the security server 110 and the mobile device 102. The mobile device 102 does this by obtaining a record of a predetermined number of past operations between the security server 110 and the mobile device 102. The record of a predetermined number of past operations acts as a token generated for a telephone call, which is then encrypted. The token is encrypted using a one-way hash function and, optionally, a nonce before being sent to the computer system 106.

(53) At step 605, the telecommunication module 908 of the mobile device 102 either initiates a telephone call with, or receives a telephone call from, the telecommunication module of the computer system 106 via the first connection 1.

(54) At step 606, the DTMF signaling module 910 of the mobile device 102 generates a DTMF signal of the encrypted data relating to a past interaction, or past interactions, between the security server 110 and the mobile device 102, which is sent as an encrypted token by the telecommunication module 908 to the computer system 106 via DTMF signaling, during the telephone call, along with the user ID. The token provides an indication that the user authentication input has been successfully validated to the computer system 106. This is because the DTMF signaling of the record of a predetermined number of past operations (i.e., the token) only occurs if the user authentication input has been successfully validated. As such, the computer system 106 knows that the user 104 has been validated upon receiving a token and once validation of the token has been obtained by the computer system 106.

(55) In an alternative embodiment, steps 602 and 603 are omitted and no validation of the user authentication input occurs at the mobile device. Step 604 occurs automatically as there is no longer a validation of the user authentication input step at the mobile device 102. Instead, the user authentication input data is also encrypted and sent to the computer system 106 via DTMF signaling, during the telephone, for validation at the computer system 106.

(56) At step 607, the telecommunication module of the computer system 106 receives the record of a predetermined number of past operations between the security server 110 and the mobile device 102 as an encrypted token, along with the user ID, from the mobile device 102 via DTMF signaling during the telephone call. The DTMF signal receiving module of the computer system 106 extracts the encrypted token from the received DTMF signal and the computer system 106 decrypts the token.

(57) At step 608, the token validation module of the computer system 106 obtains validation of the token. The predetermined number of past operations is validated by contacting the security server 110 via the third connection 3. The security server communication module of the computer system 106 either sends the token to the security server 110 for validation and received confirmation of the outcome of the validation from the security server 110, or it receives a corresponding record of a predetermined number of past operations between the security server 110 and the mobile device 102 from the security server 110 so as to enable validation to be performed at the computer system 106.

(58) Once validation of the token has been obtained by the computer system 106, the computer system 106 can determine that the user authentication input has been successfully validated. Therefore, the computer system 106 can determine that the identity of the user 104 has been successfully validated.

(59) At Step 609, if the validation of the token is unsuccessful, the process is terminated and the computer system 106 either ends the call or attempts to authenticate the identity of a user 104 via other means.

(60) At step 610, if the validation of the token is successful, the security server communication module of the computer system 106 uses the user ID to retrieve the user record corresponding to the user 104 of the mobile device 102 from the security server 110, via the third connection 3, thereby obtaining additional information about the user 104, as described above in relation to step 212.

(61) In the alternative embodiment where the user authentication input data is also sent to the computer system 106, an additional process step, not shown in FIG. 6, may be carried out where the computer system 106 obtains validation of the received user authentication input data, either validating it locally or by sending it to the security server 110 for validation.

(62) FIG. 7 shows an alternative system in which both the second and third connections 2 and 3 are not available, i.e. the mobile device 102 and the computer system 106 are working offline. When such an issue arises, the method may be automatically adapted, as shown in FIG. 8 and as shall be described below.

(63) In the method shown in FIG. 8, a cryptographic key, such as a private key and public key pair or a symmetric key, are stored at the mobile device 102 and computer system 106. One of the following three ways is used to generate and distribute the private key and public key pair or symmetric key.

(64) The security server 110 generates a key or key pair that is then propagated to the computer system 106 and mobile device 102 using any kind of channel. For example, the key or key pair may be propagated at a time when the second and third connections 2 and 3 are available or they may be transmitted by suitable alternative means.

(65) Alternatively, the mobile device 102 generates the key or key pair that is then propagated to the computer system 106 using any kind of suitable channel, for example, using the first connection 1.

(66) Alternatively, the computer system 106 generates the key or key pair that is then propagated to the mobile device 102 using any kind of suitable channel, for example, using the first connection 1.

(67) FIG. 8 is a process flow diagram. At step 801, user authentication input is obtained by the user authentication input receiving module 906 of the mobile device 102 in the same manner as in step 201, detailed above.

(68) At step 802, the user authentication input is validated by the user authentication input receiving module 906 of the mobile device 102 as no connection with the security server 110 is available. The user authentication input receiving module 906 of the mobile device 102 validates the user authentication input by comparing it to the record of user authentication inputs associated with the user 104 which are securely stored on the memory 904 of the mobile device 102.

(69) At step 803, if the validation of the user authentication input at the mobile device 102 is unsuccessful, the process is terminated.

(70) At step 804, if the validation of the user authentication input at the mobile device 102 is successful, the mobile device 102 generates an encrypted token using the cryptographic key stored at the mobile device 102.

(71) At step 805, the mobile device 102 either initiates a telephone call with, or receives a telephone call from, the computer system 106 via the first connection 1.

(72) At step 806, the mobile device 102 sends the encrypted token to the computer system 106 via DTMF signaling in the same manner as in step 208. This provides an indication that the user authentication input has been successfully validated to the computer system 106, for the same reasons as already described above in relation to step 208.

(73) At step 807, the computer system 106 receives the token generated by the mobile device 102 via the telecommunication module of the computer system 106, along with the user ID, from the mobile device 102 via DTMF signaling during the telephone call, in the same manner as in step 209.

(74) At step 808, the token validation module of the computer system 106 obtains validation of the token using the cryptographic key stored at the computer system 106 to decrypt the token. Once validation of the token has been obtained by the computer system 106, the computer system 106 can determine that the identity of the user 104 has been successfully validated for the reasons outlined above. As such, the third party user 108 may continue with the call knowing that the identity of the user 104 has been validated.

(75) At step 809, if the validation of the token is unsuccessful, the process is terminated and the computer system 106 either ends the call or attempts to authenticate the identity of a user 104 via other means.

(76) Any of the herein described communications between the various modules of the system described herein may be encrypted and decrypted using conventional encryption methods, as would be understood by the skilled person in the art.

(77) The process flow charts and descriptions thereof herein should not be understood to prescribe a fixed order of performing the method steps described therein. Rather, the method steps may be performed in any order that is practicable.

(78) Generally, any of the functionality described in this text or illustrated in the figures can be implemented using software, firmware (e.g., fixed logic circuitry), programmable or nonprogrammable hardware, or a combination of these implementations.

(79) Methods and processes described herein can be embodied as code (e.g., software code) and/or data. Such code and data can be stored on one or more computer-readable media, which may include any device or medium that can store code and/or data for use by a computer system.