WO2015130734A1

WO2015130734A1 - Two-factor authentication systems and methods

Info

Publication number: WO2015130734A1
Application number: PCT/US2015/017427
Authority: WO
Inventors: Nitesh Saxena; Stanislaw Jarecki
Original assignee: Uab Research Foundation; Uci Institute For Innovation
Priority date: 2014-02-25
Filing date: 2015-02-25
Publication date: 2015-09-03

Abstract

A two-factor authentication system and method can include a server, a client and a device carried by a user. The server can display a web page on a client browser that can be viewed by a user. To authenticate the user to the web page, the server evaluates a user entered password at the client and a response message from the device. The response message can be generated in reply to a challenge message from the server that is routed through the client. The challenge message can be provided to the device as either as an encoded message such as a matrix barcode or the challenge message can be directly communicated to the device through a wireless link. The response message can be provided to the client as either a PIN to be entered by the user, a coded message or through direct communication.

Description

TWO-FACTOR AUTHENTICATION SYSTEMS AND METHODS CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No.

61/944,130, filed February 25, 2014, which application is hereby incorporated by reference in its entirety.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR

DEVELOPMENT

[0002] This invention was made with government support under Grant Number 1209280 awarded by the National Science Foundation. The government has certain rights in the invention.

BACKGROUND

[0003] The present application generally relates to systems and methods for implementing two-factor authentication.

[0004] User authentication is critical to many online (and offline) services. Presently, textual passwords form the most dominant means of user authentication. However, passwords suffer from a number of well-documented security and usability problems. Specifically, the passwords are often "weak," i.e., have low-entropy, short length and non-random characters, due to the human-memorability requirement. As a result, an attacker can build a relatively short dictionary of all possible passwords, which dictionary can be used to guess passwords in an "online" attack. Moreover, the use of passwords for authentication also enables an "offline" dictionary attack, whereby the attacker compromises a service storing, possibly salted, one-way functions (typically hashes) of passwords and recovers these passwords. The offline dictionary attacks are attractive for malicious entities because a single server break-in leads to compromising multiple user accounts. Furthermore, since many users re-use their passwords across multiple services, compromising one service typically also compromises user accounts at many other services.

[0005] To improve the security of password authentication, two-factor authentication

(TFA) incorporates a personal computational device for the user in the authentication process. The device could be a dedicated hardware token or a personal gadget, such as a mobile phone, executing an authentication application. The device creates a short, one-time PIN (personal identification number) that has to be entered, along with the user's password, into the authentication terminal (also referred to as a client) by the user. The PIN and password are then provided to an authentication server (also referred to as a server) for validation. If the PIN is generated via a pseudorandom function whose key is shared by the device and the server, the probability of an attacker's success in an online guessing attack is reduced. However, existing TFA schemes (just like password- only schemes) store a possibly salted, one-way function of the password on the server, and therefore an adversary who compromises the server and learns the password function or hash, can still recover the password and use the recovered password at a different site employing password-only authentication.

[0006] Therefore what is needed are systems and methods to improve the security of

TFA systems against both online guessing attacks and offline dictionary attacks.

SUMMARY

[0007] The present application generally pertains to systems and methods implementing a suite of TFA protocols and mechanisms offering different security and usability levels. With respect to the TFA protocols, a server can store a randomized hash of the password and a device can store the corresponding random secret for the hash. The TFA protocols can then check whether the user types the correct password and owns the device which stores the secret. To secure the TFA protocols against attacks, the device cannot display the secret to the user. The secret can be masked with one-time values derived by a pseudorandom function. In addition, the server can encrypt the onetime mask under the device's public encryption key. If the pseudorandom function is computed on a nonce (a random or pseudo-random number that is used only once) that is based on the current time or chosen as a challenge by the server, the device can output a PIN based on the secret and the pseudorandom function. The server can verify the password and PIN pair provided by the user against the hash by re-computing the secret using the PIN and the pseudorandom function. One security parameter in the TFA protocols can be bound by the bit capacity of the device-to-client (D-to-C) channel, i.e., by the bit-length of the PIN. However, the security properties of the TFA protocols also depend on the existence and the capacity of the client-to-device (C-to-D) channel. The TFA protocols enable different implementations of the D-to-C and C-to-D channels, including a manual PIN entry by the user, a visual matrix or two dimensional (2D) barcode, e.g., a QR (quick response) code, capture, wireless communication and combinations thereof.

[0008] One advantage of the present application is that the TFA protocols are resilient to server compromise.

[0009] Another advantage of the present application is that the TFA protocols can be used with a wide range of devices and bandwidths.

[0010] Other features and advantages of the present application will be apparent from the following more detailed description of the identified embodiments, taken in conjunction with the accompanying drawings which show, by way of example, the principles of the application.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 is a block diagram showing an embodiment of a server.

[0012] FIG. 2 is a block diagram showing an embodiment of a client.

[0013] FIG. 3 is a block diagram showing an embodiment of a device.

[0014] FIG. 4 shows an embodiment of a process for implementing a two-factor authentication scheme.

[0015] FIG. 5 shows an embodiment of the process for executing the initialization phase.

[0016] FIGS. 6-10 show processes for executing an authentication phase for embodiments of a two-factor authentication system.

[0017] FIGS. 1 1 -15 schematically show embodiments of two-factor authentication systems.

[0018] Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or like parts.

DETAILED DESCRIPTION

[0019] A two-factor authentication (TFA) system can include a server, a client, a human user and a device carried by the user. The server can provide a service, application or webpage for one or more users that can be accessed after completing an authentication process. The server can store, for each user, the authentication data and information that is needed for the authentication process in a table indexed by the user names of the users. The client can execute a web browser that can be used by the user to authenticate to (and access) the service, application or web page on the server. The device can be used by the user as a secondary "security token" that is part of the authentication process to authenticate the user's session with the server. The device can be any programmable device capable of storing data, keeping a persistent clock, performing computations, and displaying characters on a screen. In addition, the device may also be able to take photographs or communicate wirelessly, i.e., via electromagnetic or acoustic waves carrying a signal, with another computer or programmable device such as the client.

