阅读说明：本技术 用于有效质询-响应验证的系统和方法 (System and method for efficient challenge-response verification ) 是由 R·林德曼 于 2020-03-16 设计创作，主要内容包括：本发明描述了用于快速验证的系统、设备、方法以及机器可读介质。例如,系统的一个实施方案包括：客户端设备的本地质询生成器,该本地质询生成器用于使用导出函数在客户端装置上生成质询；客户端设备的验证引擎,该验证引擎用于生成由指定质询-响应协议定义的质询响应；验证引擎用于将质询响应传输到服务器,并且服务器用于至少部分地通过确定质询是否在指定时间窗口内生成来验证质询响应。(Systems, devices, methods, and machine-readable media for fast authentication are described. For example, one embodiment of a system comprises: a local challenge generator of the client device for generating a challenge on the client device using the derived function; a verification engine of the client device, the verification engine to generate a challenge response defined by a specified challenge-response protocol; the verification engine is to transmit the challenge response to the server, and the server is to verify the challenge response at least in part by determining whether the challenge was generated within a specified time window.)

1. A system, the system comprising:

a local challenge generator of the client device for generating a challenge on the client device using an derivation function;

a verification engine of the client device to generate a challenge response defined by a specified challenge-response protocol;

the verification engine is to transmit the challenge response to a server, and the server is to verify the challenge response at least in part by determining whether the challenge was generated within a specified time window.

2. The system as in claim 1 wherein the verification engine is to generate the challenge response by generating a cryptographic signature over the challenge using a private key and wherein the server is to verify the challenge response using a corresponding public key, the server to reject any response with an invalid cryptographic signature.

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

4. The system of claim 3, wherein the dynamic input data includes a time that can be used by the server to determine whether the challenge was generated within the specified time window.

5. The system of claim 4, wherein the server is to hold all used challenges associated with respective cryptographic public keys for a defined time in order to prevent replay attacks.

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

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

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

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

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

11. The system of claim 1, wherein the challenge response protocol comprises a fast authentication on line (FIDO) sign-on/makecreditial operation, a FIDO authentication/getauthentication operation, a SafetyNet protocol, or an Android protection validation protocol.

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

13. A machine-readable medium having program code stored thereon, which when executed by a machine, causes the machine to perform operations comprising:

generating a challenge on the client device using the derived function;

generating a challenge response defined by a specified challenge-response protocol; and

the challenge response is transmitted to a server, and the server is to verify the challenge response at least in part by determining whether the challenge was generated within a specified time window.

14. The machine-readable medium as in claim 13 wherein the challenge response is generated by generating a cryptographic signature over the challenge using a private key and wherein the server is to verify the challenge response using a corresponding public key, the server to reject any response with an invalid cryptographic signature.

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

16. The machine-readable medium as in claim 15 wherein the dynamic input data comprises a time that can be used by the server to determine whether the challenge was generated within the specified time window.

17. The machine-readable medium as in claim 16 wherein the server is to maintain all used challenges associated with the respective cryptographic public keys for a defined time in order to prevent replay attacks.

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

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

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

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

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

23. The machine-readable medium of claim 13, wherein the challenge-response protocol comprises a fast authentication on line (FIDO) sign-on/makecreditial operation, a FIDO authentication/getauthentication operation, a SafetyNet protocol, or an Android protection validation protocol.

24. The machine-readable medium of claim 23, wherein the defined prefix comprises a FIDO AppID or an RpId.

25. A method, the method comprising:

generating a challenge on the client device using the derived function;

generating a challenge response defined by a specified challenge-response protocol; and

the challenge response is transmitted to a server, and the server is to verify the challenge response at least in part by determining whether the challenge was generated within a specified time window.

Technical Field

The present invention relates generally to the field of data processing systems. More particularly, the present invention relates to systems and methods for efficient challenge-response verification.

Description of related Art

Fig. 1 shows an exemplary client 120 having a biometric device 100. In normal operation, the biometric sensor 102 reads raw biometric data from a user (e.g., captures a user's fingerprint, records a user's voice, takes a picture of the user, etc.), and the feature extraction module 103 extracts specified features of the raw biometric data (e.g., focuses on certain areas of the fingerprint, certain facial features, etc.). The matcher module 104 compares the extracted features 133 to the 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. Application 105 may then use the score to determine whether the verification was successful (e.g., whether the score is above some specified threshold).

While the system shown in fig. 1 is directed to biometric authentication, various other or additional authentication techniques may be employed on the exemplary client 120. For example, the client-side authenticator may be triggered based on a PIN or other secret code (e.g., password) entered by the user and/or based on user presence (e.g., the user pressing a button to verify presence).

Systems have been designed to provide secure user authentication over a network using biometric sensors. In such systems, the scores and/or other authentication data generated by the application may be sent over a network to authenticate the user to a remote server. For example, patent application No.2011/0082801 ("the' 801 application") describes a framework for user enrollment 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 browser" and "man-in-the-middle" attacks in transactions), and enrollment/management of client authentication tokens (e.g., fingerprint readers, facial recognition devices, smart cards, trusted platform modules, etc.).

The assignee of the present application has developed various improvements to the verification framework described in the' 801 application. Some of these improvements are described in the following set of U.S. patent applications ("co-pending applications"), all filed on month 12, 29 of 2012, assigned to the present assignee, and incorporated herein by reference: serial No. 13/730,761 entitled "Query systems and Method to determination Capabilities" (Query System and Method for determining Authentication Capabilities); serial No. 13/730,776 entitled "System and Method for efficient engineering, registration, and Authentication With Multiple Authentication Devices" (a System and Method for Efficiently performing registration, and Authentication using Multiple Authentication Devices); serial number 13/730,780 entitled "System and Method for Processing Random Challenges with an Authentication Framework" (System and Method for Processing Random Challenges Within an Authentication Framework); serial number 13/730,791 entitled "System and Method for Implementing Privacy Classes Within an Authentication Framework"; serial number 13/730,795 entitled "System and Method for Implementing Transaction Signaling Within an Authentication Framework".

Briefly, in the authentication techniques described in these co-pending applications, a user enrolls with an authentication device (or verifier) on a client device, such as a biometric device (e.g., a fingerprint sensor). When a user registers with a biometric device, biometric reference data is captured (e.g., by swiping a finger, taking a picture, recording a voice, etc.). The user may then register the authentication device with one or more servers (e.g., websites or other relying parties equipped with secure transaction services, as described in the co-pending application) via the network; and subsequently authenticated to those servers using data exchanged during the registration process (e.g., a key preset into the authentication device). Once authenticated, the user is permitted to perform 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 may be used to uniquely identify a user) may be maintained locally on the user's authentication device to protect the user's privacy.

