Systems and methods for efficient challenge-response authentication

Abstract

[0006] Systems, apparatus, methods, and machine-readable media for fast authentication are described. For example, one embodiment of the system includes a client device local challenge generator for generating a challenge on the client device using a derivation function, and an authentication engine on the client device for generating a challenge response defined by a specified challenge response protocol, where the authentication engine sends the challenge response to a server, and the server verifies the challenge response, at least in part, by determining whether the challenge was generated within a specified time window.

Description

[Technical Field]

[0001] The present invention relates generally to the field of data processing systems, and more particularly to a system and method for efficient challenge-response authentication. [Background technology]

[0002] FIG. 1 illustrates an exemplary client 120 having a biometric authentication device 100. During normal operation, a biometric sensor 102 reads raw biometric data from a user (e.g., captures the user's fingerprint, records the user's voice, takes a snapshot of the user, etc.), and a feature extraction module 103 extracts specified characteristics of the raw biometric data (e.g., focuses on specific regions of the fingerprint, specific facial features, etc.). A matcher module 104 compares the extracted features 133 to biometric reference data 110 stored in secure storage on the client 120 and generates a score based on the similarity between the extracted features and the biometric reference data 110. The biometric reference data 110 is typically the result of an enrollment process in which a user enrolls a fingerprint, voice sample, image, or other biometric data with the device 100. An application 105 may then use the score to determine whether authentication is successful (e.g., whether the score is above a certain specified threshold).

[0003] 1 is oriented toward biometric authentication, various other or additional authentication techniques may be employed on exemplary client 120. For example, the client-side authenticator may be based on a PIN or other secret code (e.g., a password) entered by the user and / or may be triggered based on the user's presence (e.g., a button the user presses to verify presence).

[0004] Systems are designed to provide secure user authentication over a network using biometric sensors. In such systems, scores and / or other authentication data generated by an application may be sent over a network to authenticate the user with a remote server. For example, U.S. Patent Application Publication No. 2011 / 0082801 (the "'801 Application") describes a framework for user registration and authentication over a network that provides strong authentication (e.g., protection against identity theft and phishing), secure transactions (e.g., protection against "malware-in-the-browser" and "man-in-the-middle" attacks on transactions), and registration / management of client authentication tokens (e.g., fingerprint readers, facial recognition devices, smart cards, trusted platform modules, etc.).

[0005] The assignee of the present patent application has developed various improvements to the authentication framework described in the '801 application, some of which are described in the following group of U.S. patent applications (the "co-pending applications"), all of which were assigned to the assignee of the present application on December 29, 1992, and which are incorporated herein by reference: Serial No. 13 / 730,761, "Query System and Method to Determine Authentication Capabilities"; Serial No. 13 / 730,776, "System and Method for Efficiently Enrolling, Registering, and Authenticating With Multiple Authentication Devices"; Serial No. 13 / 730,780, "System and Method for Processing Random Challenges Within an Authentication Framework"; Serial No. 13 / 730,791, "System and Method for Implementing Privacy Classes Within an Authentication Framework"; and Serial No. 13 / 730,795, "System and Method for Implementing Transaction Signaling Within an Authentication Framework."

[0006] Briefly, the co-pending application describes an authentication technique in which a user enrolls in an authentication device (or authenticator), such as a biometric authentication device (e.g., a fingerprint sensor) on a client device. When a user enrolls with a biometric authentication device, biometric reference data is captured (e.g., by swiping a finger, snapping a photo, recording voice, etc.). The user can then register the authentication device with one or more servers over a network (e.g., websites or other relying parties equipped with secure transaction services as described in the co-pending application) and subsequently authenticate with those servers using data exchanged during the registration process (e.g., cryptographic keys provisioned to the authentication device). Once authenticated, the user is permitted to conduct one or more online transactions with the website or other relying party. In the framework described in the co-pending application, sensitive information, such as fingerprint data and other data that can be used to uniquely identify a user, may be kept local to the user's authentication device to protect the user's privacy.

[0007] A better understanding of the present invention can be obtained from the following detailed description taken in conjunction with the following drawings. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 illustrates an exemplary client device with biometric authentication capabilities. [Figure 2A] 1A-1D illustrate two different embodiments of a secure authentication system architecture. [Figure 2B] 1A-1D illustrate two different embodiments of a secure authentication system architecture. [Figure 2C] FIG. 1 is a transaction diagram illustrating how a key can be registered with an authentication device. [Figure 3A] FIG. 1 illustrates an embodiment of secure transaction confirmation using a secure display. [Figure 3B]FIG. 1 illustrates an embodiment of secure transaction confirmation using a secure display. [Figure 4] FIG. 1 illustrates one embodiment of the present invention providing authentication for transactions with unrelated devices. [Figure 5A] FIG. 1 is a transaction diagram illustrating two different embodiments of performing authentication for a transaction. [Figure 5B] FIG. 1 is a transaction diagram illustrating two different embodiments of performing authentication for a transaction. [Figure 6] FIG. 2 illustrates additional architectural features employed in one embodiment of the present invention. [Figure 7] 10A-10C illustrate different embodiments of bearer tokens for use in different embodiments of the present invention. [Figure 8] 10A-10C illustrate different embodiments of bearer tokens for use in different embodiments of the present invention. [Figure 9] FIG. 1 illustrates exemplary “offline” and “semi-offline” authentication scenarios. [Figure 10] FIG. 1 illustrates an example system architecture for a client and / or server. [Figure 11] FIG. 1 illustrates another exemplary system architecture for a client and / or server. [Figure 12] FIG. 1 illustrates an example challenge-response authentication protocol and system. [Figure 13] FIG. 1 illustrates an embodiment in which a client device generates a challenge locally. [Figure 14] FIG. 1 illustrates an embodiment of a time tolerance window. DETAILED DESCRIPTION OF THE INVENTION

[0009] Described below are embodiments of apparatuses, methods, and machine-readable media for implementing advanced authentication techniques and related applications. Throughout the description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are not shown, or are shown in block diagram form, in order to avoid obscuring the underlying principles of the present invention.

[0010] The embodiments of the invention discussed below involve client devices equipped with authentication capabilities such as biometric authentication devices or PIN entry. These devices may be referred to herein as “tokens,” “authentication devices,” or “authenticators.” While certain embodiments focus on facial recognition hardware / software (e.g., cameras and associated software for recognizing a user's face and tracking the user's eye movements), some embodiments may utilize additional biometric authentication devices including, for example, fingerprint sensors, voice recognition hardware / software (e.g., microphones and associated software for recognizing a user's voice), and optical recognition capabilities (e.g., optical scanners and associated software for scanning a user's retina). Authentication capabilities may also include non-biometric devices such as trusted platform modules (TPMs) and smart cards.

[0011] In a mobile biometric authentication implementation, the biometric authentication device may be remote from the relying party. As used herein, the term "remote" means that the biometric authentication device is not part of the security boundary of the computer to which it is communicatively coupled (e.g., not embedded in the same physical enclosure as the relying party computer). As an example, the biometric authentication device may be coupled to the relying party via a network (e.g., the Internet, a wireless network link, etc.) or via a peripheral input such as a USB port. Under these conditions, the relying party may have no way of knowing whether the device is one authenticated by the relying party (e.g., one that provides an acceptable level of authentication and integrity protection) and / or whether a hacker has compromised the biometric authentication device. The degree of trust in a biometric authentication device depends on the specific implementation of the device.

[0012] However, as described below, the authentication techniques used to authenticate a user may include a non-location component, such as communication over a network with a remote server and / or other data processing device. Furthermore, while specific embodiments (such as ATMs and retail stores) are described herein, it should be noted that the underlying principles of the present invention may be implemented within the context of any system in which transactions are initiated locally or remotely by an end user.