[0020] The server and the client can communicate over a network, e.g., the Internet, a local area network (LAN) or a wide area network (WAN). The server and the client can rely on a public key infrastructure (PKI) for establishing a secure channel with one-sided authentication of the server by the client. The server can have a public key with an SSL (secure sockets layer) certificate signed by a certification authority recognized by a browser executed by the client. The client and the server can establish an SSL connection via a TLS (transport layer security) handshake using the SSL certificate of the server. To implement the TFA protocol(s) on the client, the client can receive an HTML (hypertext markup language) page (or a web page) from the server using the SSL connection or the client can execute a browser plug-in from a trusted source installed on the client.

[0021] FIG. 1 shows an embodiment of a server. A server 1 10 can include logic 152, referred to herein as "server logic," for generally controlling the operation of the server 1 10. The server 1 10 also includes logic 154, referred to herein as an "authentication engine," for implementing the TFA process and/or protocol and executing the corresponding authentication algorithms for the server 1 10 associated with the TFA process and/or protocol. The server logic 152 and the authentication engine 154 can be implemented in software, hardware, firmware or any combination thereof. In the server 1 10 shown in FIG. 1 , the server logic 152 and the authentication engine 154 are implemented in software and stored in memory 156 of the server 1 10. Note that the server logic 152 and the authentication engine 154, when implemented in software, can be stored and transported on any computer-readable medium for use by or in connection with an instruction execution apparatus that can fetch and execute instructions.

[0022] The server 1 10 can include at least one conventional processing element 158, which has processing hardware for executing instructions stored in memory 156. As an example, the processing element 158 may include a central processing unit (CPU) or a digital signal processor (DSP). The processing element 158 communicates to and drives the other elements within the server 1 10 via a local interface 160, which can include at least one bus. Furthermore, an input interface 162, for example, a keypad, keyboard or a mouse, can be used to input data from a user of the server 1 10, and an output interface 164, for example, a printer, monitor, liquid crystal display (LCD), or other display apparatus, can be used to output data to the user. Further, a communication interface 166 may be used to exchange data with the client and other computing devices. As shown by FIG. 1 , user data 168 and PKI data 170 can be stored in memory 156 at the server 110. The user data 168 can include, for each user, a password and authentication data indexed by user name. The PKI data 170 can include a public key and an SSL certificate to implement a secure channel between the server 1 10 and the client. The server 1 10 can also include a clock 172 or other counting device.

[0023] FIG. 2 shows an embodiment of a client. A client 120 can include logic 202, referred to herein as "client logic," for generally controlling the operation of the client 120. The client 120 also includes logic 204, referred to herein as an "authentication engine," for executing the corresponding authentication algorithms for the client 120 associated with the TFA process and/or protocol. The client logic 202 and the authentication engine 204 can be implemented in software, hardware, firmware or any combination thereof. In the client 120 shown in FIG. 2, the client logic 202 and the authentication engine 204 are implemented in software and stored in memory 206 of the client 120. Note that the client logic 202 and the authentication engine 204, when implemented in software, can be stored and transported on any computer-readable medium for use by or in connection with an instruction execution apparatus that can fetch and execute instructions.

[0024] The client 120 can include at least one conventional processing element 208, which has processing hardware for executing instructions stored in memory 206. As an example, the processing element 208 may include a central processing unit (CPU) or a digital signal processor (DSP). The processing element 208 communicates to and drives the other elements within the client 120 via a local interface 210, which can include at least one bus. Furthermore, an input interface 212, for example, a camera, keypad, keyboard or a mouse, can be used to input data into the client 120, and an output interface 214, for example, a printer, monitor, liquid crystal display (LCD), or other display apparatus, can be used to output data to the user. Further, a communication interface 216 may be used to exchange data with the server 1 10, other computing devices and/or the device. As shown by FIG. 2, browser software 218 and PKI data 220 can be stored in memory 206 at the client 120. The browser software 218 can be any browser that can display web or HTML pages and can include "plug-in" software for use with the browser. The PKI data 220 can include information to implement a secure channel between the client 120 and the server 1 10. [0025] There can be four types of devices that can be used with the authentication systems and methods of the present application. The different device types can be used for different implementations of the authentication process and/or protocols that have different software and hardware demands on both the device and on the client 120 and have different user demands on how information is communicated between the client 120 and the device. In one embodiment, the device can be a hand-held personal device such as a smart phone, a tablet computer, an e-book reader, a smart watch or a dedicated hardware token (e.g., a RSA SecurlD token).

[0026] The first type of device (a Type I device) cannot receive any message from the client 120 during the authentication process, i.e., the execution of the authentication protocol, and can only provide a response message to the client 120. The response message from the device can be short, e.g., up to 20 or 30 bits. In one embodiment, the Type I device can maintain a clock or other updatable state, e.g., a counter. The Type I device may not need any data connectivity, except for a way to periodically synchronize its internal clock (or counter). The Type I device may only have a small screen on which the device can display the response message encoded into a short numerical or alphanumerical string, i.e., a PIN. The user can then read the PIN and type or enter the PIN into the browser on the client 120.

[0027] The second type of device (Type II) can receive a challenge message from the client 120 and can reply with a response message to the client 120. For Type II devices, the challenge message from the client 120 can be medium-sized, e.g., between 100 and 2,000 bits and the response message from the device can be short, e.g., up to 20 or 30 bits. The Type II device can include a camera or image sensor that can capture or photograph a screen display from the browser of the client 120 or other output from the client 120. In one embodiment, the client can display the challenge message for the device in a matrix barcode. The matrix barcode can be used to encode a challenge message of 2,000 bits or more depending on the resolution of the camera or image sensor in the Type II device. The user can position the device near the client 120 to detect and capture the displayed matrix barcode on the device. The device can decode the captured matrix barcode to obtain the challenge message from the client 120 and reply to the challenge message with a response message. The response message can include a PIN displayed on the device. The user can then read the PIN and type or enter the PIN into the browser on the client 120. [0028] The third type of device (Type III) can receive a challenge message from the client