Background

Drawings

The invention may be better understood from the following detailed description taken in conjunction with the following drawings, in which:

FIG. 1 illustrates an exemplary client device with biometric verification capabilities;

FIGS. 2A and 2B illustrate two different embodiments of a security verification system architecture;

FIG. 2C is a transaction diagram showing how a key may be registered in an authentication device;

FIGS. 3A and 3B illustrate an embodiment of a secure transaction confirmation using a secure display;

FIG. 4 illustrates one embodiment of the present invention for performing transaction verification with an unaffiliated device;

FIGS. 5A and 5B are transaction diagrams illustrating two different embodiments for performing transaction verification;

FIG. 6 illustrates additional architectural features employed in one embodiment of the present invention;

figures 7 to 8 show different embodiments of an anonymous token employed in different embodiments of the present invention;

FIG. 9 illustrates exemplary "offline" and "semi-offline" verification scenarios;

FIG. 10 illustrates an exemplary system architecture of a client and/or server;

FIG. 11 illustrates another exemplary system architecture of a client and/or server;

FIG. 12 illustrates an example of a challenge-response authentication protocol and system;

FIG. 13 illustrates one embodiment in which a client device generates a challenge locally; and is

Fig. 14 illustrates an embodiment of a time acceptance window.

Detailed description of the preferred embodiments

The following describes implementations of apparatus, methods, and machine-readable media for implementing advanced authentication techniques and associated applications. Throughout the description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one 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.

The embodiments of the invention discussed below relate to client devices having authentication capabilities, such as biometric devices or PIN entry. These devices are sometimes referred to herein as "tokens," authentication devices, "or" authenticators. While certain embodiments focus on facial recognition hardware/software (e.g., a camera and associated software for recognizing a user's face and tracking the user's eye movement), some embodiments may utilize additional biometric devices including, for example, a fingerprint sensor, voice recognition hardware/software (e.g., a microphone and associated software for recognizing a user's voice), and optical recognition capabilities (e.g., an optical scanner and associated software for scanning a user's retina). The verification capabilities may also include non-biometric devices such as Trusted Platform Modules (TPMs) and smart cards.

In a mobile biometric implementation, the biometric device may be remotely dependent on the relying party. As used herein, the term "remote" means that the biometric sensor is not part of the security boundary of the computer to which it is communicatively coupled (e.g., the biometric sensor is not embedded in the same physical housing as the relying party computer). For example, the biometric 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 not know whether the device is one authorized 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 device. The confidence level of a biometric device depends on the particular implementation of the device.

However, as discussed below, authentication techniques for authenticating a user may involve non-location components, such as communication with a remote server and/or other data processing device via a network. Further, while particular embodiments (such as ATMs and retail locations) are described herein, it should be noted that the underlying principles of the invention may be implemented in the context of any system in which a transaction is initiated by an end user, either locally or remotely.

The term "relying party" is sometimes used herein to refer not only to the entity with which the user transaction is attempted (e.g., a website or online service that performs the user transaction), but also to a secure transaction server (which may perform the basic authentication techniques described herein) that represents that entity's implementation. The secure transaction server providing remote authentication capability may be owned and/or under the control of the relying party or may be under the control of a third party providing secure transaction services to the relying party as part of a business arrangement.

The term "server" as used herein refers to software executing on one hardware platform (or across multiple hardware platforms) that receives a request from a client via a network, then performs one or more operations in response, and transmits a response to the client, typically including the results of the operations. The server responds to client requests to provide or assist in providing network "services" to the client. Notably, the server is not limited to a single computer (e.g., a single hardware device for executing server software), but may in fact be spread across multiple hardware platforms, possibly located at multiple geographic locations.

Embodiments of the invention described herein include techniques for authenticating a user for a transaction initiated by a secure transaction device. For example, the transaction may be a withdrawal, transfer, or other user-initiated operation, and the transaction device may be an Automated Teller Machine (ATM), point of sale (PoS) transaction device, or other device capable of performing transactions on behalf of a user. The transaction may involve, for example, completing a payment at a retail or other retail location equipped with the transaction device to purchase goods or services, drawing funds via the transaction device, performing maintenance on the transaction device, or any other transaction for which user authentication is required.

One embodiment of the present invention provides techniques for verifying user identity (i.e., verifying the user) locally, even if the device is offline (i.e., not connected to the back-end verification server) or semi-offline (i.e., only periodically connected to the back-end verification server). In one embodiment, the user's client device possesses the ability to cache authentication requests generated by a back-end authentication server (e.g., operating on behalf of a relying party), and the device is provided with the data needed to verify authentication responses transmitted from the user's client device to the device.

Before discussing the details of these embodiments of the invention, an overview of remote user authentication techniques is provided herein. 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 techniques

Fig. 2A and 2B illustrate two embodiments of a system architecture including a client-side component and a server-side component for remotely authenticating a user. The embodiment shown in fig. 2A uses a browser plug-in based architecture to communicate with a website, whereas the embodiment shown in fig. 2B does not require a browser. The various authentication techniques and associated applications described herein may be implemented on any of these system architectures. For example, the verification engine within the client device described herein may be implemented as part of a secure transaction service 201 that includes an interface 202. It should be noted, however, that the embodiments described above may be implemented using a logical arrangement of hardware and software other than those shown in fig. 2A and 2B.