[0013] The term "relying party" may be used herein to refer not only to the entity seeking to perform a user transaction (e.g., a website or online service performing the user transaction), but also to a secure transaction server implemented on behalf of that entity that may perform the basic authentication techniques described herein. The secure transaction server providing the remote authentication capabilities may be owned and / or under the control of the relying party, or may be under the control of a third party that provides secure transaction services to the relying party as part of a business arrangement.

[0014] The term "server" is used herein to refer to software running on a hardware platform (or across multiple hardware platforms) that receives requests from clients over a network, performs one or more operations in response, and sends a response to the client, typically including the results of the operations. A server responds to client requests to provide, or help provide, a network "service" to the client. Importantly, a server is not limited to a single computer (e.g., a single hardware device running server software), but may in fact span multiple hardware platforms, potentially in multiple geographic locations.

[0015] Embodiments of the invention described herein include techniques for authenticating a user to initiate a transaction through a secure transaction device. By way of example, the transaction may be a withdrawal, a transfer, or other user-initiated action, and the transaction device may be an automatic teller machine (ATM), a point-of-sale (PoS) transaction device, or other device capable of performing a transaction on behalf of a user. A transaction may involve, for example, completing payment for the purchase of goods or services at a retail store or other retail location equipped with the device, withdrawing funds via the device, performing maintenance on the device, or any other transaction requiring user authentication.

[0016] One embodiment of the present invention provides a technique for locally authenticating a user (i.e., validating a user) even in situations where the device is offline (i.e., not connected to a backend authentication server) or semi-offline (i.e., connected to a backend authentication server only periodically). In one embodiment, the user's client device is capable of caching authentication requests generated by a backend authentication server (e.g., acting on behalf of a relying party), and the device contains the data necessary to validate authentication responses sent to the device from the user's client device.

[0017] Before discussing the details of these embodiments, a summary of remote user authentication techniques is provided. These and other remote user authentication techniques are described in co-pending applications assigned to the assignee of the present application and incorporated herein by reference. Remote User Authentication Technology

[0018] 2A and 2B illustrate two embodiments of a system architecture with client-side and server-side components for remotely authenticating a user. The embodiment illustrated in FIG. 2A uses a browser plug-in-based architecture to communicate with a website, while the embodiment illustrated in FIG. 2B does not require a browser. The various authentication techniques and related applications described herein may be implemented in either of these system architectures. For example, the authentication engine within the client device described herein may be implemented as part of secure transaction service 201, which includes interface 202. However, it should be noted that the above-described embodiments may be realized using logical configurations of hardware and software other than those illustrated in FIGS. 2A-B.