120 and can reply with a response message to the client 120. For Type III devices, the message from the client can be medium-sized, e.g., between 100 and 2,000 bits, and the response from the device can be medium-sized, e.g., between 100 and 2,000 bits. The Type III device can include a camera or image sensor that can capture or photograph a screen display from the browser of the client 120 or other output from the client 120. In addition, the device can include a larger display than a Type II device. In one embodiment, the client 120 can display the challenge message for the device in a matrix barcode. The matrix barcode can be used to encode a challenge message of 2,000 bits or more depending on the resolution of the camera or image sensor in the Type III device. The user can position the device near the client 120 to detect and capture the displayed matrix barcode on the device. The device can decode the captured matrix barcode to obtain the challenge message from the client 120 and reply to the challenge message with a response message. The response message can be encoded in a matrix barcode and displayed on the device. The client 120 can include a camera or image sensor and the user can position the device displaying the matrix barcode so the camera of the client 120 can capture or photograph the matrix barcode.

[0029] The fourth type of device (Type IV) can receive a challenge message from the client

120 and can reply with a response message to the client 120. For Type IV devices, the challenge message from the client 120 can be long, e.g., several thousand bits, and the response message from the device can be long, e.g., several thousand bits. The Type IV device is capable of higher bandwidth communication with the client 120 via a wireless connection, e.g., over Bluetooth® or Wi-Fi®. The device can receive challenge messages from the client 120 over the wireless connection and can reply to the challenge message with a response message. The device can send the response message back to the client 120 over the wireless connection.

[0030] FIG. 3 shows an embodiment of a device. A device 130 can include logic 302, referred to herein as "device logic," for generally controlling the operation of the device 130. The device 130 also includes logic 304, referred to herein as an "authentication engine," for executing the corresponding authentication algorithms for the device 130 associated with the TFA process and/or protocol. The device logic 302 and the authentication engine 304 can be implemented in software, hardware, firmware or any combination thereof. In the device 130 shown in FIG. 3, the device logic 302 and the authentication engine 304 are implemented in software and stored in memory 306 of the device 130. Note that the device logic 302 and the authentication engine 304, when implemented in software, can be stored and transported on any computer-readable medium for use by or in connection with an instruction execution apparatus that can fetch and execute instructions.

[0031] The device 130 can include at least one conventional processing element 308, which has processing hardware for executing instructions stored in memory 306. As an example, the processing element 308 may include a central processing unit (CPU) or a digital signal processor (DSP). The processing element 308 communicates to and drives the other elements within the device 130 via a local interface 310, which can include at least one bus. Furthermore, an input interface 312, for example, a camera, keypad, keyboard or a mouse, can be used to input data into the device 130, and an output interface 314, for example, a liquid crystal display (LCD), or other display apparatus, can be used to output data to the user. Further, a communication interface 316 may be used to exchange data with the client 120 or other computing device. The device 130 can also include a clock 318 or other counting device.

[0032] FIG. 4 shows an embodiment of a process for implementing a TFA scheme. As shown in FIG. 4 the TFA scheme can, for each authentication protocol, execute an initialization algorithm or phase (step 402) prior to a user attempting to authenticate to a service and execute an authentication algorithm or phase (step 404) each time a user wants to authenticate to a service. The authentication algorithm can be executed in separate portions by the server 1 10, the client 120 and the device 130. The initialization algorithm can be executed separately for each user and can have the following inputs: a security parameter; a message parameter that fixes the upper-limit on the bit-length of the response message from the device 130; and the user's password stored on the server 1 10. The initialization algorithm can output a pair of state (or secret) values, i.e., the server state value and the device state value. The server state value is stored by the server 1 10 under the user name of the user in user data 168. The device state value is securely loaded into memory 306 of the device 130 belonging to the user. In one embodiment, the client 120 may not have any permanent state, i.e., the client 120 is considered state-free, and can execute authentication protocol code that is provided by a browser plug-in or is downloaded as a web page from the server 1 10 each time the user authenticates.

[0033] In one embodiment, whenever the user wants to authenticate to the server 1 10 from a browser on the client 120, the client 120 and server 1 10 can establish a secure connection using the server's public key and certificate. The user can specify his or her user name in the browser of the client 120. The user name can be provided to the server 1 10 over the secure connection during the authentication process. The server 1 10 can retrieve the server state value stored under the user name. The server 1 10 can execute the server authentication protocol algorithm to possibly communicate a challenge message to the client 120. The client 120 can execute the client authentication protocol algorithm and can send a challenge message to the device 130 that can be based on or is the challenge message received from the server 1 10. The device 130 can execute the device authentication protocol algorithm using the challenge message from the client 120 and the device state value to generate a response message for the client 120. In one embodiment, for devices 130 that do not have data connectivity, i.e., Type I devices, the message from the client 120 to the device 130 can be fixed as a special sign, e.g., opening an application on the device 130, that triggers the device 130 to compute the response message and does not include or carry further information. The sever authentication protocol algorithm, after receiving the response message and the user-entered password from the client 120, can then output a bit that designates whether or not the user has been authenticated.

[0034] In one embodiment, a TFA scheme can additionally rely on a synchronized clock between the device 130 and the server 1 10 and can be referred to as time-based. If the synchronized clock is used, then the sever authentication protocol algorithm and the device authentication protocol algorithm each have an additional time-encoding input. The output bit from the sever authentication protocol algorithm can be one (designating that the user is authenticated) only if the server time-encoding input is equal to the device time-encoding input. In another embodiment, the TFA scheme can use updatable storage in both the server 1 10 and the device 130 to provide a strictly increasing counter and can be referred to as counter-based. The output bit from the sever authentication protocol algorithm can be one (designating that the user is authenticated) only if the server counter and the device counter are synchronized or equal.

[0035] Four different TFA protocols can be used in the present application. Each of the