Turning to fig. 2A, the illustrated embodiment includes a client 200 equipped with one or more authentication devices 210-212 for enrolling and authenticating an end user. As described above, the authentication devices 210-212 may include biometric devices, such as fingerprint sensors, voice recognition hardware/software (e.g., a microphone and associated software for recognizing a user's voice), facial recognition hardware/software (e.g., a camera and associated software for recognizing a user's face), and optical recognition functionality (e.g., an optical scanner and associated software for scanning a user's retina); and non-biometric devices such as Trusted Platform Modules (TPMs) and smart cards. The user may enroll the biometric device by providing biometric data (e.g., swiping a finger over a fingerprint device), which the secure transaction service 201 may store in the secure storage 220 as biometric template data (via the interface 202).

Although the secure storage 220 is shown outside the security perimeter of the authentication devices 210-212, in one embodiment, each authentication device 210-212 may have its own integrated secure storage. In addition, each authentication device 210-212 may cryptographically protect the biometric reference data records (e.g., wrapping these data records with a symmetric key to secure the storage device 220).

The verification devices 210-212 are communicatively coupled to the client through an interface 202 (e.g., an application programming interface or API) exposed by the secure transaction service 201. The secure transaction service 201 is a secure application for communicating with one or more secure transaction servers 232-233 via a network and for interfacing with a secure transaction plugin 205 executing within the environment of the web browser 204. As shown, the interface 202 may also provide secure access to a secure storage 220 on the client 200 that stores information related to each of the authentication devices 210-212, such as a device identification code (such as an authenticator authentication id (aaid)), a user identification code, user enrollment data (e.g., a scanned fingerprint or other biometric data), and keys for performing the secure authentication techniques described herein. For example, as discussed in detail below, the unique key may be stored into each authentication device and subsequently used when communicating with the server 230 via a network, such as the internet.

As discussed below, the secure transaction plug-in 205 supports certain types of network transactions, such as HTTP or HTTPs transactions with the website 231 or other server. In one embodiment, the secure transaction plugin is initiated in response to a particular HTML tag inserted into the Web page HTML code by a Web server 231 (hereinafter sometimes simply referred to as "server 230") within the secure enterprise or Web destination 230. In response to detecting such a tag, the secure transaction plugin 205 may forward the transaction to the secure transaction service 201 for processing. Additionally, for certain types of transactions (e.g., such as secure key exchange), the secure transaction service 201 may open a direct communication channel with the local transaction server 232 (i.e., co-located with the website) or the off-site transaction server 233.

The secure transaction servers 232-233 are coupled to a secure transaction database 240 to store user data, authentication device data, keys, and other security information needed to support secure authentication transactions as described below. It should be noted, however, that the underlying principles of the invention do not require the separation of logical components within the secure enterprise or web destination 230 shown in FIG. 2A. For example, the website 231 and the secure transaction servers 232-233 may be implemented within a single physical server or separate physical servers. Further, the website 231 and the transaction servers 232-233 may be implemented within integrated software modules executed on one or more servers to perform the functions described below.

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

In either of the embodiments shown in fig. 2A and 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 within the secure storage 220. In addition, the secure transaction servers 232 through 233 manage a secure transaction database 240 on the server side.

Fig. 2C shows 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 to 233. The keys are stored in the secure storage 220 of the client 200 and the secure transaction database 220 used by the secure transaction servers 232 to 233. In one embodiment, the key is a symmetric key generated by one of the secure transaction servers 232-233. However, in another implementation discussed below, an asymmetric key may be used. In this embodiment, the public key may be stored by the secure transaction servers 232-233 and the second associated private key may be stored in the secure storage 220 on the client. Further, in another embodiment, the key may be generated on the client 200 (e.g., by the authentication device or authentication device interface rather than the secure transaction servers 232-233). The underlying principles of the invention are not limited to any particular type of key or manner of generating a key.

Secure key provisioning protocols, such as Dynamic Symmetric Key Provisioning Protocol (DSKPP), may be used to share keys with clients via a secure communication channel (e.g., see comment for comments (RFC) 6063). However, the underlying principles of the invention are not limited to any particular key provisioning protocol.

Turning to the specific details shown in fig. 2C, once user enrollment or user verification is complete, the server 230 generates a randomly generated challenge (e.g., a cryptographic nonce) that the client must present during device enrollment. The random challenge may be valid for a limited period of time. The secure transaction plugin detects the random challenge and forwards it to the 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 locates the user using the username, verifies the random challenge, verifies the authentication code of the device (e.g., AAID) if it has been sent, and creates a new entry for the user in secure transaction database 220. The server may also generate a key or public/private key pair, write the key to the database 220, and send the key back to the secure transaction service 201 using a key provisioning protocol. Once this is done, the authentication device and the server 230 share the same key if a symmetric key is used, or a different key if an asymmetric key is used.

Fig. 3A illustrates a secure transaction confirmation for browser-based implementations. Although a browser-based implementation is shown, the same basic principles may be implemented using a stand-alone application or a mobile device application.

This secure transaction confirmation is designed to provide greater security for certain types of transactions (e.g., financial transactions). In the illustrated embodiment, the user confirms each transaction before conducting the transaction. Using the illustrated technique, the user confirms what transaction he/she wants to do at all and does do the transaction he/she sees in window 301 of the Graphical User Interface (GUI). In other words, this embodiment ensures that the "middle man" (MITM) or "browser middle man" (MITB) cannot modify the transaction text to make a transaction that the user does not confirm.

In one embodiment, the secure transaction plugin 205 displays a window 301 in a browser environment to show transaction details. The secure transaction server 201 periodically (e.g., at random intervals) verifies that the text shown in the window is not being tampered with by anyone (e.g., by generating a hash/signature over the displayed text). In various embodiments, the verification device has a trusted user interface (e.g., an API for providing a trusted UI compliant with global platform organization (GlobalPlatform)).

The following example will help highlight the operation of this embodiment. The user selects merchandise from the merchant web site and selects "check out". The merchant website sends the transaction to a service provider (e.g., PayPal) having a secure transaction server 232-233 that implements one or more embodiments of the invention described herein. The merchant web site authenticates the user and completes the transaction.

The secure transaction servers 232-233 receive the Transaction Details (TD) and place and send the "secure transaction" request in an HTML page to the client 200. The secure transaction request includes transaction details and a random challenge. The secure transaction plugin 205 detects the request for the transaction confirmation message and forwards all data to the secure transaction service 201. In embodiments that do not use a browser or plug-in, this information may be sent directly from the secure transaction server to the secure transaction service on the client 200.

With browser-based implementations, the secure transaction plugin 205 displays a window 301 with transaction details to the user (e.g., in a browser environment) and asks the user to provide verification 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 a window 301. The secure transaction service 201 starts a timer and checks the contents of the window 301 being displayed to the user. The verification period may be randomly selected. The secure transaction service 201 ensures that the user sees valid transaction details in window 301 (e.g., generates a hash of the details and verifies that the content is accurate by comparing to the hash of the correct content). If it is detected that the content has been tampered with, generation of a confirmation token/signature is prevented.

After the user provides valid verification data (e.g., by swiping a finger over a fingerprint sensor), the verification device verifies the user and generates a cryptographic signature (sometimes referred to as a "token") using the transaction details and the random challenge (i.e., a signature is calculated from the transaction details and the random number). This allows the secure transaction servers 232-233 to ensure that transaction details have not been modified between the server and the client. The secure transaction service 201 sends the generated signature and username to the secure transaction plugin 205, which forwards the signature to the secure transaction servers 232 to 233. The secure transaction servers 232-233 identify the user using the user name and verify the signature. If the verification is successful, a confirmation message is sent to the client and the transaction is processed.

One embodiment of the invention implements a query policy in which a secure transaction server transmits a server policy to a client, the server policy indicating authentication functions accepted by the server. The client then analyzes the server policy to identify a subset of authentication functions that it supports and/or that the user has indicated a desire to use. The client then registers and/or authenticates the user using a subset of authentication tokens that match the provided policy. Thus, there is less impact on the privacy of the client, as the client is not required to transmit detailed information about its authentication function (e.g., all of its authentication devices) or other information that can be used to uniquely identify the client.

By way of example and not limitation, the client may include a number of user verification functions, such as a fingerprint sensor, voice recognition functions, facial recognition functions, eye/optical recognition functions, PIN verification, and the like. However, for privacy reasons, the user may not wish to disclose all of the details of their functionality to the requesting server. Thus, using the techniques described herein, the secure transaction server may transmit a server policy to the client indicating that it supports, for example, fingerprint, optical, or smart card authentication. The client may then compare the server policy to its own authentication function and select one or more available authentication options.

One embodiment of the present invention employs transaction signing on a secure transaction server such that a session with a client is maintained without the need to maintain any transaction state on the server. In particular, transaction details, such as transaction text, displayed within window 301 may be sent to a client signed by a server. The server may then verify whether the signed transaction response received by the client is valid by verifying the signature. The server does not need to store the transaction content permanently, as doing so would consume a large amount of storage space for a large number of clients and would lead to the possibility of a denial of service type attack on the server.

One embodiment of the invention is shown in FIG. 3B, which illustrates a website or other web service 311 initiating a transaction with a client 200. For example, the user may have selected an item on the website to purchase, and may be ready to check out payment. In the illustrated example, the website or service 311 submits the transaction to a secure transaction server 312 that includes signature processing logic 313 for generating and verifying signatures (as described herein) and verification logic 314 for performing client verification (e.g., using the previously described verification techniques).

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

Once the client receives the above information, the user may receive an indication that user verification is required to complete the transaction. In response, the user may swipe a finger, for example, on a fingerprint scanner, take a picture, speak into a microphone, or perform any other type of authentication permitted for a given transaction. In one embodiment, once the user has been successfully verified by the verification device 210, the client transmits back to the server: (1) random challenge and transaction text (both previously provided by the server to the client), (2) authentication data that proves that the user successfully completed authentication; and (3) signatures.

The verification module 314 on the secure transaction server 312 may then confirm that the user has been properly verified and the signature processing logic 313 regenerates a signature over the random challenge and transaction text using the private key. If the signature matches the signature sent by the client, the server may verify that the transaction text is the same as it was originally received from the website or service 311. This saves storage and processing resources because the secure transaction server 312 is not required to permanently store the transaction text (or other transaction data) within the secure transaction database 120.

System and method for authenticating a client to an offline device or a device with limited connectivity

As mentioned, one embodiment of the present invention includes techniques for authenticating a user (i.e., verifying the user) locally, even if 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 a relying party, but the device is connected to a relying party). Fig. 4 illustrates one such arrangement, wherein a client 400 having an authentication device previously registered with a relying party 451 establishes a secure channel with a transaction device 450 in order 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 point of sale, an internet of things (IoT) device, or any other device capable of establishing a channel with the client 400 and allowing a 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) protocol as set forth in bluetooth core specification version 4.0). Of course, the underlying principles of the invention are not limited to any particular communication standard.