[0019] 2A , the illustrated embodiment includes a client 200 equipped with one or more authentication devices 210-212 for enrolling and authenticating end users. As described above, authentication devices 210-212 may include biometric authentication devices such as fingerprint sensors, voice recognition hardware / software (e.g., microphones and associated software for recognizing a user's voice), facial recognition hardware / software (e.g., cameras and associated software for recognizing a user's face), and optical recognition capabilities (optical scanners and associated software for scanning a user's retina), as well as non-biometric authentication devices such as trusted platform modules (TPMs) and smart cards. A user can enroll in a biometric authentication device by providing biometric data (e.g., swiping a finger on a fingerprint authentication device) that secure transaction service 201 (via interface 202) can store as biometric template data in secure storage 220.

[0020] Although secure storage 220 is shown external to the secure peripheral device of authentication device(s) 210-212, in one embodiment, each authentication device 210-212 may have its own integrated secure storage. Additionally, each authentication device 210-212 may cryptographically protect the biometric criteria data records (e.g., by wrapping the data records to secure storage 220).

[0021] The authentication devices 210-212 are communicatively coupled to the client through an interface 202 (e.g., an application programming interface, or API) exposed by a secure transaction service 201. The secure transaction service 201 is a secure application for communicating with one or more secure transaction servers 232-233 over a network and interfacing with a secure transaction plug-in 205 running within the context of a web browser 204. As shown, the interface 202 may also provide secure access to a secure storage device 220 of the client 200, which stores information about each of the authentication devices 210-212, such as a device identification code (authenticator attestation ID (AAID)), a user identification code, user enrollment data (e.g., scanned fingerprint or other biometric data), and keys used to perform the secure authentication techniques described herein. For example, as described in more detail below, a unique key may be stored on each authentication device and subsequently used when communicating with a server 230 over a network, such as the Internet.

[0022] As described below, certain types of network transactions are supported by the secure transaction plug-in 205, such as HTTP or HTTPS transactions with a website 231 or other server. In one embodiment, the secure transaction plug-in is initiated in response to specific HTML tags inserted into the HTML code of a web page by a web server 231 (sometimes simply referred to as "server 230") internal to a secure enterprise or web destination 230. In response to detecting such a tag, the secure transaction plug-in 205 can forward the transaction to the secure transaction service 201 for processing. Furthermore, for certain types of transactions (e.g., secure key exchange, etc.), the secure transaction service 201 can open a direct communication channel with an internally located transaction server 232 (i.e., co-located with the website) or an externally located transaction server 233.

[0023] Secure transaction servers 232-233 are coupled to secure transaction database 240, which stores user data, authentication device data, keys, and other secure information necessary to support secure authentication transactions, as described below. However, it should be noted that the underlying principles of the present invention do not require the separation of logical components within secure enterprise or web destination 230 shown in Figure 2A. For example, website 231 and secure transaction servers 232-233 may be implemented within a single physical server or separate physical servers. Furthermore, website 231 and transaction servers 232-233 may be implemented within integrated software modules that run on one or more servers to perform the functions described below.

[0024] As noted above, the underlying principles of the present invention are not limited to the browser-based architecture shown in Figure 2A. Figure 2B illustrates an alternative implementation in which a standalone application 254 utilizes functionality provided by secure transaction service 201 to authenticate a user over a network. In one embodiment, application 254 is designed to establish a communication session with one or more network services 251 that rely on secure transaction servers 232-233 to perform user / client authentication techniques, as described in more detail below.

[0025] 2A-2B, the secure transaction servers 232-233 may generate keys that are then securely transmitted to the secure transaction service 201 and stored in an authentication device in the secure storage 220. In addition, the secure transaction servers 232-233 manage a server-side secure transaction database 240.

[0026] 2C illustrates a series of transactions for registering an authentication device. As described above, during registration, a key is shared between the authentication device and one of the secure transaction servers 232-233. The key is stored in the secure storage 220 of the client 200 and in a secure transaction database 220 used by the secure transaction servers 232-233. In one embodiment, the key is a symmetric key generated by one of the secure transaction servers 232-233. However, in another embodiment, described below, an asymmetric key may be used. In this embodiment, a public key may be stored by the secure transaction server 232-233, and a second, associated private key may be stored in the secure storage 220 of the client. Furthermore, in another embodiment, the key(s) may be generated on the client 200 (e.g., by the authentication device or authentication device interface rather than by the secure transaction server 232-233). The underlying principles of the present invention are not limited to any particular type of key or key generation method.

[0027] A secure key provisioning protocol such as the Dynamic Symmetric Key Provisioning Protocol (DSKPP) may be used to share the key with the client over a secure communication channel (see, e.g., Request for Comments (RFC) 6063). However, the underlying principles of the present invention are not limited to any particular key provisioning protocol.

[0028] Referring to the specific details shown in FIG. 2C , upon completion of user registration or user verification, server 230 generates a randomly generated challenge (e.g., a cryptographic nonce) that must be presented by the client during device registration. The random challenge may be valid for a limited period of time. The secure transaction plug-in detects the random challenge and forwards it to secure transaction service 201. In response, the secure transaction service initiates an out-of-band session (e.g., an out-of-band transaction) with server 230 and communicates with server 230 using a key provisioning protocol. Server 230 verifies the user's location using the username, validates the random challenge, validates the device's authentication code (e.g., AAID) if one was submitted, and creates a new entry for the user in secure transaction database 220. It may also generate a key or public / private key pair, write the key(s) to database 220, and send the key(s) back to secure transaction service 201 using the key provisioning protocol. Once complete, the authentication device and server 230 share the same key if a symmetric key was used, or a different key if an asymmetric key was used.

[0029] Figure 3A shows secure transaction confirmation for a browser-based implementation. Although a browser-based implementation is shown, the same basic principles may be implemented using a standalone application or a mobile device application.

[0030] Secure transaction confirmation is designed to provide stronger security for certain types of transactions (e.g., financial transactions). In the illustrated embodiment, the user confirms each transaction before committing it. Using the illustrated technique, the user confirms exactly what they want to complete and completes exactly what they see displayed in window 301 of the graphical user interface (GUI). In other words, this embodiment ensures that the transaction text cannot be modified by a "man in the middle" (MITM) or "man in the browser" (MITB) to complete a transaction that the user did not confirm.

[0031] In one embodiment, the secure transaction plug-in 205 displays a window 301 in the browser context showing the details of the transaction. The secure transaction server 201 periodically (e.g., at random intervals) verifies that the text shown in the window has not been tampered with by anyone (e.g., by generating a hash / signature over the displayed text). In a different embodiment, the authentication device has a trusted user interface (e.g., providing an API that conforms to GlobalPlatform's TrustedUI).

[0032] The following example helps highlight the operation of this embodiment: A user selects an item to purchase from a merchant site and selects "Checkout." The merchant site sends the transaction to a service provider (e.g., PayPal), which has a secure transaction server 232-233 that implements one or more of the inventive embodiments described herein. The merchant site authenticates the user and completes the transaction.

[0033] The secure transaction server 232-233 receives the transaction details (TD) and places a "secure transaction" request in an HTML page and sends it to the client 200. The secure transaction request includes the transaction details and a random challenge. The secure transaction plug-in 205 detects the request for a transaction confirmation message and forwards all data to the secure transaction service 201. In embodiments that do not use a browser or plug-in, the information may be sent directly from the secure transaction server to the secure transaction service on the client 200.

[0034] For browser-based implementations, the secure transaction plug-in 205 displays a window 301 with the transaction details to the user (e.g., within the browser context) and prompts the user to provide authentication to confirm the transaction. In embodiments that do not use a browser or plug-in, the secure transaction service 201, the application 254 (FIG. 2B), or the authentication device 210 may display the window 301. The secure transaction service 201 starts a timer and verifies the contents of the window 301 displayed to the user. The verification period may be chosen randomly. The secure transaction service 201 ensures that the user is viewing valid transaction details in the window 301 (e.g., by generating a hash for the details and verifying that the contents are accurate by comparing it with the hash of the accurate contents). If it detects that the contents have been tampered with, it prevents the verification token / signature from being generated.

[0035] After the user provides valid verification data (e.g., by swiping a finger on a fingerprint sensor), the authentication device verifies the user and generates a cryptographic signature (sometimes referred to as a "token") with the transaction details and a random challenge (i.e., the signature is calculated over the transaction details and a nonce). This allows the secure transaction server 232-233 to ensure that the transaction details have not been modified between the server and the client. The secure transaction service 201 sends the generated signature and the username to the secure transaction plug-in 205, which forwards the signature to the secure transaction server 232-233. The secure transaction server 232-233 identifies the user by the username and verifies the signature. If the verification is successful, a confirmation message is sent to the client and the transaction is processed.

[0036] One embodiment of the present invention implements a query policy in which a secure transaction server sends a server policy to a client indicating the authentication capabilities allowed by the server. The client then analyzes the server policy to identify a subset of authentication capabilities that the server policy supports and / or that the user indicates a desire to use. The client then registers and / or authenticates the user using the subset of authentication tokens that match the provided policy. Thus, there is less impact to the client's privacy because the client is not required to send exhaustive information about its authentication capabilities (e.g., all of its authentication devices) or other information that might be used to uniquely identify the client.

[0037] By way of example and not limitation, a client may include many user verification capabilities, such as a fingerprint sensor, voice recognition capabilities, facial recognition capabilities, eye / optical recognition capabilities, PIN verification, to name a few. However, for privacy reasons, a user may not want to reveal details about all of their capabilities to a requesting server. Thus, using the techniques described herein, a secure transaction server may send a server policy to a client indicating, for example, that it supports fingerprint, optical, or smart card authentication. The client may then compare the server policy against its own authentication capabilities and select one or more of the available authentication options.

[0038] One embodiment of the present invention uses transaction signing in a secure transaction server so that no transaction state needs to be maintained on the server to maintain a session with a client. In particular, transaction details, such as the transaction text displayed in window 301, may be sent to the client signed by the server. The server may then verify that the signed transaction response received by the client is valid by verifying the signature. The server does not need to persistently store the contents of the transaction, which would consume a significant amount of storage space for a large number of clients and open the possibility of denial of service type attacks against the server.

[0039] One embodiment of the present invention is illustrated in Figure 3B, which shows a website or other network service 311 initiating a transaction with a client 200. For example, a user may have selected items to purchase on the website and may be ready to check out and pay. In the illustrated example, the website or service 311 hands off the transaction to a secure transaction server 312 that includes signature processing logic 313 for generating and verifying signatures (as described herein) and authentication logic for performing client authentication 314 (e.g., using the authentication techniques described above).

[0040] In one embodiment, the authentication request sent from the secure transaction server 312 to the client 200 includes a random challenge, such as an encrypted nonce (as described above), transaction details (e.g., specific text to be presented to complete the transaction), and a signature generated by the signature processing logic 313 over the random challenge and transaction details using a private key (known only by the secure transaction server).

[0041] Once the above information is received by the client, the user may receive an indication that user verification is required to complete the transaction. In response, the user may, for example, swipe a finger across a fingerprint scanner, snap an image, speak into a microphone, or perform any other type of authentication allowed for the given transaction. In one embodiment, once the user is successfully verified by authentication device 210, the client sends back to the server: (1) a random challenge and transaction text (both previously provided to the client by the server), (2) authentication data verifying that the user successfully completed authentication, and (3) a signature.

[0042] The authentication module 314 on the secure transaction server 312 may then verify that the user is properly authenticated, and the signature processing logic 313 uses the private key to recreate the signature over the random challenge and transaction text. If the signature matches the one sent by the client, the server can verify that the transaction text is the same as when it was originally received from the website or service 311. The secure transaction server 312 does not need to persistently store the transaction text (or other transaction data) in the secure transaction database 120, so storage and processing resources are saved. For offline or limited connectivity devices Systems and methods for authenticating clients

[0043] As described above, one embodiment of the present invention includes techniques for locally authenticating a user (i.e., validating a user) even in situations where the user device and the device are offline (i.e., not connected to a relying party's backend authentication server) or semi-offline (i.e., the user device is not connected to the relying party, but the device is connected). FIG. 4 illustrates one such configuration in which a client 400, with a relying party 451 previously registered in its authentication device, establishes a secure channel with a transaction device 450 to complete a transaction. By way of example and not limitation, the transaction device may be an ATM, a point-of-sale (PoS) transaction device at a retail location, an Internet of Things (IoT) device, or any other device capable of establishing a channel with the client 400 and allowing the user to perform a transaction. The channel may be implemented using any wireless communication protocol, including, by way of example and not limitation, near field communication (NFC) and Bluetooth (e.g., Bluetooth Low Energy (BTLE) as described in Bluetooth Core Specification Version 4.0). Of course, the underlying principles of the present invention are not limited to any particular communication standard.

[0044] As indicated by the dotted arrows, the connection between client 400 and relying party 451, and / or the connection between transaction device 450 and relying party 451, may be sporadic or non-existent. Real-world applications in the payment field often rely on such “offline” use cases. For example, a user with client 400 (e.g., a smartphone) may not have connectivity to relying party 451 at the time of the transaction, but may still want to authorize a transaction (e.g., a payment) by authenticating transaction device 450. However, in some embodiments of the present invention, client 400 and / or transaction device 450 exchange some information with relying party 451 (although not required during the authentication or transaction confirmation process described herein).

[0045] Traditionally, user verification has been achieved using a secret, such as a personal identification number (PIN), that is captured by a device (e.g., a PoS transaction device or ATM). The device then creates an online connection to a relying party to verify the secret, or calls on the user's authenticator (e.g., an EMV bank card) to verify the PIN. Such implementations have several disadvantages. They may require an online connection, which may be available at times but not always. They also require the user to enter a long-lived secret into a potentially untrusted device, thereby exposing them to shoulder surfing and other attacks. Additionally, they are inherently tied to a specific user verification method (e.g., a PIN in this case). Finally, they require the user to remember a secret, such as a PIN, which can be inconvenient for the user.

[0046] The authentication techniques described herein provide significant flexibility in terms of user verification methods and security, as users can rely on their client's authentication capabilities. In particular, in one embodiment, for the duration that the client is connected to the relying party, a mobile application on the user's client caches an authentication request provided by the relying party. The authentication request may contain the same (or similar) information as the authentication request described above (e.g., a nonce and public key associated with the authenticator), as well as additional information, including a signature for (at least a portion of) the authentication request generated by the relying party, a verification key, and potentially timing data indicating the period for which the authentication request remains valid (or, conversely, the time after which the authentication request expires). In one embodiment, the mobile application may cache multiple such connection requests (e.g., one for each transaction device or type of transaction device).

[0047] In one embodiment, the cached authentication request may then be used for transactions with the transaction device in situations where the client / mobile application is unable to connect with the relying party. In one embodiment, the mobile application triggers the creation of an authentication response based on the cached authentication request, including the serverData and additional data received from the transaction device. The authentication response is then sent to the transaction device, which then verifies the authentication response using a verification key from the relying party (e.g., during the time the transaction device is connected with the relying party). In particular, the transaction device may verify the signature on the serverData included in the authentication response using a key provided by the relying party. In one embodiment, the signature is generated by the relying party using a private relying party verification key, and the transaction device verifies the signature using the corresponding public relying party verification key (provided to the transaction device by the relying party).

[0048] Once the transaction device has verified the serverData extracted from the authentication response, it may use the public key extracted from the authentication request (e.g., Uauth.pub) to verify the authentication response generated by the client / mobile application (e.g., in the same or similar manner as the verification by the relying party described above when the client is directly authenticating the relying party).

[0049] In an alternative embodiment described below, the relying party provides the authentication request directly to the transaction device (rather than through a mobile application on the client device). In this embodiment, the transaction device may solicit an authentication request from the relying party upon receiving a request to complete a transaction from a mobile application on the client. Once it has the authentication request, it may validate the request and authentication response as described above (e.g., by generating a signature and comparing it to an existing signature).

[0050] 5A is a transaction diagram illustrating the interactions between a client 400, a transaction device 450, and a relying party in an embodiment in which the client 400 caches the authentication request. This embodiment is sometimes referred to as a "fully offline" embodiment because the transaction device 450 does not need to have an existing connection with the relying party.

[0051] At 501, a client requests a cacheable authentication request from a relying party. At 502, the relying party generates a cacheable authentication request, at 503 the authentication request is sent to the client, and at 504 the client caches the authentication request. In one embodiment, the authentication request includes the public key (Uauth.pub) associated with the authenticator used for authentication and a signature generated using a relying party verification key (RPVerifyKey) over the public key and a random nonce. If asymmetric keys are used, the RPVerifyKey used to generate the signature by the relying party is a private key with the corresponding public RPVerifyKey that the relying party provided to the transaction device (potentially long before processing the user authentication request).

[0052] In one embodiment, the authentication request also includes timing information indicating the length of time the authentication request is valid (e.g., MaxCacheTime). In this embodiment, a signature for a cacheable authentication request may be generated over a combination of the public authentication key, a nonce, and MaxCacheTime (e.g., ServerData=Uauth.pub|MaxCacheTime|serverNonce|Sign(RPVerifyKey,Uauth.pub|MaxCacheTime|serverNonce)). In one embodiment, the authentication response includes more than one authentication key (e.g., one for each authenticator that can authenticate the user), and a signature may be generated over all of these keys (e.g., along with a nonce and MaxCacheTime).

[0053] As mentioned above, the public RPVerifyKey needs to be known by the transaction device 450, or any device intended to perform offline verification of the authentication request / response. This extension is required because the transaction device does not have any knowledge of the authentication keys registered at the relying party (i.e., there is no established relationship between the user device and the transaction device). As a result, the relying party must communicate with the transaction device (or other device) in a secure manner that the key(s) will be used for authentication response verification. The transaction device verifies MaxCacheTime to determine if the cached authentication request is still valid (to comply with the relying party's policy on how long a cached authentication request can be used).

[0054] At 505, the client establishes a secure connection to the transaction device and initiates a transaction. For example, if the transaction device is a PoS transaction device, the transaction may involve a debit or credit transaction. If the transaction device is an ATM, the transaction may involve a cash withdrawal or a maintenance operation. The underlying principles of the present invention are not limited to any particular type of key or key generation method. Additionally, at 505, the client may send a cached authentication request to the transaction device.

[0055] In response, at 506, the transaction device may send device identification information (e.g., a transaction device identification code), a random challenge (nonce), and optionally a transaction text of a defined syntax to complete the transaction. The random challenge / nonce is then cryptographically bound to the authentication response. This mechanism allows the device to verify that the user verification is fresh and not cached / reused.

[0056] To support transaction confirmations such as those described above (see, e.g., FIGS. 3A-B and associated text), a transaction device may be required to create a standardized, human-readable representation of the transaction. "Standardized," as used herein, means a format that can be parsed by relying parties (e.g., for final validation as shown in operation 511 below) and / or the transaction device. Human-readability is required because transaction confirmation requires displaying the authenticator on a secure display of client 400. One example of such encoding may be XML, in which case XSLT is used for visualization.

[0057] At 507, an authentication user interface is displayed that prompts the user to authenticate with the client using a particular authenticator (e.g., swipe a finger on a fingerprint sensor, enter a PIN code, speak into a microphone, etc.) to generate an authentication response. Once the user provides authentication, the client's authentication engine verifies the user's personal information (e.g., compares authentication data collected from the user with user verification criteria data stored in the authenticator's secure storage) and encrypts and / or generates a signature (and potentially a transaction device ID and / or transaction text) over the random challenge using a private key associated with the authentication device. The authentication response is then sent to the transaction device at 508.

[0058] At 509, the transaction device uses the public RPVerifyKey to verify the signature on the serverData (received at 505), if it has not already done so. Once the serverData is verified, the public key (Uauth.pub) associated with the authenticator used to perform the authentication is known. This key is used to verify the authentication response. For example, the public authentication key may be used to decrypt or verify the signature generated over the nonce and any other relevant information (e.g., transaction text, transaction device ID, etc.). If transaction confirmation is performed by the transaction device, then at 508 it may verify the transaction text displayed to the client by validating the signature generated over the transaction text and included in the authentication response. As an alternative to having a cryptographically secure serverData structure, the transaction device can also verify the unsigned serverData using an online connection to the relying party, if one is available (semi-offline case).

[0059] Depending on whether the authentication was successful or not, an indication of success or failure is sent to the client at 510. If successful, the transaction device authorizes the transaction (e.g., debiting / crediting an account to complete a purchase, automatically dispensing cash, performing accounting tasks, etc.). If unsuccessful, the transaction is rejected and / or additional authentication is required.

[0060] If a connection exists to the relying party, the transaction device may send an authentication response and / or transaction text (assuming the relying party is the entity responsible for verifying the transaction text) to the relying party at 511. A record of the transaction may be recorded at the relying party and / or the relying party may verify the transaction text and confirm the transaction (not shown).

[0061] 5B is a transaction diagram illustrating the interactions between a client 400, a transaction device 450, and a relying party in an embodiment where the transaction device has a connection with the relying party and receives authentication requests from it. This embodiment is sometimes referred to as a "semi-offline" embodiment because the client does not have a connection to the relying party, but the transaction device 450 does.

[0062] At 521, the client initiates a transaction and establishes a secure connection with the transaction device (e.g., NFC, Bluetooth, etc.). At 522, the transaction device responds with an authentication request to the relying party. At 523, the relying party generates an authentication request, which is sent to the transaction device at 524. As in the embodiment shown in FIG. 5A, the authentication request may include a public key (Uauth.pub) associated with the client's authenticator used for authentication and a signature generated using the relying party authentication key (RPVerifyKey) over the public key and a random nonce. If asymmetric keys are used, the RPVerifyKey used to generate the signature by the relying party is a private key with the corresponding public RPVerifyKey that the relying party provides to the transaction device (potentially long before processing the user authentication request). Instead of having a cryptographically secure serverData structure, the transaction device may also use an online connection to the relying party, if one is available (semi-offline case), to verify the unsigned serverData.

[0063] In one embodiment, serverData also includes timing information indicating the length of time the authentication request is valid (e.g., MaxCacheTime). In this embodiment, a signature on serverData may be generated over the combination of the public authentication key, the nonce, and MaxCacheTime (e.g., ServerData=Uauth.pub|MaxCacheTime|serverNonce|Sign(RPVerifyKey,Uauth.pub|MaxCacheTime|serverNonce)). In one embodiment, the authentication response includes one or more authentication keys (e.g., one for each authenticator), and a signature may be generated over all of these keys (e.g., along with the nonce and MaxCacheTime).

[0064] In one embodiment, the remainder of the transaction diagram in Figure 5B operates substantially as shown in Figure 5A. At 525, the transaction device may send identifying information (e.g., a transaction device identification code), a random challenge (nonce), and optionally a transaction text of a defined syntax to complete the transaction. The random challenge / nonce is then cryptographically bound to the authentication response. This mechanism allows the device to verify that the user verification is fresh and not cached / reused.

[0065] To support transaction confirmations such as those described above (see, e.g., FIGS. 3A-B and associated text), a transaction device may be required to create a standardized, human-readable representation of the transaction. "Standardized," as used herein, means a format that can be parsed by relying parties (e.g., for final validation as shown in operation 511 below) and / or the transaction device. Human-readability is required because transaction confirmation requires the authenticator to be displayed on a secure display of client 400. One example of such encoding could be XML, in which case XSLT is used for visualization.

[0066] At 526, an authentication user interface is displayed that prompts the user to authenticate with the client using a particular authenticator (e.g., swipe a finger over a fingerprint sensor, enter a PIN code, speak into a microphone, etc.) to generate an authentication response. Once the user provides authentication, the client's authentication engine verifies the user's personal information (e.g., compares authentication data collected from the user with user verification criteria data stored in the authenticator's secure storage) and encrypts and / or generates a signature (and potentially a transaction device ID and / or transaction text) over the random challenge using a private key associated with the authentication device. The authentication response is then transmitted to the transaction device at 527.

[0067] At 528, the transaction device uses the public RPVerifyKey to verify the signature on the serverData (received at 524), if it has not already done so. Once the serverData is verified, the public key (Uauth.pub) associated with the authenticator used to perform the authentication is known. This key is used to verify the authentication response. For example, the public authentication key may be used to decrypt or verify the signature generated over the nonce and any other relevant information (e.g., transaction text, transaction device ID, etc.). If transaction confirmation is performed by the transaction device, it may verify the transaction text displayed to the client at 528 by validating the signature generated over the transaction text and included in the authentication response. As an alternative to having a cryptographically secure serverData structure, the transaction device can also verify the unsigned serverData using an online connection to the relying party, if one is available (semi-offline case).

[0068] Depending on whether the authentication was successful or not, an indication of success or failure is sent to the client at 529. If successful, the transaction device authorizes the transaction (e.g., debiting / crediting an account to complete a purchase, automatically disbursing cash, performing accounting tasks, etc.). If unsuccessful, the transaction is rejected and / or additional authentication is required.

[0069] At 530, the transaction device may send an authentication response and / or transaction text to the relying party (assuming the relying party is the entity responsible for verifying the transaction text). A record of the transaction may be recorded at the relying party, and / or the relying party may verify the transaction text and confirm the transaction (not shown).

[0070] As shown in Figure 6, in one embodiment, a mobile application 601 executes on a client in combination with an authentication client 602 (which may be the secure transaction service 201 and interface 202 shown in Figure 2B) to perform the operations described herein. In particular, the mobile application 601 may open a secure channel using Transport Layer Security (TLS) or other secure communication protocol to a web application 611 executing on the transaction device 450. The transaction device's web server 612 may also open a secure channel to communicate with the relying party 451 (e.g., to obtain authentication requests and / or to provide updates to the relying party 451, as described above). The authentication client 602 may also communicate directly with the relying party 451, for example, to obtain cacheable authentication requests (as described in detail above).

[0071] In one embodiment, the authentication client 602 may identify the relying party and any authenticated mobile applications 601 using an "AppID," which is a unique code associated with each application made available by the relying party. In some embodiments where the relying party offers multiple online services, a user may have multiple AppIDs with a single relying party (one for each service offered by the relying party).

[0072] In one embodiment, any application identified by an AppID may have multiple "facets" that identify the application type and / or allowable mechanisms for connecting with the relying party. For example, a particular relying party may allow access via web services and via different platform-specific mobile applications (e.g., an Android application, an iOS application, etc.). Each of these may be identified using a different "FacetID" that may be provided by the relying party to the authentication engine as illustrated.

[0073] In one embodiment, the calling mobile application 601 passes its AppID to an API exposed by the authentication client 602. On each platform, the authentication client 602 identifies the calling application 601 and determines its FacetID. It then resolves the AppID and checks whether the FacetID is included in the TrustedApps list provided by the relying party 451.

[0074] In one embodiment, the cacheable authentication request described above may be accomplished using a bearer token as shown in Figures 7 and 8. In the embodiments of the invention described herein, the token acceptor (transaction device 450) needs to be able to verify the token, the authentication response, and the binding of the token to the authentication response without requiring a separate "online" connection to the token issuer (relying party).

[0075] Two classifications of bearer tokens should be distinguished:

[0076] 1. Tokens that are verifiable only by the recipient (e.g., transaction device 450) using a different channel to the issuer (e.g., relying party 451) that must exist between token issuance and token validation. This classification of tokens is referred to herein as "unsigned tokens."

[0077] 2. Tokens that are verifiable by the recipient by virtue of their cryptographic construction, for example by including a digital signature that can be verified using data received from the token issuer, potentially well before the particular token is issued. This category of tokens is referred to herein as "signed tokens."

[0078] The term "signed token structure" is used herein to refer to both a signed token containing a Uauth.pub key and a signed structure containing a token. Binding a signed token to an authentication key

[0079] 7, in one embodiment, to bind a signed token to an authentication key, the token issuer (e.g., relying party 451) (a) adds the authentication public key (Uauth.pub) 702 to the to-be-signed portion 701 of the signature(-to-be) token; and (b) includes the signed token in the to-be-signed portion of the authentication response. By doing this, the token acceptor (e.g., transaction device 450) can verify the token by validating the signature 703 (e.g., the public RPVerifyKey described above). If the verification is successful, the public key (Uauth.pub) can be extracted and used to verify the authentication response, as described above. Binding an unsigned token to an authentication key

[0080] 8, to bind the unsigned token 802 to the authentication key, in one embodiment, the token issuer (e.g., relying party 451) creates a signed structure that encompasses (at least) the original token 802 and the to-be-signed data 801, including the authentication public key (Uauth.pub). The signed structure can be verified by validating the signature 803 using the public key associated with the private signing key (e.g., the RPVerifyKey pair described above). This public signing key needs to be shared with the token recipient (e.g., transaction device 450). Sharing can occur after generating the signing key pair, potentially well before the first signed structure is generated.

[0081] The technology described herein supports both a "fully offline" implementation (i.e., the transaction device 450 has no connection to the relying party 451 at the time of the transaction) as well as a "semi-offline" implementation (i.e., the transaction device has a connection to the relying party 451 at the time of the transaction, but the client does not).

[0082] Even in the case of being completely offline, it is expected that the transaction device 450 will still occasionally connect to the relying party 451 via the host. For example, the host may collect all responses stored on the transaction device 450 for sending to the relying party, and may also update (if necessary) the list of revoked Uauth keys (e.g., public authentication keys that have been revoked since the last connection).

[0083] Some embodiments support pure (session) authentication as well as transaction confirmation, where the relying party 451 can verify the transaction if the transaction device 450 submits the transaction text to the relying party 451 along with an authentication response.

[0084] There are several different use cases / applications for the technology described here, for example:

[0085] 1. Payment. A user has registered a Payment Service Provider (PSP) on their authenticator (e.g., a smartphone). The user wants to authenticate a payment at a merchant using a point-of-sale device (PoS) that has been authenticated by the PSP, but the PoS does not have a trusted, permanent online connection to the PSP (e.g., located on a bus). In this example, to enable the transaction despite the lack of a trusted, permanent connection, the PoS may be implemented as a transaction device 450 and the PSP may be implemented as a relying party 451, as described above.

[0086] 2. Internet of Things. An enterprise has installed several embedded devices (e.g., in a factory, building, etc.). Maintenance of such devices is performed by technicians employed by the contracting party. To perform maintenance, the technicians must authenticate to the devices to prove their eligibility for the work. The following assumptions are made (based on real-world configuration conditions):

[0087] a. Technicians are unable to perform registration for each such device (there are too many devices);

[0088] b. Maintaining a meticulous list of qualified technicians for each device requires too many technicians and the variability of such technicians is too great.

[0089] c. Neither the device nor the technician's computer has a reliable network connection at the time of maintenance.

[0090] Using the techniques described above, an enterprise can inject a trust anchor (e.g., a public RPVerifyKey) into all of their devices at once (e.g., at installation time). Each technician then registers a contracted party (e.g., a relying party 451, which may be the technician's employer). Using the techniques described above, the technician can authenticate each device.

[0091] The above-described embodiments of the present invention may be implemented in any system in which a client with authentication capabilities registers a relying party, and authentication operations are performed between this client and a device that (a) acts on behalf of the relying party and (b) is offline at the time of the transaction (i.e., does not have a reliable network connection to the origin server of the relying party with which the client is registering). In such an example, the client receives a cacheable authentication request from the origin server and caches it. When requested, the client calculates an authentication response and sends it to the device.

[0092] In another embodiment, the client adds the channel binding data (received in the authentication request) to the response in a cryptographically secure manner. By doing this, the relying party's origin server can verify that the request was received by the legitimate client (and not some man-in-the-middle).

[0093] In one embodiment, the relying party adds additional authenticated data to the response, such as a Uauth.pub key that allows the device to verify the authentication or transaction confirmation response without having to contact the relying party server to obtain the authorized Uauth.pub key. In another embodiment, the relying party requires that the client's user perform a successful authentication before issuing a "cacheable" authentication request (to prevent denial of service attacks). In one embodiment, the relying party requires that the client indicate whether the request is cacheable. If cacheable, the relying party may require additional authenticated data in the response (e.g., MaxCacheTime, as described above).

[0094] In one embodiment, a device such as transaction device 450 does not have a direct network connection to the relying party, but is "synchronized" to the relying party using a separate computer (sometimes referred to herein as a "host"). This host retrieves all collected authentication responses from the device and forwards them to the relying party. In addition, the host may also copy a list of revoked Uauth keys to the device to ensure that one of the revoked keys is not used in an authentication response.

[0095] In one embodiment, a device such as transaction device 450 sends a random value (e.g., a nonce) to a client, which cryptographically appends this random value as an extension to the authentication response before signing it. This signed random value serves as a proof of freshness to the device.

[0096] In one embodiment, the client authenticator adds the current time Ta as an extension to the authentication response before signing. The device / transaction device may compare that time with the current time Td and only accept the response if the difference between Ta and Td is acceptable (e.g., if the difference is less than 2 minutes (abs(Td-Ta)<2 minutes)).

[0097] In one embodiment, the relying party adds an authenticated (i.e., signed) expiration date to the cacheable request, and as noted above, the device / transaction device only accepts the response as valid if it is received before the expiration date.

[0098] In one embodiment, the relying party appends an authenticated (i.e., signed) data block (e.g., the "signed token structure" described above) containing additional information to the cacheable request, such as (but not limited to) a public key, an expiration date, a maximum transaction value (e.g., a Security Assertion Markup Language (SAML) assertion, an OAuth token, a JSON Web Signature (JWS) object, etc.). The device / transaction device may only accept the response as valid if it can positively verify the signed data block and the contents are acceptable.

[0099] In one embodiment, the relying party adds only the signed token to the cacheable authentication request, but the transaction device has an online connection to the relying party at the time of the transaction, and the transaction device uses the online connection to the relying party at the time of the transaction to verify the authenticity of the unsigned token.

[0100] FIG. 9 illustrates exemplary “offline” and “semi-offline” authentication scenarios, according to one embodiment of the present invention. In this embodiment, a user with a computing device 910 has an established relationship to a relying party 930 and can authenticate the relying party. However, in some situations, a user desires to perform a transaction (e.g., authentication of transaction confirmation) using a device 970 that has an established relationship to the relying party 930, but not necessarily to the user's computing device 910. With respect to this embodiment, a transaction is referred to as “fully offline” if the connections 920 and 921 do not exist or are not stable at the time of association (e.g., at the time of authenticating the user's computing device 910 to the device 970, or at the time of the transaction between the user's computing device 910 and the device 970). With respect to this embodiment, a transaction is “semi-offline” if the connection 920 between the user's computing device 910 and the relying party 930 is not stable, but the connection 921 between the device 970 and the relying party 930 is stable. It should be noted that in this embodiment, the connection 922 between the user's computing device 910 and the device 970 needs to be stable at some point in time for the association to occur. It is also expected that an authenticator will be connected to the user's computing device 910. The connection 922 can be realized using any kind of communication channel / protocol, including, but not limited to, Bluetooth, Bluetooth Low Energy (BTLE), Near Field Communication (NFC), Wi-Fi, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UTMS), Long Term Evolution (LTE) (e.g., 4G LTE), and TCP / IP. Exemplary Data Processing Device

[0101] Figure 10 is a block diagram illustrating an exemplary client and server that can be used in some embodiments of the present invention. It should be understood that while Figure 10 illustrates various components of a computer system, it is not intended to represent any particular architecture or manner of interconnecting the components, as such details are not pertinent to the present invention. It will be understood that other computer systems having fewer components or multiple components can also be used in accordance with the present invention.

[0102] 10, a computer system 1000 in the form of a data processing system includes bus(es) 1050 coupled to a processing system 1020, a power supply 1025, a memory 1030, and a non-volatile memory 1040 (e.g., a hard drive, flash memory, phase-change memory (PCM), etc.). The bus(es) 1050 may be connected to each other through various bridges, controllers, and / or adapters, as is well known in the art. The processing system 1020 may retrieve instruction(s) from the memory 1030 and / or the non-volatile memory 1040 and execute the instructions to perform operations as described above. A bus 1050 interconnects the above components together and also interconnects them to an optional dock 1060, a display controller and display device 1070, input / output devices 1080 (e.g., a NIC (Network Interface Card), cursor control (e.g., a mouse, touch screen, touch pad, etc.), keyboard, etc.), and optional wireless transceiver(s) 1090 (e.g., Bluetooth, WiFi, infrared, etc.).

[0103] 11 is a block diagram illustrating an exemplary data processing system that may be used in some embodiments of the present invention. For example, data processing system 190 may be a handheld computer, a personal digital assistant (PDA), a mobile phone, a portable gaming system, a portable media player, a tablet, or a handheld computing device that may include a mobile phone, a media player, and / or a gaming system. As another example, data processing system 1100 may be an embedded processing device within a network computer or another device.

[0104] According to one embodiment of the present invention, an exemplary architecture of data processing system 1100 may be used for the portable device described above. Data processing system 1100 includes processing system 1120, which may include one or more microprocessors and / or systems on an integrated circuit. Processing system 1120 is coupled to memory 1110, power source 1125 (including one or more batteries), audio input / output 1140, display controller and display device 1160, optional input / output 1150, input device(s) 1170, and wireless transceiver(s) 1130. It will be understood that additional components not shown in FIG. 11 may be part of data processing system 1100 in certain embodiments of the present invention, and that certain embodiments of the present invention may use fewer components than those shown in FIG. 11. It will further be understood that one or more buses not shown in FIG. 11 may be used to interconnect various components, as is well known in the art.

[0105] The memory 1110 can store data and / or programs for execution by the data processing system 1100. The audio input / output 1140 can include, for example, a microphone and / or speaker for playing music and / or providing telephony functionality via the speaker and microphone. The display controller and display device 1160 can include a graphical user interface (GUI). The wireless (e.g., RF) transceiver 1130 (e.g., WiFi transceiver, infrared transceiver, Bluetooth transceiver, wireless cellular transceiver, etc.) can be used to communicate with other data processing systems. One or more input devices 1170 allow a user to provide input to the system. These input devices can be a keypad, keyboard, touch panel, multi-touch panel, etc. The optional other input / output 1150 can be a connector for a dock. Apparatus and method for efficient challenge-response authentication

[0106] Challenge-response protocols that use cryptographic signatures in responses are the state of the art for authentication (e.g., as specified in current FIDO protocols), transaction confirmation (e.g., Android Protected Confirmation), and other security purposes (see, e.g., SafetyNet). As shown in FIG. 12, a client device 1210 typically generates and stores a random challenge (1201) and asks a server 1211 to send (1202) the challenge to the client. The client computes a response 1203 that includes a signature generated using the challenge 1202. The client sends this response 1204, including the signature, to the server 1211, which, if successful (i.e., the signature is verified), must verify and send a confirmation 1205. The server 1211 only accepts responses that are related to the challenge 1202 that the server has stored for subsequent use. The reason for this approach is the need to protect against replay attacks, i.e., attacks in which an entity can simply capture and replay a response in order to be authenticated. Unfortunately, this requires an extra communication round trip.

[0107] The server 1211 verifies the freshness of the challenge in the response 1204 (i.e., verifies whether the server still has a copy of the challenge and verifies the validity period of the challenge) to ensure that it is not a replay attack.

[0108] Although communication is typically very fast, a round trip still takes a significant amount of time, so reducing the time of one of the two round trips can significantly improve the speed of these operations.

[0109] To address this limitation, one embodiment of the present invention generates a challenge locally in a predetermined manner, thereby avoiding a client-to-server request for the challenge and subsequent server authentication. Figure 13 illustrates one particular embodiment in which a client device 1310 and a server 1311 may initially establish a TLS (Transport Layer Security) channel at 1300. An authentication engine 1313 on the client device 1310 includes a local challenge generator 1320 that locally generates a challenge at 1301. Once generated, the authentication engine 1313 generates a challenge response 1302 that includes a signature for the challenge. The challenge response is sent at 1303, and challenge verification logic / circuitry 1321 on the server 1311 verifies the challenge at 1304 and verifies the response at 1305. The server 1311 retains the challenge and AppID for a specified period of time (e.g., until server-now > app-now + X + more), as described below. In one embodiment, challenge verification logic / circuitry 1321 performs verification at 1304-1305 by independently generating a challenge and signature and comparing the signature and / or challenge with those received by client device 1310. If verification is successful, server 1311 sends a confirmation at 1306.

[0110] This approach removes the need for an additional round trip while still maintaining the replay attack protection properties of the protocol. In one particular implementation, assuming that client 1310 and server 1311 have access to the same "defined prefix," the following operations are performed:

[0111] The challenge is generated at 1301 and / or 1304 using a key derivation function: c = derivative function(defined prefix, current time). In one embodiment, the key derivation function includes Argon2 with a predefined set of parameters such as a salt (for password hashes), a degree of parallelism, a desired number of return bytes, an amount of memory to use, a number of iterations to perform, a version number, and / or a key. In another embodiment, the key derivation function includes the Password-Based Key Derivation Function 2 (pbkdf2). However, any similar function may be employed. One purpose of this function is to generate a result c over time for many different inputs (defined prefix and current time).

[0112] A response is calculated at 1302 as defined by the underlying challenge-response protocol. A variety of different challenge-response protocols may be used, including but not limited to FIDO, SafetyNet, and Android Protected Confirmation.

[0113] A challenge response is sent to server 1311 at 1303 containing the "current time." The server verifies that the "current time" is within a specified tolerance window and stores the value "c" until this window is exceeded. This means that server 1311 will reject any responses that indicate they were generated more than a threshold amount of time in the past (e.g., 60, 90, 120 seconds, etc.) or that they were generated too far in the future (e.g., more than 10 seconds).

[0114] An exemplary time tolerance window 1401 is shown in Figure 14. The tolerance window is selected to be large enough to tolerate clock skew (i.e., inaccuracy between the client's and server's notions of time), yet small enough for the server to store all values ​​of "c" that appear in correctly signed responses. In one embodiment, server 1311 also rejects responses containing a known value "c" that was signed with the same cryptographic key (as the original value "c"). If acceptable, server 1311 returns the requested data or sends a confirmation of the intended action in 1305.

[0115] As an example, in Figure 14, time t1 is considered to be too early and outside the window; this response would not be accepted. Time t2 is inside the acceptance window; this response would be accepted if the associated challenge was not already stored by the server. Time t3 is considered to be too late and outside the window; this response would not be accepted.

[0116] Thus, one embodiment of the present invention implements a cryptographic challenge-response protocol, in which a local challenge generator 1320 generates a challenge and a cryptographic signature through the challenge using a private key (e.g., stored in secure storage 1325), and the associated public key is known to a challenge verification circuit / logic 1321 on the server 1311. The challenge verification circuit / logic 1321 verifies the cryptographic signature using the public key and rejects any response that does not have a valid cryptographic signature. In one embodiment, a challenge c is generated by the local challenge generator 1320 using a key derivation function, and the server verifies whether the challenge c is “fresh” based on verifying that the input data for generating the challenge is acceptable (e.g., the dynamic input data is acceptable and the defined prefix is ​​expected). The server 1311 retains all used challenges associated with each cryptographic public key for a defined time to prevent replay attacks.

[0117] In one implementation, the dynamic input data to the key derivation function is the current time known to the client device 1310, and the challenge verification circuit / logic 1321 determines the dynamic input data to be acceptable within an acceptance window. Alternatively or additionally, the dynamic input data may be previously exchanged data, such as unique data generated as part of establishing the TLS session 1300.

[0118] The key derivation function used may be Argon2, pbkdf2, or some other password hash function. Key derivation functions may also include hash functions such as SHA256 and SHA-3. Additionally, the definition prefix variable may include the FIDO AppID / RpId.

[0119] The challenge-response protocol may include any type of challenge-response protocol, including a FIDO registration / makeCredential operation, a FIDO authentication / getAssertion operation, the Google SafetyNet protocol, or Android Protected Confirmation.

[0120] As described above, embodiments of the present invention may include various steps. The steps may be embodied in machine-executable instructions that cause a general-purpose or special-purpose processor to perform particular steps. Alternatively, the steps may be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

[0121] Elements of the present invention may also be provided as a machine-readable medium for storing machine-executable program code, which may include, but is not limited to, floppy disks, optical disks, CD-ROMs and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, or any other type of medium / machine-readable medium suitable for storing electronic program code.

[0122] Throughout the foregoing description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without some of these specific details. For example, it will be readily apparent to those skilled in the art that the functional modules and methods described herein may be implemented as software, hardware, or any combination thereof. Furthermore, although some embodiments of the present invention are described herein in the context of a mobile computing environment, the underlying principles of the present invention are not limited to mobile computing implementations. Virtually any type of client or peer data processing device may be used in some embodiments, including, for example, desktop or workstation computers. Accordingly, the scope and spirit of the present invention should be judged in terms of the following claims.

[0123] As described above, embodiments of the present invention may include various steps. The steps may be embodied in machine-executable instructions that cause a general-purpose or special-purpose processor to perform particular steps. Alternatively, the steps may be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

Claims

1. 1. A system comprising: a local challenge generator on the client device for generating a challenge including an encrypted nonce on the client device using the derivation function; an authentication engine on the client device for generating a challenge response as defined by a specified challenge response protocol; the authentication engine sends the challenge and the challenge response to a server, the server verifies the challenge response at least in part by determining whether the challenge was generated within a specified time window, and the server retains all used challenges associated with each cryptographic public key for a defined time to prevent replay attacks.

2. 2. The system of claim 1, wherein the authentication engine generates the challenge response by generating a cryptographic signature over the challenge using a private key, the server verifies the challenge response using a corresponding public key, and the server rejects any response with an invalid cryptographic signature.

3. 2. The system of claim 1, wherein the challenge is generated using a key derivation function that includes a defined prefix and dynamic input data as input, and the server is configured to recognize or reproduce the defined prefix and dynamic input data input.

4. 4. The system of claim 3, wherein the dynamic input data includes a time available for use by the server to determine if the challenge was generated within the specified time window.

5. 5. The system of claim 4, wherein the dynamic input data includes a current time known to the client device, and the server determines that the dynamic input data is acceptable if the current time is within an acceptance window.

6. The system of claim 3 , wherein the dynamic input data comprises data previously exchanged between the client device and the server.

7. 7. The system of claim 6, wherein the previously exchanged data includes data exchanged to establish a Transport Layer Security (TLS) session between the client device and the server.

8. The system of claim 1 , wherein the derivation function comprises an Argon2 key derivation function or a pbkdf2 key derivation function.

9. The system of claim 1 , wherein the derivation function comprises a hash function.

10. 4. The system of claim 3, wherein the specified challenge-response protocol comprises a Fast Identify Online (FIDO) registration / makeCredential operation, a FIDO authentication / getAssertion operation, a SafeNet protocol, or an Android Protected Confirmation protocol.

11. The system of claim 10 , wherein the defined prefix comprises a FIDO AppID or RpId.

12. A non-transitory machine-readable medium having program code stored thereon, the program code, when executed by a machine, causing the machine to: generating a challenge including a cryptographic nonce on the client device using the derivation function; generating a challenge response on the client device as defined by a specified challenge response protocol; a machine-readable medium for performing operations of transmitting the challenge and the challenge response from the client device to a server, wherein the server verifies the challenge response, at least in part, by determining whether the challenge was generated within a specified time window; and the server retains all used challenges associated with each cryptographic public key for a defined time to prevent replay attacks.

13. 13. The machine-readable medium of claim 12, wherein the challenge response is generated by generating a cryptographic signature over the challenge using a private key, the server verifies the challenge response using a corresponding public key, and the server rejects any response with an invalid cryptographic signature.

14. 13. The machine-readable medium of claim 12, wherein the challenge is generated using a key derivation function that includes a defined prefix and dynamic input data as input, and the server is configured to recognize or reproduce the defined prefix and dynamic input data input.

15. 15. The machine-readable medium of claim 14, wherein the dynamic input data includes a time usable by the server to determine if the challenge was generated within the specified time window.

16. 16. The machine-readable medium of claim 15, wherein the dynamic input data includes a current time known to the client device, and the server determines that the current time is acceptable if it is within an acceptance window.

17. 15. The machine-readable medium of claim 14, wherein the dynamic input data comprises data previously exchanged between the client device and a server.

18. 20. The machine-readable medium of claim 17, wherein the previously exchanged data includes data exchanged to establish a Transport Layer Security (TLS) session between the client device and the server.

19. 13. The machine-readable medium of claim 12, wherein the derivation function comprises an Argon2 key derivation function or a pbkdf2 key derivation function.

20. The machine-readable medium of claim 12 , wherein the derivation function comprises a hash function.

21. 15. The machine-readable medium of claim 14, wherein the specified challenge-response protocol comprises a Fast Identify Online (FIDO) enrollment / makeCredential operation, a FIDO authentication / getAssertion operation, a SafeNet protocol, or an Android Protected Confirmation protocol.

22. 22. The machine-readable medium of claim 21, wherein the defined prefix comprises a FIDO AppID or RpId.

23. 1. A method comprising: generating a challenge including a cryptographic nonce on the client device using the derivation function; generating a challenge response on the client device as defined by a specified challenge response protocol; transmitting the challenge and the challenge response from the client device to a server, wherein the server validates the challenge response at least in part by determining whether the challenge was generated within a specified time window, and wherein the server retains all used challenges associated with each cryptographic public key for a defined time to prevent replay attacks.

Images