TFA protocols can be executed given any bandwidth limit of f bits for the response message sent from the device 130 to the client 120, i.e., the message parameter. The first protocol, referred to as "TFA-T," is a time-based TFA protocol that can be used with all devices 130. The devices 130 used with the TFA-T protocol can use a clock synchronized with the server 1 10 (or, alternatively, a synchronized counter). The second protocol, referred to as "TFA-SC," is a symmetric-key based TFA protocol that can be used with devices 130 that can receive a single challenge message from the client 120 during the TFA protocol execution. The third protocol, referred to as "TFA-PC," is a public-key based TFA protocol that can be used with devices 130 that can receive a single challenge message from the client 120 during the TFA protocol execution. The fourth protocol, referred to as "TFA-PC-Alt," is a variant of protocol TFA-PC, which reduces the bandwidth requirements of TFA-PC by replacing public key encryption with a key encapsulation mechanism. In one embodiment, the TFA-SC protocol can have a C-to-D message length of 80 bits, the TFA-PC protocol can have a C-to-D message length of 344 bits and the TFA- PC-Alt protocol can have a C-to-D message length of 196 bits.

[0036] The TFA-T protocol can use a collision-resistant hash (CRH) function that can be modeled as a random oracle and a pseudorandom function (PRF). Since the TFA-T protocol is a time-based protocol, the sever authentication protocol algorithm and the device authentication protocol algorithm can each have an additional time-encoding input, i.e., a server time-encoding input and a device time-encoding input. The initialization algorithm can determine a first (s) parameter based on the supplied message parameter and a second (/ ) parameter or key based on the supplied security parameter. The initialization algorithm can then compute a third (h) parameter or hash value using the CRH function with the s parameter and the stored user password as inputs. The initialization algorithm then sets the device state value based on the s parameter and the k parameter and sets the server state value based on the h parameter and the k parameter.

[0037] The device authentication protocol algorithm can then compute a fourth (r) parameter or random value using the PRF function with the device time encoding input. The device authentication protocol algorithm can then compute the response message based on the s parameter from the device state value and the r parameter. The device authentication protocol algorithm can then send the response message to the client 120. The client authentication protocol algorithm can receive the response message and can send a message to the server 1 10 that includes the response message and a password entered into the client 120 by the user. The server authentication protocol algorithm can then compute a separate r parameter using the PRF function with the server time encoding input. The server authentication protocol algorithm can then accept the user authentication if the h parameter from the server state value is equal to the output or hash value of the CRH function with the password entered by the user, the response message and the r parameter as inputs.

[0038] The TFA-SC protocol is very similar to the TFA-T protocol and is different only in how the r parameter is computed by the device authentication protocol algorithm and the server authentication protocol algorithm. The PRF functions use a nonce selected by the server 1 10 instead of the time-encoding input. The initialization algorithm can determine a first (s) parameter based on the supplied message parameter and a second (k) parameter or key based on the supplied security parameter. The initialization algorithm can then compute a third (h) parameter or hash value using the CRH function with the s parameter and the stored user password as inputs. The initialization algorithm then sets the device state value based on the s parameter and the k parameter and sets the server state value based on the h parameter and the k parameter.

[0039] The server authentication protocol algorithm can then select a fourth (x) parameter or nonce based on a second security parameter. The second security parameter can be derived from a positive linear function of the security parameter. The server authentication protocol algorithm can then send the x parameter in a challenge message to the client 120. The client authentication protocol algorithm sends the x parameter in a challenge message to the device 130. The device authentication protocol algorithm can then compute a fifth (r) parameter or random value using the PRF function with the x parameter. The device authentication protocol algorithm can then compute the response message based on the s parameter from the device state value and the r parameter. The device authentication protocol algorithm can then send the response message to the client 120. The client authentication protocol algorithm can receive the response message and can send a message to the server 1 10 that includes the response message and a password entered into the client 120 by the user. The server authentication protocol algorithm can then compute a separate r parameter using the PRF function with the x parameter. The server authentication protocol algorithm can then accept the user authentication if the h parameter from the server state value is equal to the output or hash value of the CRH function with the password entered by the user, the response message and the r parameter as inputs.

[0040] The TFA-PC protocol and TFA-PC-Alt protocols modify the TFA-SC protocol (and the TFA-T protocol) by having the random challenge, i.e., the r parameter, agreed-upon using a public-key encryption for which the server 1 10 has the encryption key and the device 130 has decryption key. The TFA-PC protocol uses the CRH function, a semantically-secure public key encryption (PKE) and an unforgeable message authentication code (MAC). The MAC can be added to the ciphertext encrypting the r parameter computed under a symmetric key shared by the server 1 10 and device 130. The PKE functionality can include a first PKE function (Kg), a second PKE function (Enc) and a third PKE function (Dec). The MAC functionality can include a first MAC function (M g), a second MAC function (Mac) and a third MAC function (Ver). [0041] The initialization algorithm can determine a first (s) parameter based on the supplied message parameter and a second (k) parameter or key using the Mkg function with the supplied security parameter. The initialization algorithm can compute an encryption key and a decryption key pair using the Kg function with the security parameter as an input. The initialization algorithm can then compute a third (n) parameter or hash value using the CRH function with the s parameter and the stored user password as inputs. The initialization algorithm then sets the device state value based on the s parameter, the decryption key and the k parameter and sets the server state value based on the h parameter, encryption key and the k parameter.