As indicated by the dashed 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 may not exist. Practical applications in the payment domain typically rely on such "offline" use cases. For example, a user owning the client 400 (e.g., a smartphone) may not be connected with the relying party 451 at the time of a transaction, but may want to authorize the transaction (e.g., payment) by authenticating to the transaction device 450. However, in some embodiments of the present invention, client 400 and/or transaction device 450 do exchange some information with relying party 451 (although not necessarily during the authentication or transaction confirmation process described herein).

Conventionally, user verification has been performed using a secret such as a Personal Identification Number (PIN) to be acquired by a device (e.g., a PoS transaction device or ATM). The device will then create an online connection with the relying party to verify the secret, or will require the user's authenticator (e.g., EMV bank card) to verify the PIN. This implementation has several disadvantages. This implementation may require an online connection, but online connections may sometimes be available, but are not always available. This implementation also requires the user to enter long-term valid secrets into a potentially untrusted device that is subject to the risk of shoulder surfing and other attacks. In addition, the implementation is essentially tied to a particular user verification method (e.g., a PIN in this case). Finally, this implementation requires the user to remember a secret such as a PIN, which may be inconvenient for the user.

The authentication techniques described herein allow a user to rely on the authentication capabilities of his/her own client, so provide significantly greater flexibility in user verification methods and security. In particular, in one embodiment, a mobile application on a user client caches authentication requests provided by a relying party during the time the client connects to the relying party. The verification request may include the same (or similar) information as the verification request described above (e.g., a random number and a public key associated with the verifier), as well as additional information including a signature on (at least a portion of) the relying party-generated verification request, a verification key, and potential timing data indicating a period of time within which the verification request will remain valid (or conversely, a time after which the verification request will expire). In one embodiment, the mobile application may cache multiple such connection requests (e.g., one for each transaction device or transaction device type).

In one embodiment, the cached authentication request may then be used to conduct a transaction with the transaction device in the event that 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 a cached authentication request that includes the serverData and additional data received from the transaction device. The validation response is then transmitted to the transaction device, which then verifies the validation response using a verification key provided by the relying party (e.g., during the time the transaction device is connected to the relying party). In particular, the transaction device may use the relying party provided key to verify the signature on the serverData contained in the verification response. In one embodiment, the relying party generates a signature using a private relying party verification key, and the transaction device verifies the signature using a corresponding public relying party verification key (provided by the relying party transaction device).

Once the transaction device has verified the serverData extracted from the authentication response, the public key (e.g., uauth. pub) extracted from the authentication request can then be used to verify the authentication response generated by the client/mobile application (e.g., in the same or similar manner as the above-described verification by the relying party when the client authenticates directly to the relying party).

In an alternative implementation 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 require an authentication request from the relying party upon receiving a request from a mobile application on the client to complete the transaction. Once the transaction device obtains the verification request, the request and verification response may be verified as described above (e.g., by generating a signature and comparing the signature to existing signatures).

Figure 5A is a transaction diagram illustrating interactions between client 400, transaction device 450, and relying parties in one embodiment of client 400 caching authentication requests. This embodiment is sometimes referred to as an "all offline" embodiment because it does not require the transaction device 450 to have an existing connection with the relying party.