[0042] The server authentication protocol algorithm can determine a fourth (r) parameter based the message parameter from the s parameter. The sever authentication protocol algorithm can encrypt a fifth (c) parameter using the Enc function with the encryption key and the r parameter as inputs. The sever authentication protocol can compute a sixth (o) parameter using the Mac function with the k parameter and the c parameter as inputs. The server authentication protocol algorithm sends the c parameter and the σ parameter in a challenge message to the client 120. The client authentication protocol algorithm sends the c parameter and the σ parameter in a challenge message to the device 130. The device authentication protocol algorithm stops the authentication process if the output of the Ver function having the k parameter, the c parameter and the σ parameter as inputs is not equal to one (1 ). Otherwise, the device authentication protocol algorithm can then decrypt the r parameter from the Dec function having the c parameter and the k parameter as inputs. The device authentication protocol algorithm can then compute the response message based on the s parameter from the device state value and the r parameter. The device authentication protocol algorithm can then send the response message to the client 120. The client authentication protocol algorithm can receive the response message and can send a message to the server 1 10 with the response message and a password entered into the client 120 by the user. The server authentication protocol algorithm can then accept the user authentication if the h parameter from the server state value is equal to the output or hash value of the CRH function with the password entered by the user, the response message and the r parameter as inputs.

[0043] The TFA-PC-ALT protocol is a variant of the TFA-PC protocol. In the TFA-PC-ALT protocol, the public key encryption from the TFA-PC protocol is replaced with a key encapsulation mechanism (KEM). The KEM functionality can include a first KEM function (Kg), a second KEM function (Enc) and a third KEM function (Dec). The initialization algorithm can determine a first (s) parameter based on the supplied message parameter. The initialization algorithm can compute an encryption key, a decryption key and a second (C) parameter pair using the Kg function with the supplied security parameter and the supplied message parameter as inputs. The initialization algorithm can then compute a third (h) parameter or hash value using the CRH function with the s parameter and the stored user password as inputs. The initialization algorithm then sets the device state value based on the s parameter and the decryption key and sets the server state value based on the h parameter and the encryption key.

[0044] The sever authentication protocol algorithm can generate a fourth (c) parameter and a fifth (r) parameter pair using the Enc function with the encryption key from the server state value as an input. The server authentication protocol algorithm can then send the c parameter in a challenge message to the client 120. The client authentication protocol algorithm sends the c parameter in a challenge message to the device 130. The device authentication protocol algorithm stops the process if the c parameter is not an element of the C parameter. Otherwise, the device authentication protocol algorithm can then decrypt the r parameter from the Dec function having the c parameter and the decryption key from the device state value as inputs. The device authentication protocol algorithm can then compute the response message based on the s parameter from the device state value and the r parameter. The device authentication protocol algorithm can then send the response message to the client 120. The client authentication protocol algorithm can receive the response message and can send a message to the server 1 10 that includes the response message and a password entered into the client 120 by the user. The server authentication protocol algorithm can then accept the user authentication if the h parameter from the server state value is equal to the output or hash value of the CRH function with the password entered by the user, the response message and the r parameter as inputs.

[0045] In one embodiment, for the TFA-PC protocol, the client 120 can send the user name to the server 1 10 to permit the server authentication protocol algorithm to retrieve the server state value at the beginning of the server authentication protocol algorithm. However, in the TFA-T protocol, the TFA-SC protocol, and the TFA-PC-Alt protocol, if all the users are initialized using the same security parameter (and second security parameter in the case of the TFA-SC parameter) then the server authentication protocol algorithm only needs the server state value in the last step (user acceptance) and the client authentication protocol algorithm can send the user name in the message to the server 1 10 that includes the response message and a password entered by the user. [0046] In another embodiment, if a TFA protocol is implemented on a Type III or Type IV device so the response message to the client 120 can include more information and if the D-to-C channel is authenticated or because the device 130 and the client 120 can establish authentication keys in the initialization process, then the device authentication protocol algorithm can include a hash of the server's public key in the response message. The client authentication protocol algorithm can confirm that the SSL session with the server 1 10 is established under the correct public key from the server 1 10 before sending the message to server 1 10.

[0047] To further clarify the operation of the TFA scheme, several embodiments of different

TFA systems or mechanisms implementing different TFA protocols are described. The TFA systems can be categorized based on: (1 ) the underlying device type, e.g., a low- bandwidth device (LBD) that includes Type I and Type II devices, a mid-bandwidth device (MBD) that includes Type III devices and a full-bandwidth device (FBD) that includes Type IV devices; (2) the underlying communication methods for the C-to-D and/or D-to-C channels; and (3) the underlying protocol, e.g., TFA-T, TFA-SC, TFA-PC and TFA-PC-Alt.

[0048] Before using any of the TFA systems, the user has to register with the service or web site on server 1 10 deploying the TFA system. The user registration can be completed by executing the initialization phase or algorithm a single time and reusing the information for subsequent uses. FIG. 5 shows an embodiment of the process for executing the initialization phase. The process begins with the server 1 10 and the device 130 agreeing upon the selection of the protocol parameters and keys for the TFA protocol being used (step 502). In one embodiment, the protocol parameters and keys can follow a generic URI (uniform resource identifier) syntax. Next, the server 1 10 can transfer set-up information to the device 130 (step 504). The set-up information can include one or more of the protocol type, the service domain name, any encryption keys, a secret value, and the PRF key. In one embodiment, the transfer between the server 1 10 and the device 130 can be accomplished with matrix barcodes using the client 120 as an intermediary. The server 1 10 can embed the set-up information into a matrix barcode and provide the matrix barcode to the client 120. The device 130 can then capture the matrix barcode from the client 120. The device 130 can interpret the captured matrix barcode with an application on the device 130 for two-factor authentication.

[0049] The server 1 10 can store user account information (step 506) to be used for each execution of the authentication process. The user account information stored by the server 1 10 can include the protocol type, the user name, a random salt value, a salted hash of the user's password, a key, and the public key for the device 130 if the TFA-PC protocol is used. In one embodiment, the random salt value can be 128 bits and the key can be 128 bits. The device 130 can store authentication information (step 508) to be used for each execution of the authentication process. The authentication information can include the domain name, a key, a secret parameter, and the private key for the device 130 if the TFA- PC protocol is used. In one embodiment, the secret parameter can be 19 bits for LBD devices and 128 bits for FBD devices. The user name is not stored on the device 130 unless the user has more than one account with a service. By not storing the user name on the device 130, an attacker, who compromises the device 130, is prevented from determining the user account that corresponds to the key stored on the device 130. The domain name of the service is stored on the device to identify different services requiring the TFA process.

[0050] FIGS. 6-10 show embodiments of processes for executing an authentication phase in the embodiments of two-factor authentication systems shown in FIGS. 1 1-15. FIG. 6 shows an embodiment of authentication phase for an LBD using a PIN for the TFA system shown in the embodiment of FIG. 1 1. The process can use the TFA-T protocol and begins with a user 140 launching an authentication application on the device 130 and identifying the service on the server 1 10 for authentication. The device can then create a PIN (step 602) from the s parameter and a PRF computation of the current device time-encoding input or timestamp using the k parameter and display the PIN on the device 130. In one embodiment, the PIN can be 19 bits encoded into 6 digits and/or characters. The user 140 then manually enters or copies the PIN into the client 120 (step 604) and enters the user's user name and password. The client 120 can then submit the client response, i.e., the PIN and the user's user name and password, to the server 1 10 (step 606). The server 110 evaluates the client response (step 608) by computing the PRF using the k parameter on the server time-encoding input or timestamp and can authenticate the user, if appropriate. In one embodiment, the device 130 can generate a new or fresh PIN every 30 seconds and the user 140 can be provided with 1 minute to copy the PIN into the client 120.

[0051] FIG. 7 shows an embodiment of authentication phase for an LBD using a PIN and an encoded message for the TFA system shown in the embodiment of FIG. 12. The process can use the TFA-SC protocol or the TFA-PC protocol and begins with the server 1 10 generating a random challenge (step 702). In one embodiment, the random challenge can have 128 bits. If the TFA-PC protocol is used, the server 1 10 can encrypt the random challenge with the encryption key and authenticate the resulting ciphertext using the k parameter. The server 1 10 can then encode the random challenge (either the random challenge itself if using the TFA-SC protocol or the encrypted and authenticated random challenge if using the TFA-PC protocol) and the domain name into an encoded challenge message, e.g., a matrix or 2D barcode, and send the encoded challenge message or matrix barcode to the client 120 (step 704). The user 140 can then capture or take a picture of the encoded challenge message or matrix barcode displayed on the client 120 using the device 130 (step 706). The device 130 can then process the contents of the encoded challenge message or matrix barcode, verify the encoded challenge message or matrix barcode and produce, per the corresponding authentication protocol being used, a response PIN (step 708). In one embodiment, the PIN can be 19 bits encoded into 6 digits and/or characters. The user 140 then manually enters or copies the PIN into the client 120 (step 710) and enters the user's password. The client 120 can then submit the client response, i.e., the PIN and the user's password, to the server 1 10 (step 712). The server 1 10 evaluates the client response (step 714) based on the received information and can authenticate the user if appropriate. If the TFA-SC protocol is being used, the user 140 can include the user's user name in the client response. However, if the TFA-PC protocol is being used, the client 120 has to send the user's user name to the server 1 10 before sending the client response.

FIG. 8 shows an embodiment of authentication phase for an MBD using encoded messages for the TFA system shown in the embodiment of FIG. 13. The process can use the TFA-SC protocol or the TFA-PC protocol and begins with the server 1 10 generating a random challenge (step 802). In one embodiment, the random challenge can have 128 bits. If the TFA-PC protocol is used, the server 1 10 can encrypt the random challenge with the encryption key and authenticate the resulting ciphertext using the k parameter. The server 1 10 can then encode the random challenge (either the random challenge itself if using the TFA-SC protocol or the encrypted and authenticated random challenge if using the TFA-PC protocol) and the domain name into an encoded challenge message, e.g., a matrix or 2D barcode, and send the encoded challenge message or matrix barcode to the client 120 (step 804). The user 140 can then capture or take a picture of the encoded challenge message or matrix barcode displayed on the client 120 using the device 130 (step 806). The device 130 can then process the contents of the encoded challenge message or matrix barcode, verify the encoded challenge message or matrix barcode and produce, per the corresponding authentication protocol being used, a response message that is encoded into an encoded response message or matrix barcode (step 808). In one embodiment, the response message can be between 20-128 bits. The client 120 can then capture or take a picture of the encoded response message or matrix barcode displayed on the device 130 using a camera and corresponding image capture software on the client 120 (step 810). The user 140 can position the device 130 in the field of view of the camera of the client 120 to permit the camera of the client 120 to capture the matrix barcode. The client 120 can then process the contents of the encoded message or matrix barcode and forward the decoded response message from the device 130 with the user name and/or password to the server 1 10 (step 812). The server 1 10 evaluates the client response (step 814) based on the received information and can authenticate the user if appropriate. If the TFA-SC protocol is being used, the user 140 can include the user's user name in the client response. However, if the TFA-PC protocol is being used, the client 120 has to send the user's user name to the server 1 10 before sending the client response.

[0053] FIG. 9 shows an embodiment of authentication phase for an FBD using wireless communications for the system shown in the embodiment of FIG. 14. The process can use the TFA-SC protocol or the TFA-PC protocol and begins with the server 1 10 generating a random challenge (step 902). In one embodiment, the random challenge can have 128 bits. If the TFA-PC protocol is used, the server 1 10 can encrypt the random challenge with the encryption key and authenticate the resulting ciphertext using the k parameter. The server 1 10 can then send the random challenge (either the random challenge itself if using the TFA-SC protocol or the encrypted and authenticated random challenge if using the TFA-PC protocol) in a message to the client 120 (step 904). The client 120 can transfer the challenge message over a bi-directional wireless connection, e.g., Bluetooth or Wi-Fi, to the device 130 (step 906). The device 130 can process the challenge message and produce, per the corresponding authentication protocol being used, a response message (step 908). In one embodiment, the response message can be 128 bits. The device 130 can then transmit the response message to the client over the wireless connection (step 910). The client 120 can then forward the response message from the device 130 with the user name and/or password to the server 1 10 (step 912). The server 1 10 evaluates the client response (step 914) based on the received information and can authenticate the user if appropriate. If the TFA-SC protocol is being used, the user 140 can include the user's user name in the client response. However, if the TFA-PC protocol is being used, the client 120 has to send the user's user name to the server 1 10 before sending the client response.