At 501, a client requests a cacheable authentication request from a relying party. At 502, a relying party generates a cacheable validation request; at 503, a verification request is sent to the client; at 504, the client caches the authentication request. In one embodiment, the verification request includes a public key (uauth. pub) associated with the verifier to be used for verification, and a signature generated over the public key and the random number using a relying party verification key (RPVerifyKey). If an asymmetric key is used, the RPVerifyKey that the relying party uses to generate the signature is a private key with a corresponding public RPVerifyKey that the relying party has provided to the transaction device (possibly well before processing the user authentication request).

In one embodiment, the authentication request also includes timing information (e.g., maxcacetime) indicating a length of time during which the authentication request will remain valid. In this embodiment, the signature of the cacheable authentication request may be generated by a combination of a public authentication key, a random number, and MaxCacheTime (e.g., ServerData ═ uauth. pub | MaxCacheTime | servernecent | Sign (RPVerifyKey, uauth. pub | MaxCacheTime | servernecent)). In one embodiment, the verification response includes more than one verification key (e.g., one for each verifier capable of verifying the user), and the signature may be generated by all of these keys (e.g., along with the random number and maxcache time).

As mentioned, the transaction device 450 or any device intended to perform offline verification of authentication requests/responses needs to know the public RPVerifyKey. This extension is necessary because the authentication key registered at the relying party is completely unclear to the transaction device (i.e., no relationship is established between the user device and the transaction device). Thus, the relying party must communicate information to the transaction device (or other device) in a secure manner regarding which keys are to be used for verification of the response. The transaction device will check maxcache time to determine if the cached authentication request is still valid (in order to comply with the policy of the relying party as to how long the cached authentication request can be used).

At 505, the client establishes a secure connection with 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 maintenance task. The underlying principles of the invention are not limited to any particular type of transaction device or secure connection. Additionally, at 505, the client may transmit the cached authentication request to the transaction device.

In response, at 506, the transaction device may transmit device identity information (e.g., a transaction device identification code), a random challenge (nonce), and optionally, transaction text to complete the transaction in a defined syntax. The random challenge/nonce will then be cryptographically bound to the authentication response. This mechanism allows the device to verify that the user verification is newly generated and has not been cached/reused.

To support transaction confirmation such as described above (see, e.g., fig. 3A and 3B and associated text), the transaction device may be required to create a standardized and human-readable representation of the transaction. As used herein, "standardized" means a format that can be resolved by a relying party (e.g., for final verification as indicated in operation 511 described below) and/or that can be resolved by a transaction device. The format needs to be human readable because transaction confirmation requires the validator to display these transaction confirmations on the secure display of client 400. An example of such encoding may be XML, where XSLT is used for visualization.

At 507, to generate an authentication response, an authentication user interface is displayed for guiding the user to perform authentication on the client using a particular authenticator (e.g., swipe a finger over a fingerprint sensor, enter a PIN code, speak into a microphone, etc.). Once the user provides the verification, a verification engine on the client verifies the user's identity (e.g., compares the verification data collected from the user with user verification reference data stored in a secure storage of the verifier) and encrypts and/or generates a signature over the random challenge (possibly also over the transaction device ID and/or transaction text) using a private key associated with the verification device. The verification response is then transmitted to the transaction device at 508.

At 509, if the verification engine has not transmitted a verification response to the transaction device, the transaction device uses the public RPVerifyKey to verify the signature on the serverData (received at 505). Once the serverData is verified, the transaction device knows the public key (uuuth. The transaction device uses the key to verify the verification response. For example, the transaction device may use the public verification key to decrypt or verify a signature generated over the random number and any other relevant information (e.g., transaction text, transaction device ID, etc.). If the transaction device performs a transaction confirmation, the transaction device may verify the transaction text displayed on the client by verifying the signature generated on the transaction text and included in the verification response, at 508. Instead of having an cryptographically secure serverData structure, the transaction device may also verify unsigned serverData using an online connection with the relying party if the connection is available (semi-offline).

At 510, a success indication or a failure indication is sent to the client depending on whether the verification succeeded or failed, respectively. If successful, the transaction device will allow the transaction (e.g., debit/credit the account to complete the purchase, pay cash, perform administrative tasks, etc.). If it fails, the transaction device will not allow the transaction and/or request additional verification.

If there is a connection with the relying party, the transaction device may transmit an authentication response and/or transaction text to the relying party (assuming the relying party is the entity responsible for verifying the transaction text) 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).

FIG. 5B is a transaction diagram illustrating interactions between a client 400, a transaction apparatus 450, and a relying party in one embodiment in which the transaction apparatus has a connection with the relying party and receives an authentication request from the relying party. This embodiment is sometimes referred to as a "semi-offline" embodiment because the transaction device 450 is connected with the relying party even though the client is not connected to the relying party.

At 521, the client initiates a transaction, establishing a secure connection (e.g., NFC, bluetooth, etc.) with the transaction device. At 522, the transaction device responds requiring an authentication request from the relying party. At 523, the relying party generates a verification request and then sends the verification request to the transaction device at 524. As in the embodiment shown in fig. 5A, the verification request may include a public key (uauth. pub) associated with the verifier that is to be used for verification on the client, and a signature generated over the public key and the random number using a relying party verification key (RPVerifyKey). If an asymmetric key is used, the RPVerifyKey that the relying party uses to generate the signature is a private key with a corresponding public RPVerifyKey that the relying party provides to the transaction device (possibly well before processing the user authentication request). Instead of having an cryptographically secure serverData structure, the transaction device may also verify unsigned serverData using an online connection with the relying party if the connection is available (semi-offline).

In one embodiment, the serverData also includes timing information (e.g., MaxCacheTime) indicating the length of time during which the authentication request will remain valid. In this embodiment, the signature of serverData may be generated by a combination of a public verification key, a random number, and MaxCacheTime (e.g., serverData ═ uauth. pub | MaxCacheTime | servernecent | Sign (RPVerifyKey, uauth. pub | MaxCacheTime | servernecent)). In one embodiment, the verification response includes more than one verification key (e.g., one for each verifier), and the signature may be generated with all of these keys (e.g., along with the random number and maxcache time).

In one embodiment, the remainder of the transaction diagram in FIG. 5B operates substantially as shown in FIG. 5A. At 525, the transaction device may transmit identity information (e.g., a transaction device identification code), a random challenge (nonce), and optionally, transaction text to complete the transaction in a defined syntax. The random challenge/nonce will then be cryptographically bound to the authentication response. This mechanism allows the device to verify that the user verification is newly generated and has not yet been cached.