[0054] In one embodiment, the device 130 can implement a Bluetooth channel as a mobile application operating in server mode by listening on a RFCOMM (radio frequency communication) socket. The RFCOMM socket can be addressed using a UUID (universally unique identifier) in accordance with the Serial Port Profile (SPP). The client 120 can execute a browser extension that employs the use of the Bluetooth API (application programming interface). The device 130 executes the mobile application in the background to establish connectivity. The Bluetooth API enables the web browser at the client 120 to operate in either client or server mode. A packaged extension can instruct the browser at the client 120 to load the authentication page stored on the server 1 10. When the user 140 initiates the log in process, the web site hosted on the server 1 10 calls the extension using a well-known ID (a signature to uniquely identify the extension) with the challenge sent by the server 1 10 as input. The extension (1 ) establishes Bluetooth connectivity using the Bluetooth adapter address of the device 130 (which is provided to the client 120 during the initialization phase) rather than going through the process of device discovery during the authentication session, (2) sends the challenge to the device 130, (3) receives the response message or PIN (128 bits or more), and (4) returns the response to the browser. The browser then sends the response including the password to the server 1 10 which then authenticates the user 140, if appropriate.

[0055] In this embodiment, a paired Bluetooth connection can be used although the protocols do not require the client/device channel to be secure. The one-time pairing can be established during the initialization phase after which the client 120 and the device 130 can take part in the authentication process without involvement from the user 140 (except for the launching of the application). The pairing process can be repeated whenever the user roams over to another client 120. In a further embodiment, an unpaired (insecure) Bluetooth connection can be established, but the unpaired connection requires a new NPAPI (Netscape Plugin Application Programming Interface) plugin embedded with the browser extension. In this embodiment, the challenge can be encoded in a matrix barcode and is shown on the web page for capturing by the device 130.

[0056] In another embodiment, the device 130 and the client 120 can utilize Wi-Fi as a bidirectional communication medium. Ad hoc mode Wi-Fi is a point-to-point infrastructureless wireless channel that can be formed with Wi-Fi adaptors equipped on the device 130 and the client 120. However, some clients 120 may dedicate their wireless adaptor to an Internet connection, which may render ad hoc Wi-Fi unavailable for the D- to- C channel. To address the possible constraint on Wi-Fi communication as a result of the Internet connection of the client 120, the device 130 and the client 120 may be connected using Virtual Wi-Fi or a Wireless Hosted Network. [0057] Virtual Wi-Fi features two coexisting functionalities: 1 ) virtualizing a physical wireless adapter; and 2) executing a software-based wireless access point (SoftAP). Virtual Wi-Fi can be used to establish a direct connection between the client 120 and the device 130 upon a request from the server 1 10 in order to transfer a challenge to the device 130 through the client 120 and receive a response back whenever the wireless adaptor of the client 120 is serving other networks. Therefore, by virtualizing one physical wireless adapter, the device 130 and client 120 can be connected while the user 140 is surfing the web or otherwise using the wireless adaptor on the client 120. To address security concerns, a static key can be specified and hard-coded or incorporated into the virtual Wi-Fi applications. After the wireless connection is established between the client 120 and the device 130, applications on the two sides can communicate back and forth.

[0058] In one embodiment, a packaged application can be titled "TFA-Wi-Fi-App" and can be launched on the client 120. TFA-Wi-Fi-App can relay challenges received from the web page on the server 1 10 to the device 130 and receive the response from the device 130 and forward it to the server 110. A UDP (user datagram protocol) channel can be used for communication between the client 120 and the device 130. Every time the user 140 opens a login web-page, the server 1 10 sends a challenge, which initiates or fires a function in TFA-Wi-Fi-App to "multicast" the challenge on the created UDP socket to the device 130. The device 130 receives the datagram packet, processes it, creates a response and sends it back on the UDP socket to the TFA-Wi-Fi-App to be forwarded to the server 1 10.

[0059] FIG. 10 shows an embodiment of authentication phase for an FBD using encoded messages and wireless communications for the system shown in the embodiment of FIG. 15. The process can use the TFA-SC protocol or the TFA-PC protocol and begins with the server 1 10 generating a random challenge (step 1002). In one embodiment, the random challenge can have 128 bits. If the TFA-PC protocol is used, the server 1 10 can encrypt the random challenge with the encryption key and authenticate the resulting ciphertext using the k parameter. The server 1 10 can then encode the random challenge (either the random challenge itself if using the TFA-SC protocol or the encrypted and authenticated random challenge if using the TFA-PC protocol) and the domain name into an encoded challenge message or matrix or 2D barcode and send the encoded challenge message or matrix barcode to the client 120 (step 1004). The user 140 can then capture or take a picture of the encoded challenge message or matrix barcode displayed on the client 120 using the device 130 (step 1006). The device 130 can then process the contents of the encoded challenge message or matrix barcode, verify the encoded challenge message or matrix barcode and produce, per the corresponding authentication protocol being used, a response message (step 1008). In one embodiment, the response message can be 128 bits. The device 130 can then transmit the response message to the client over the wireless connection (step 1010). The client 120 can then forward the response message from the device 130 with the user name and/or password to the server 1 10 (step 1012). The server 1 10 evaluates the client response (step 1014) based on the received information and can authenticate the user, if appropriate. If the TFA-SC protocol is being used, the user 140 can include the user's user name in the client response. However, if the TFA-PC protocol is being used, the client 120 has to send the user's user name to the server 1 10 before sending the client response.

[0060] In one embodiment, the server 1 10 can be a web server maintaining and accessing a user accounts database to authenticate each user identified with a unique user name. In another embodiment, the server 1 10 can communicate with the client 120 over a secure SSL channel. The client 120 can communicate with the device 130 over mix-bandwidth channels, formed using manual PIN entry, encoded messages, e.g., matrix barcodes, wireless communication and combinations thereof. The device can execute a TFA authentication application (TFA-App).