To support transaction confirmation such as described above (see, e.g., fig. 3A and 3B and associated text), the transaction device may be required to create a standardized and human-readable representation of the transaction. As used herein, "standardized" means a format that can be resolved by a relying party (e.g., for final verification as indicated in operation 511 described below) and/or that can be resolved by a transaction device. The format needs to be human readable because transaction confirmation requires the validator to display these transaction confirmations on the secure display of client 400. An example of such encoding may be XML, where XSLT is used for visualization.

At 526, to generate an authentication response, an authentication user interface is displayed for guiding the user to perform authentication on the client using a particular authenticator (e.g., swipe a finger over a fingerprint sensor, enter a PIN code, speak into a microphone, etc.). Once the user provides the verification, a verification engine on the client verifies the user's identity (e.g., compares the verification data collected from the user with user verification reference data stored in a secure storage of the verifier) and encrypts and/or generates a signature over the random challenge (possibly also over the transaction device ID and/or transaction text) using a private key associated with the verification device. The verification response is then transmitted to the transaction device at 527.

At 528, if the verification engine has not transmitted a verification response to the transaction device, the transaction device uses the public RPVerifyKey to verify the signature on the serverData (received at 524). Once the serverData is verified, the transaction device knows the public key (uuuth. The transaction device uses the key to verify the verification response. For example, the transaction device may use the public verification key to decrypt or verify a signature generated over the random number and any other relevant information (e.g., transaction text, transaction device ID, etc.). If the transaction device performs a transaction confirmation, the transaction device may verify the transaction text displayed on the client by verifying the signature generated on the transaction text and included in the verification response at 528. Instead of having an cryptographically secure serverData structure, the transaction device may also verify unsigned serverData using an online connection with the relying party if the connection is available (semi-offline).

At 529, a success indication or a failure indication is sent to the client, depending on whether the verification was successful or failed, respectively. If successful, the transaction device will allow the transaction (e.g., debit/credit the account to complete the purchase, pay cash, perform administrative tasks, etc.). If it fails, the transaction device will not allow the transaction and/or request additional verification.

At 530, the transaction device may transmit 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).

As shown in FIG. 6, in one embodiment, a mobile application 601 is executed on a client to perform the operations described herein in conjunction with an authentication client 602 (which may be the secure transaction service 201 and interface 202 shown in FIG. 2B). In particular, the mobile application 601 may use the Transport Layer Security (TLS) protocol or other secure communication protocol to open a secure channel to a web application 611 executing on the transaction device 450. The web server 612 on the transaction device may also open a secure channel to communicate with the relying party 451 (e.g., to retrieve the authentication request and/or provide updates to the relying party 451 as described above). The verification client 602 may communicate directly with the relying party 451, for example, to retrieve a cacheable verification request (as discussed in detail above).

In one implementation, the verification client 602 may identify the relying party and any authorized mobile applications 601 having an "AppID," which is a unique code associated with each application available to the relying party. In some embodiments where a relying party provides multiple online services, a user may own multiple appids in a single relying party (the relying party provides one AppID for each service).

In one embodiment, any application identified by an AppID may have multiple "facets" (facets) that identify the allowed mechanisms and/or application types for connecting with a relying party. For example, a particular relying party may allow access via a Web service and via different platform-specific mobile applications (e.g., Android applications, iOS applications, etc.). Each of these items may be identified using a different "facetID," which, as shown, the relying party may provide to the verification engine.

In one implementation, calling mobile application 601 passes its AppID to an API exposed by authentication client 602. On each platform, the authentication client 602 identifies the calling application 601 and determines its facetID. The authentication client then parses the AppID and checks if the FacetID is contained in the TrustedApp list provided by the relying party 451.

In one embodiment, the cacheable verification request described above can be implemented using an anonymous token such as that shown in fig. 7 and 8. In the embodiments of the invention described herein, the token recipient (transaction device 450) needs to be able to verify the token, the validation response, and the binding of the token and validation response without requiring another "online" connection to be established with the token issuer (relying party).

Two classes of anonymous tokens should be distinguished:

1. tokens that can only be verified by a receiving party (e.g., transaction device 450) using a different channel to an issuing party (e.g., relying party 451), such tokens must exist between token issuing and token verification. Such tokens are referred to herein as "unsigned tokens".

2. A token that can be verified by a recipient because it has an encrypted structure (e.g., because it contains a digital signature described below) that can be verified using data received from a token issuer (in a manner that is suitable for use prior to issuance of the particular token). Such tokens are referred to herein as "signed tokens".

The term "signed token structure" is used herein to refer to both a signed token containing a uuuth.

Binding a signed token to an authentication key