[0061] In another embodiment, the server 1 10 can be an Apache® web server with

MySQL® database running server-side PHP scripts. The client 120 can be a terminal having an HTML or HTML 5 browser when used with an LBD or a MBD. The client 120 can be a terminal having a browser extension written in JavaScript® programming language when used with an FBD. The device 130 can be a smartphone or tablet computer executing a mobile operating system, e.g., Android™ operating system or iOS® operating system. The matrix or 2D barcode can be a QR (quick response) code that can be encoded and/or decoded, when needed, using the ZXing library.

[0062] Although the figures herein may show a specific order of method steps, the order of the steps may differ from what is depicted. Also, two or more steps may be performed concurrently or with partial concurrence. Variations in step performance can depend on the software and hardware systems chosen and on designer choice. All such variations are within the scope of the application. Software implementations could be accomplished with standard programming techniques, with rule based logic and other logic to accomplish the various connection steps, processing steps, comparison steps and decision steps. It should be understood that the identified embodiments are offered by way of example only. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present application. Accordingly, the present application is not limited to a particular embodiment, but extends to various modifications that nevertheless fall within the scope of the application. It should also be understood that the phraseology and terminology employed herein is for the purpose of description only and should not be regarded as limiting.

Claims

CLAIMS What is claimed is:

1. A system to implement two-factor authentication, the system comprising:

a server, the server being operable to execute a server authentication algorithm stored on the server, the server authentication algorithm implementing an authentication protocol on the server, the authentication protocol implementing two-factor authentication for an application stored on the server;

a client in communication with the server, the client being operable to execute a client authentication algorithm, the client authentication algorithm implementing the authentication protocol on the client, the client comprising a browser operable to permit a user to access the application on the server;

a device, the device being operable to execute a device authentication algorithm stored on the device, the device authentication algorithm implementing the authentication protocol on the device;

the device authentication algorithm being operable to generate a response message for the server in response to receiving an input at the device;

the client authentication algorithm being operable to generate a client message for the server in response to receiving the response message from the device, the client message including the response message and a password entered by a user in the browser; and

the server authentication algorithm being operable to receive the client message and decide to authenticate a user to the application using the response message and the password.

2. The system of claim 1 wherein the client authentication algorithm is stored on the client as one of:

a plug-in application for the browser; or

a web page provided to the client by the application on the server.

3. The system of claim 1 wherein the server authentication algorithm is operable to generate a challenge message and provide the challenge message to the client.

4. The system of claim 3 wherein:

the client authentication algorithm is operable to display the challenge message as an encoded message on the client; and

the input to the device authentication algorithm is a captured image of the encoded message displayed on the client, the captured image of the encoded message being provided by an image sensor in the device.

5. The system of claim 4 wherein:

the device authentication algorithm is operable to display the response message as an encoded message on the device; and

the client authentication algorithm is operable to receive the response message as a captured image of the encoded message displayed on the device, the captured image of the response message being provided by an image sensor in the client.

6. The system of claim 4 wherein the device authentication algorithm is operable to wirelessly transmit the response message to the client.

7. The system of claim 4 wherein:

the device authentication algorithm is operable to display the response message as a personal identification number on the device; and

the client authentication algorithm is operable to receive the response message from a manual entry of the personal identification number by the user viewing the device.

8. The system of claim 3 wherein:

the client authentication algorithm is operable to wirelessly transmit the challenge message to the device and the input to the device authentication algorithm is the received challenge message from the client; and

the device authentication algorithm is operable to wirelessly transmit the response message to the client.

9. The system of claim 1 further comprises:

the input to the device authentication algorithm is the user launching the device authentication algorithm on the device;

10. The system of claim 9 wherein:

the server authentication algorithm has a first time encoded input;

the device authentication algorithm has a second time encoded input used to generate the response message; and

the server authentication algorithm is operable to decide to authenticate a user to the application using the response message, the password and the first time encoded input.

1 1. A two-factor authentication method comprising:

generating a challenge message at a server in response to a user accessing a web page on the server with a web browser on a client;

sending the challenge message to the client;

transferring the challenge message from the client to a device;

preparing, by the device, a response message to the transferred challenge message;

transferring the response message from the device to the client;

submitting, by the client, the response message and a password entered by the user to the server; and

evaluating, by the server, the response message and the password to authenticate the user to the web page.

12. The method of claim 1 1 wherein said transferring the challenge message from the client to a device includes transferring the challenge message from the client to the device over a wireless connection.

13. The method of claim 1 1 wherein said transferring the response message from the device to the client includes transferring the response message from the device to the client over a wireless connection.

14. The method of claim 1 1 wherein said transferring the challenge message from the client to a device includes:

encoding the challenge message in a matrix code;

displaying the matrix barcode on the client; and

receiving a captured image of the displayed matrix barcode at the device.

15. The method of claim 1 1 wherein said transferring the response message from the device to the client includes:

generating a personal identification number corresponding to the response message;

displaying the personal identification number on the device; and

receiving an entry of the personal identification number by the user at the client.

16. The method of claim 1 1 wherein said transferring the response message from the device to the client includes:

encoding the response message in a matrix code;

displaying the matrix barcode on the device; and

receiving a captured image of the displayed matrix barcode at the client.

17. The method of claim 1 1 further comprises completing an initialization phase prior to said generating a challenge message.

18. The method of claim 17 wherein said completing an initialization phase includes: selecting an authentication protocol;

storing user information to be used by the selected authentication protocol;

transferring set-up information relating to the selected authenticated protocol to the device; and

storing the transferred set-up information on the device.

19. The method of claim 1 1 wherein said evaluating the response message includes: calculating a hash value with the response message;

comparing the calculated hash value to a stored hash value; and

authenticating the user in response to the calculated hash value matching the stored hash value.

20. The method of claim 1 1 wherein said generating a challenge message includes encrypting the challenge message using public key encryption.