As shown in fig. 7, in one embodiment, to bind the signed token to the verification key, the token issuer (e.g., relying party 451): (a) pub 702 a verification public key (uuuth. pub) to a part to be signed 701 of a (to be) signed token; and (b) adding the signed token to the portion of the authentication response to be signed. By doing so, the token recipient (e.g., transaction device 450) is able to verify the token by verifying the signature 703 (e.g., the public RPVerifyKey described above). If the verification is successful, the token recipient can extract the public key (uuth.

Binding an unsigned token to an authentication key

As shown in fig. 8, to bind the unsigned token 802 to the verification key, in one embodiment, the token issuer (e.g., relying party 451) creates a signed structure that covers (at least) the original token 802 and the data to be signed 801, including the verification public key (uauth. The signed structure can be verified by verifying the signature 803 using a public key (e.g., the RPVerifyKey pair described above) associated with the private signature key. The public signing key needs to be shared with the token recipient (e.g., transaction device 450). The sharing can be done once after the generation of the signing key pair, which is suitable for use before the generation of the first signed structure.

The techniques described herein support both "all offline" implementations (i.e., the transaction apparatus 450 is not connected to the relying party 451 at the time of the transaction) and "semi-offline" implementations (i.e., the transaction apparatus is connected to the relying party 451 at the time of the transaction, but the client is not connected to the relying party).

Even in the all offline case, it is still desirable that the transaction device 450 be connected to the relying party 451 via the host from time to time. For example, the host may collect all responses stored in the transaction device 450 for sending to the relying party, and may also update (if needed) a list of revoked Uauth keys (e.g., public authentication keys that have been revoked since the last connection).

Some embodiments also support pure (session) authentication and transaction confirmation. Even in the case of transaction confirmation, if the transaction device 450 submits the transaction text to the relying party 451 along with the validation response, the relying party 451 is able to verify the transaction.

There are several different use cases/applications for the techniques described herein. For example:

1.paymentThe user has registered his/her authenticator (e.g., smartphone) with a Payment Service Provider (PSP). The user wants to verify payment at some merchants using a point of sale device (PoS) authorized by the PSP, but the PoS does not establish a reliable and permanent online connection with the PSP (e.g., in a bus). In this example, the PoS may be implemented as a transaction device 450 and the PSP may be implemented as a relying party 451 as described above, thereby allowing transactions to be conducted despite the absence of a reliable and permanent connection.

2.Internet of thingsCompanies have installed several embedded devices (e.g., in factories, buildings, etc.). Maintenance of such devices is performed by technicians employed by the contractors. To perform maintenance, the technician must authenticate to the device in order to prove his/her competency in performing the task. Some assumptions were made (based on actual framework conditions) as follows:

a. the technician cannot perform registration with each such device (because there are too many such devices).

b. Due to the large number of technicians, and the considerable variation of such technicians, there is no guarantee that the list of qualified technicians on each device is always up to date.

c. At maintenance time, neither the device nor the technician's computer has a reliable network connection.

Using the techniques described above, a company is able to inject a trust anchor (e.g., a public RPVerifyKey) into all devices at once (e.g., at installation time). Each technician then registers with a contracting party (e.g., relying party 451, which may be the technician's employer). Using the above techniques, the technician will be able to authenticate to each device.

The embodiments of the present invention described above may be implemented in any system in which a client with authentication capabilities registers with a relying party and performs authentication operations between the client and a device that (a) functions on behalf of the relying party and (b) is offline at the time of a transaction (i.e., no reliable network connection is established with the relying party origin server with which the client has registered). In this case, the client receives the cacheable authentication request from the origin server and caches the authentication request. Once the authentication response is needed, the client computes and sends the authentication response to the device.

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 so, the relying party's origin server can verify that the request has been received by a legitimate client (rather than some intermediary).

In one embodiment, the relying party adds additional verified data to the response, such as a uuuth. In another embodiment, the relying party requires the user of the client to successfully perform authentication before issuing a "cacheable" authentication request (to prevent a denial of service attack). In one embodiment, the relying party asks the client to indicate whether the required request is cacheable or non-cacheable. If cacheable, the relying party may need additional verification data (e.g., MaxCacheTime, described above) in the response.

In one embodiment, a device (such as transaction device 450) does not establish a direct network connection with a relying party, but rather uses a separate computer (sometimes referred to herein as a "host") to "synchronize" with the relying party. The host retrieves all authentication responses collected from the device and transfers them to the relying party. In addition, the host may also copy a list of revoked Uauth keys to the device to ensure that none of the revoked keys are used in the authentication response.

In one embodiment, a device (such as the transaction device 450) sends a random value (e.g., a random number) to a client, which then cryptographically adds the random value as an extension to (before signing) a verification response. This signed random value is used to prove the freshness of the device.

In one embodiment, the client's verifier adds the current time Ta as an extension to the verification response (before signing the verification response). The device/transaction device may compare this time to the current time Td and accept the response only if the difference between Ta and Td is acceptable (e.g., if the difference is less than two minutes (abs (Td-Ta) < 2 min)).

In one embodiment, the dependency direction may cache requests to add a verified (i.e., signed) deadline. As described above, the device/transaction device will accept the response and treat it as valid only if it is received before the expiration time.

In one embodiment, the relying party may cache a request to add a verified (i.e., signed) data block (e.g., the "signed token structure" mentioned above) that includes additional information such as, but not limited to, a public key, an expiration time, 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 accept the response and treat it as valid only if the signed data block can be verified as valid and the content acceptable.

In one embodiment, the relying party only adds the unsigned token to the cacheable verification request, but the transaction device has an online connection with the relying party at the time of the transaction. The transaction device verifies the authenticity of the unsigned token at the time of the transaction using an online connection with the relying party.

FIG. 9 illustrates exemplary "offline" and "semi-offline" verification scenarios, according to one embodiment of the invention. In this embodiment, the user owning the computing device 910 has established a relationship with the relying party 930 and can authenticate to the relying party. However, in some cases, the user wants to perform a transaction (e.g., verify a transaction confirmation) with a device 970 that has established a relationship with the relying party 930, but not necessarily with the user's computing device 910. For this embodiment, if connection 920 and connection 921 are not present or are not stable at the relevant time (e.g., the time the user's computing device 910 is authenticated to device 970, or the time a transaction is conducted between the user's computing device 910 and device 970), then the transaction is referred to as being "completely offline". For this embodiment, if the connection 920 between the user's computing device 910 and the relying party 930 is unstable, but the connection 921 between the device 970 and the relying party 930 is stable, then the transaction is referred to as "semi-offline". Note that in this embodiment, the connection 922 between the user's computing device 910 and the device 970 is required to be stable at the relevant time. It is also desirable that the verifier be connected to the user's computing device 910. Connection 922 may be implemented using any type of communication channel/protocol, including but not limited to: bluetooth, Bluetooth Low energy (BTLE), Near Field Communication (NFC), Wifi, 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 apparatus

Fig. 10 is a block diagram illustrating exemplary clients and servers that may be used in some embodiments of the invention. It should be appreciated that while FIG. 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 germane to the present invention. It should be understood that other computer systems having fewer components or more components may also be used with the present invention.

As shown in fig. 10, computer system 1000, which is one form of a data processing system, includes a bus 1050 that couples processing system 1020, a power supply 1025, memory 1030, and non-volatile memory 1040 (e.g., hard disk drive, flash memory, Phase Change Memory (PCM), etc.). The bus 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 the instructions from the memory 1030 and/or the non-volatile memory 1040 and execute the instructions to perform the operations described above. The bus 1050 interconnects the above components together, and also interconnects those components to an optional base 1060, a display controller and display device 1070, an input/output device 1080 (e.g., a NIC (network interface card), cursor controls (e.g., a mouse, touch screen, touch pad, etc.), a keyboard, etc.), and an optional wireless transceiver 1090 (e.g., bluetooth, WiFi, infrared, etc.).

FIG. 11 is a block diagram illustrating an exemplary data processing system that may be used in some embodiments of the present invention. For example, the data processing system 190 may be a handheld computer, a Personal Digital Assistant (PDA), a mobile telephone, a portable gaming system, a portable media player, a tablet computer, or a handheld computing device (which may include a mobile telephone, a media player, and/or a gaming system). As another example, the data processing system 1100 may be a network computer or an embedded processing device within another device.

The exemplary architecture of the data processing system 1100 may be used for the mobile devices described above, in accordance with one embodiment of the present invention. Data processing system 1100 includes a processing system 1120 that may include one or more microprocessors and/or systems on integrated circuits. Processing system 1120 is coupled to memory 1110, power supply 1125 (which includes one or more batteries), audio input/output 1140, display controller and display device 1160, optional input/output 1150, input device 1170, and wireless transceiver 1130. It is to be appreciated that other components not shown in FIG. 11 may also be part of data processing system 1100 in certain embodiments of the present invention, and that fewer components than shown in FIG. 11 may be used in certain embodiments of the present invention. In addition, it should be understood that one or more buses, not shown in FIG. 11, may be used to interconnect the various components as is well known in the art.

Memory 1110 may store data and/or programs for execution by data processing system 1100. Audio input/output 1140 may include a microphone and/or speaker, for example, to play music, and/or to provide telephone functionality through the speaker and microphone. The display controller and display 1160 may include a Graphical User Interface (GUI). A wireless (e.g., RF) transceiver 1130 (e.g., a WiFi transceiver, an infrared transceiver, a bluetooth transceiver, a wireless cellular telephone transceiver, etc.) may 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 may be a keypad, keyboard, touch panel, multi-touch panel, etc. Optional other input/outputs 1150 may be connectors of the base.

Apparatus and method for efficient challenge-response verification

The challenge-response protocol with cryptographic signatures in the response is the most advanced technique for authentication (e.g., such as specified in the current FIDO protocol), transaction validation (e.g., such as Android protection validation), and other security purposes (see, e.g., SafetyNet). As shown in fig. 12, the client device 1210 generally requires the server 1211 (at 1201) to generate and remember a random challenge and send the challenge to the client (at 1202). The client computes a response 1203 that includes a signature generated using challenge 1202. The client transmits this response 1204, including the signature, to the server 1211, which must verify and transmit a confirmation 1205 if successful (i.e., if the signature is verified). The server 1211 will only accept responses related to the challenge 1202 that the server has stored for subsequent use. The reason for this approach is the need to prevent replay attacks, i.e. attacks where some entities can only capture a response and replay it for verification. Unfortunately, this requires an additional communication round trip.

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 time of the challenge) to ensure that it is not a replay attack.

Although communication is typically quite fast, round trips still take a significant amount of time. Therefore, reducing the time for one of the two round trips would significantly improve the speed of these operations.

To address this limitation, one embodiment of the invention locally generates the challenge in a predetermined manner, thereby avoiding client-to-server requests for the challenge and subsequent servers. Fig. 13 illustrates a particular embodiment in which a client device 1310 and a server 1311 may initially establish a TLS (transport layer security) channel at 1300. The verification engine 1313 of the client device 1310 includes a local challenge generator 1320 that locally generates a challenge at 1301. Once generated, the verification engine 1313 generates a challenge response 1302 that includes a signature on the challenge. The challenge response is transmitted at 1303 and challenge verification logic/circuitry 1321 on the server 1311 verifies the challenge at 1304 and the response at 1305. The server 1311 holds the challenge and AppID for a specified duration, as described below (e.g., until the server now > the application now + X + more). In one embodiment, the challenge verification logic/circuit 1321 performs verification at 1304 through 1305 by independently generating a challenge and signature and comparing the signature and/or challenge with the signature and/or challenge received by the client device 1310. If the verification is successful, the server 1311 transmits an acknowledgement at 1306.

With this approach, the need for additional round trips is eliminated while still preserving the replay attack protection features of the protocol. In one particular implementation, assuming that the client 1310 and the server 1311 have access to the same "defined prefix," the following is performed.

At 1301 and/or 1304, the challenge is generated as a defined-prefix (current-time) using a key derivation function. In one embodiment, the key derivation function includes Argon2 with a set of predefined parameters such as salt (for cryptographic hashing), parallelism, number of required return bytes, amount of memory to be used, number of iterations to be performed, version number, and/or key. In another embodiment, the key derivation function comprises a cipher-based key derivation function 2(pbkdf 2); however, any similar function may be employed. One purpose of this functionality is to make it time consuming to generate results c for many different inputs (defining a prefix and a current time).

A response defined by the underlying challenge-response protocol is computed at 1302. Various different challenge-response protocols may be used, including but not limited to FIDO, safetyNet, and Android protection validation.

The challenge response, including the "current time," is transmitted to the server 1311 at 1303. The server verifies that the "current time" is within the designated acceptance window and stores value "c" until the window is exceeded. This means that the server 1311 will reject responses indicating that they have generated for more than a threshold amount of time in the past (e.g., more than 60 seconds, 90 seconds, 120 seconds, etc.) or indicating that they have generated in the far future (e.g., more than 10 seconds).

An exemplary time acceptance window 1401 is shown in fig. 14. The acceptance window is chosen to be large enough to allow clock skew (i.e., inaccuracy between the notions of time on the client side and the server side), but still small enough to allow the server to remember all the values "c" that appear in a correctly signed response. In one embodiment, the server 1311 will also reject responses containing a known value "c" signed by the same encryption key (e.g., initial value "c"). If acceptable, the server 1311 returns the requested data or sends an acknowledgement of the intended operation at 1305.

By way of example, in fig. 14, t1 is too early and therefore considered outside of this window; the response will not be accepted. Time t2 is just inside the acceptance window; if the relevant challenge has not been remembered by the server, the response will be accepted. Time t3 is too late and therefore considered outside of the window; the response is not accepted.

Thus, one embodiment of the invention implements a cryptographic challenge-response protocol in which the local challenge generator 1320 generates a challenge and a cryptographic signature over the challenge using a private key (e.g., stored in the secure storage 1325), and in which the relevant public key is known to the challenge verification circuitry/logic 1321 on the server 1311. The challenge verification circuitry/logic 1321 uses the public key to verify the cryptographic signature and rejects all responses that do not have a valid cryptographic signature. In one embodiment, the local challenge generator 1320 generates the challenge c using a key derivation function, and the server verifies whether the challenge c is "fresh" based on verifying that the input data to generate the challenge is acceptable (e.g., that the dynamic input data is acceptable and the defined prefix is the expected defined prefix). The server 1311 maintains all used challenges associated with the respective cryptographic public keys for a defined time in order to prevent replay attacks.

In one implementation, the dynamic input data of the key derivation function is a current time known to the client device 1310, and wherein the challenge verification circuit/logic 1321 determines that the dynamic input data is acceptable within the acceptance window. Alternatively or in addition, the dynamic input data can be previously exchanged data, such as unique data generated as part of the establishment 1300 of the TLS session.

The key derivation function used may be Argon2, pbkdf2, or some other cryptographic hash function. The key derivation functions may also include hash functions, such as SHA256 and SHA-3. In addition, defining prefix variables may include FIDO AppID/RpIdo

The challenge-response protocol may include any type of challenge-response protocol, including FIDO registration/makeCredental operations, FIDO verification/getAssertion operations, Google safetyNet protocol, or Android protection validation.