HK1236268B - System and method for authenticating a client to a device - Google Patents

Description

System and method for authenticating a client to a device

Background Art

Technical Field

The present invention generally relates to the field of data processing systems. More particularly, the present invention relates to systems and methods for authenticating a client to a device, such as an offline device or a device with limited connectivity to a relying party.

Description of related fields

FIG1 illustrates an exemplary client 120 having a biometric device 100. During normal operation, the biometric sensor 102 reads raw biometric data from the user (e.g., captures the user's fingerprint, records the user's voice, takes a photo of the user, etc.), and the feature extraction module 103 extracts specified features from the raw biometric data (e.g., focusing on certain areas of the fingerprint, certain facial features, etc.). The matcher module 104 compares the extracted features 133 with biometric reference data 110 stored in secure storage on the client 120 and generates a score 153 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 the user enrolls a fingerprint, voice sample, image, or other biometric data with the device 100. The application 105 can then use the score 135 to determine whether authentication was successful (e.g., whether the score is above a specified threshold).

Systems that use biometric sensors to provide secure user authentication over a network have also been designed. In such systems, a score 135 and/or other authentication data generated by an application 105 can 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 registration and authentication over a network that provides strong authentication (e.g., protection against identity theft and phishing), secure transactions (e.g., protection against “in-browser malware” and “man-in-the-middle” attacks during transactions), and registration/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 authentication framework described in the '801 application. Some of these improvements are described in the following set of U.S. patent applications (the "co-pending applications"), all of which were filed on December 29, 2012 and assigned to the present assignee: Serial No. 13/730,761, entitled "Query System and Method to Determine Authentication Capabilities"; Serial No. 13/730,776, entitled "System and Method for Efficiently Enrolling, Registering, and Authenticating With Multiple Authentication Devices"; Serial No. 13/730,780, entitled "System and Method for Processing Random Challenges Within an Authentication Framework"; Serial No. 13/730,791, entitled "System and Method for Implementing Privacy Classes Within an Authentication Framework"; 13/730,795, entitled “System and Method for Implementing Transaction Signaling Within an Authentication Framework.”

In short, in the authentication techniques described in these co-pending applications, a user enrolls with a biometric device on a client to generate biometric template data (e.g., by swiping a finger, taking a photo, recording a voice, etc.); registers the biometric device with one or more servers via a network (e.g., a website or other relying party equipped with a secure transaction service as described in the co-pending applications); and then authenticates with those servers using data exchanged during the enrollment process (e.g., an encryption key pre-set to the biometric 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 applications, sensitive information (such as fingerprint data and other data that can be used to uniquely identify the user) can be maintained locally on the user's client device (e.g., a smartphone, laptop, etc.) to protect the user's privacy.

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG1 illustrates an exemplary client device having biometric authentication capabilities;

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

FIG2C is a transaction diagram illustrating how a key may be registered into an authentication device;

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

FIG4 illustrates an embodiment of the present invention for performing transaction verification using unconnected devices;

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

FIG6 illustrates additional architectural features employed in one embodiment of the present invention;

7 to 8 illustrate different embodiments of bearer tokens used in different embodiments of the present invention;

FIG9 shows exemplary “offline” and “semi-offline” verification scenarios;

FIG10 illustrates an exemplary system architecture of a client and/or server; and

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

DETAILED DESCRIPTION

The following describes embodiments of devices, methods, and machine-readable media for implementing advanced authentication techniques and associated applications. Throughout the description, for purposes of explanation, numerous specific details are set forth herein to provide a thorough understanding of the present invention. However, those skilled in the art will readily appreciate that the present invention can 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 to avoid obscuring the underlying principles of the present invention.

The embodiments of the present invention discussed below relate to client devices with authentication capabilities (such as biometric devices or PIN entry). These devices are sometimes referred to herein as "tokens," "authentication devices," or "authenticators." While some 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 movements), some embodiments may utilize additional biometric devices, including, for example, fingerprint sensors, 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). Authentication capabilities may also include non-biometric devices, such as Trusted Platform Modules (TPMs) and smart cards.

In specific implementations of mobile biometrics, the biometric device may be remote from the relying party. As used herein, the term "remote" means that the biometric sensor is not part of the security perimeter 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's 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 be able to know whether the device is an authorized device by the relying party (e.g., a device that provides an acceptable level of authentication and integrity protection) and/or whether a hacker has compromised the biometric device. The confidence level of the biometric device depends on the specific implementation of the device.

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

The term "relying party" is sometimes used herein to refer not only to the entity with which a user transaction is attempted (e.g., a website or online service that performs the user transaction), but also to a secure transaction server implemented on behalf of that entity (which can perform the underlying authentication techniques described herein). The secure transaction server that provides remote authentication capabilities can be owned and/or under the control of the relying party, or can be under the control of a third party that provides secure transaction services to the relying party as part of a business arrangement.

As used herein, the term "server" refers to software executed on a hardware platform (or across multiple hardware platforms) that receives requests from clients via a network, then performs one or more operations in response, and transmits a response to the client, which typically includes the results of the operations. The server responds to client requests, thereby providing or helping to provide network "services" to the client. It is worth noting that a server is not limited to a single computer (e.g., a single hardware device for executing server software), but can actually be distributed across multiple hardware platforms, potentially located in multiple geographical locations.

Embodiments of the present invention described herein include techniques for authenticating a user for transactions initiated through a secure transaction device. For example, a transaction may be a withdrawal, transfer, or other user-initiated operation, and the transaction device may be an automated teller machine (ATM), a 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 to purchase goods or services at a retail store or other retail location equipped with a transaction device, withdrawing 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 a technique for verifying a user's identity (i.e., verifying a user) locally, even when the device is offline (i.e., not connected to a backend verification server) or semi-offline (i.e., only periodically connected to a backend verification server). In one embodiment, the user's client device has the ability to cache verification requests generated by a backend verification server (e.g., operating on behalf of a relying party), and the device is provided with the data required to verify the verification response transmitted from the user's client device to the device.

Before discussing the details of these embodiments of the present invention, this article first provides an overview of remote user authentication techniques. These and other remote user authentication techniques are described in co-pending applications, which are assigned to the assignee of the present application and are incorporated herein by reference.

Remote user authentication technology

Figures 2A and 2B show two embodiments of a system architecture comprising a client-side component and a server-side component for remotely verifying a user. The embodiment shown in Figure 2A uses a browser plug-in-based architecture to communicate with a website, while the embodiment shown in Figure 2B does not require a browser. Various verification techniques and associated applications described herein can be implemented on any of these system architectures. For example, the verification engine in the client device described herein can be implemented as a part for a secure transaction service 201 comprising an interface 202. However, it should be noted that the embodiments described above can be implemented using a logical arrangement of hardware and software other than those shown in Figures 2A and 2B.

Turning to Figure 2A, the illustrated embodiment includes a client 200 equipped with one or more authentication devices 210 to 212 for enrolling and authenticating end users. As described above, the authentication devices 210 to 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 capabilities (e.g., an optical scanner and associated software for scanning a user's retina); as well as non-biometric devices such as Trusted Platform Modules (TPMs) and smart cards. A user may enroll a biometric device by providing biometric data (e.g., swiping a finger across a fingerprint device), which the secure transaction service 201 may store as biometric template data in the secure storage device 220 (via interface 202).

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

Authentication devices 210 to 212 are communicatively coupled to the client via 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 to 233 via a network and for interfacing with a secure transaction plug-in 205 executed within the environment of a web browser 204. As shown, the interface 202 may also provide secure access to a secure storage device 220 on the client 200, which stores information related to each of the authentication devices 210 to 212, such as a device identification code (e.g., an authenticator attestation 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, a unique key may be stored in each authentication device and subsequently used when communicating with the server 230 via a network (e.g., the Internet).

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

Secure transaction servers 232-233 are coupled to secure transaction database 240 to store user data, authentication device data, cryptographic keys, and other security information required 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 the secure enterprise or web destination 230 shown in FIG2A. 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 executed on one or more servers to perform the functions described below.

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

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 a verification device within the secure storage device 220. Additionally, the secure transaction servers 232-233 manage a secure transaction database 240 on the server side.

Figure 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 the 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 discussed 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, related private key may be stored in the secure storage 220 on the client. Furthermore, in another embodiment, the key 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 method of generating the key.

A secure key provisioning protocol, such as the Dynamic Symmetric Key Provisioning Protocol (DSKPP), may be used to share keys with the client via a secure communication channel (see, for example, Request 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 FIG2C , once user registration or user verification is complete, server 230 generates a randomly generated challenge (e.g., a cryptographic random number) that the client must present during device registration. This random challenge is valid for a limited period of time. The secure transaction plugin detects the random challenge and forwards it to secure transaction service 201. In response, 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 device's authentication code (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 database 220, and send the key back to secure transaction service 201 using a key provisioning protocol. Once complete, the authenticating device and server 230 share the same key if symmetric keys are used, or different keys if asymmetric keys are used.

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

This secure transaction confirmation is designed to provide enhanced security for certain types of transactions (e.g., financial transactions). In the illustrated embodiment, the user confirms each transaction before conducting it. Using the illustrated technique, the user confirms exactly what transaction they want to conduct and actually conducts the transaction they see in window 301 of the graphical user interface (GUI). In other words, this embodiment ensures that a "man in the middle" (MITM) or "man in the browser" (MITB) cannot modify the transaction text to conduct a transaction that the user has not confirmed.

In one embodiment, the secure transaction plug-in 205 displays a window 301 in the browser environment to display the transaction details. The secure transaction server 201 periodically (e.g., at random intervals) verifies that the text displayed in the window has not been tampered with by anyone (e.g., by generating a hash/signature on 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 the Global Platform organization).

The following example will help highlight the operation of this embodiment. A user selects an item from a merchant website and selects "Checkout." The merchant website sends the transaction to a service provider (e.g., PayPal) that has secure transaction servers 232-233 implementing one or more embodiments of the present invention described herein. The merchant website authenticates the user and completes the transaction.

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

In a browser-based implementation, the secure transaction plug-in 205 displays a window 301 with the 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, application 254 ( FIG. 2B ), or verification device 210 may display window 301. The secure transaction service 201 starts a timer and verifies the contents of 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 the accuracy of the content by comparing it with a hash of the correct content). If it is detected that the content has been tampered with, the generation of the confirmation token/signature is blocked.

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

One embodiment of the present invention implements a query strategy in which a secure transaction server transmits a server policy to a client, indicating the authentication capabilities accepted by the server. The client then analyzes the server policy to identify a subset of authentication capabilities that the server supports and/or that the user has indicated they wish to use. The client then registers and/or authenticates the user using the subset of authentication tokens that matches the provided policy. Consequently, there is less impact on the client's privacy because the client is not required to transmit detailed information about its authentication capabilities (e.g., all of its authentication devices) or other information that could be used to uniquely identify the client.

By way of example and not limitation, a client may include a variety of user verification capabilities, such as a fingerprint sensor, voice recognition, facial recognition, eye/optical recognition, PIN verification, and so on. However, for privacy reasons, a user may not wish to reveal all details of their capabilities to the requesting server. Therefore, using the techniques described herein, a 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 with its own authentication capabilities and select one or more available authentication options.

One embodiment of the present invention utilizes transaction signing on a secure transaction server, allowing the client session to be maintained without maintaining any transaction state on the server. Specifically, transaction details, such as the transaction text, displayed in window 301 can be sent to the client, where they are signed by the server. The server can then verify the validity of the signed transaction response received by the client by verifying the signature. The server does not need to permanently store the transaction content, as doing so would consume significant storage space for a large number of clients and could lead to the possibility of a denial-of-service attack on the server.

One embodiment of the present invention is illustrated in FIG3B , 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 submits the transaction to a secure transaction server 312, which includes signature processing logic 313 for generating and verifying signatures (as described herein) and verification logic 314 for performing client authentication (e.g., using the authentication techniques previously described).

In one embodiment, the verification request sent from the secure transaction server 312 to the client 200 includes a random challenge (such as a cryptographic random number) (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) on the random challenge and 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, for example, swipe a finger on a fingerprint scanner, take a photo, speak into a microphone, or perform any other type of verification permitted for a given transaction. In one embodiment, once the user has successfully passed verification by the verification device 210, the client transmits the following back to the server: (1) a random challenge and transaction text (both of which were previously provided to the client by the server), (2) verification data proving that the user successfully completed verification, and (3) a signature.

The verification module 314 on the secure transaction server 312 can then confirm that the user has been correctly authenticated, and the signature processing logic 313 uses the private key to regenerate a signature on the random challenge and the transaction text. If the signature matches the signature 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. This saves storage and processing resources because the secure transaction server 312 does not need to permanently store the transaction text (or other transaction data) in 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 a user) locally, even when the user device and the device are offline (i.e., not connected to the 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 to the relying party). Figure 4 shows one such arrangement, in which a client 400 having an authentication device previously registered with a relying party 451 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., the Bluetooth Low Energy (BTLE) protocol as proposed in Bluetooth Core Specification Version 4.0). Of course, the underlying principles of the present invention are not limited to any particular communication standard.

As indicated by the dashed arrows, connections between client 400 and relying party 451 and/or between transaction device 450 and relying party 451 may be sporadic or nonexistent. Real-world applications within the payment field often rely on such "offline" use cases. For example, a user with client 400 (e.g., a smartphone) may not be connected to relying party 451 at the time of a transaction, but may want to authorize the transaction (e.g., payment) by authenticating with 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 implemented using a secret such as a personal identification number (PIN) that is to be captured by a device (e.g., a PoS transaction device or ATM). The device will then establish an online connection with the relying party to verify the secret, or will require the user's authenticator (e.g., an EMV bank card) to verify the PIN. This implementation has several disadvantages. The implementation may require an online connection, which may sometimes be available, but not always. The implementation also requires the user to enter a long-term secret into a potentially untrusted device that is subject to the risk of shoulder surfing and other attacks. In addition, the implementation is inherently tied to a specific user verification method (e.g., a PIN in this case). Finally, the implementation requires the user to remember a secret such as a PIN, which may be inconvenient for the user.

The verification techniques described herein allow a user to rely on the verification capabilities of his/her own client, thereby providing significantly greater flexibility in user verification methods and security. Specifically, in one embodiment, a mobile application on a user's client caches a verification request provided by a relying party during the time that the client is connected 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 public key associated with the authenticator) as well as additional information, including a signature on (at least a portion of) the verification request generated by the relying party, a verification key, and potential timing data indicating the time period within which the verification request will remain valid (or conversely, the time after which the verification request will expire). In one embodiment, the mobile application may cache multiple such connection requests (e.g., one request for each transaction device or transaction device type).

In one embodiment, in the event that the client/mobile application is unable to connect with the relying party, the cached verification request can subsequently be used to conduct a transaction with the transaction device. In one embodiment, the mobile application triggers the creation of a verification response based on the cached verification request containing serverData and additional data received from the transaction device. The verification response is then transmitted to the transaction device, which then verifies the verification response using a verification key provided by the relying party (e.g., during the time the transaction device is connected to the relying party). Specifically, the transaction device can use the key provided by the relying party to verify the signature on the serverData included in the verification response. In one embodiment, the relying party uses a private relying party verification key to generate the signature, and the transaction device verifies the signature using a corresponding public relying party verification key (provided by the relying party to the transaction device).

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

In an alternative embodiment described below, the relying party provides a verification request directly to the transaction device (rather than through a mobile application on the client device). In this embodiment, the transaction device can request a verification request from the relying party when it receives a request to complete a transaction from the mobile application on the client. Once the transaction device obtains the verification request, it can verify the request and verification response as described above (e.g., by generating a signature and comparing it to an existing signature).

5A is a transaction diagram illustrating the interactions between client 400, transaction device 450, and a relying party in one embodiment where client 400 caches validation requests. This embodiment is sometimes referred to as a "fully offline" embodiment because it does not require transaction device 450 to have an existing connection to the relying party.

At 501, the 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; at 504, the client caches the authentication request. In one embodiment, the authentication request includes the public key (Uauth.pub) associated with the authenticator to be used for authentication, and a signature generated over the public key and a random number using the relying party's verification key (RPVerifyKey). If asymmetric keys are used, the RPVerifyKey used by the relying party 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 verification request also includes timing information (e.g., MaxCacheTime) indicating the length of time the verification request will remain valid. In this embodiment, the signature of the cacheable verification request can be generated by combining the public verification key, the nonce, and the MaxCacheTime (e.g., ServerData=Uauth.pub|MaxCacheTime|serverNonce|Sign(RPVerifyKey, Uauth.pub|MaxCacheTime|serverNonce)). In one embodiment, the verification response includes more than one verification key (e.g., one verification key for each authenticator capable of verifying the user), and the signature can be generated by all of these keys (e.g., together with the nonce and MaxCacheTime).

As mentioned, the transaction device 450, or any device designed to perform offline verification of authentication requests/responses, needs to know the public RPVerifyKey. This extension is necessary because the transaction device has no knowledge of the verification keys registered with the relying party (i.e., no relationship has been established between the user device and the transaction device). Therefore, the relying party must securely communicate to the transaction device (or other device) information about which keys will be used for verification of the authentication response. The transaction device will check MaxCacheTime to determine whether the cached authentication request is still valid (in order to comply with the relying party's policy on how long a 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 Point-of-Sale (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 present invention are not limited to any particular type of transaction device or secure connection. Additionally, at 505, the client may transmit a 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 (random number), and optionally, transaction text that completes the transaction in a defined syntax. The random challenge/random number will then be cryptographically bound to the verification response. This mechanism allows the device to verify that the user verification is freshly generated and has not been cached/reused.

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

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

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

At 510, depending on whether the verification succeeds or fails, a success indication or a failure indication is sent to the client. If successful, the transaction device will allow the transaction (e.g., debit/credit an account to complete the purchase, pay cash, perform an administrative task, etc.). If unsuccessful, 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 a verification 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).

5B is a transaction diagram illustrating the interactions between client 400, transaction device 450, and a relying party in one embodiment in which the transaction device has a connection to the relying party and receives a verification request from the relying party. This embodiment is sometimes referred to as a "semi-offline" embodiment because, although the client is not connected to the relying party, the transaction device 450 is 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 with a verification request from the relying party. At 523, the relying party generates a verification request and then, at 524, sends it to the transaction device. As in the embodiment shown in FIG5A , the verification request may include the public key (Uauth.pub) associated with the authenticator on the client that will be used for verification, as well as a signature generated using the relying party's verification key (RPVerifyKey) over the public key and a random number. If asymmetric keys are used, the RPVerifyKey used by the relying party to generate the signature is a private key with a corresponding public RPVerifyKey, which the relying party provides to the transaction device (possibly well before processing the user's verification request). Instead of using a cryptographically secure serverData structure, the transaction device may also verify the unsigned serverData using an online connection to the relying party, if available (semi-offline scenario).

In one embodiment, serverData also includes timing information (e.g., MaxCacheTime) indicating the length of time the verification request will remain valid. In this embodiment, the signature of serverData can be generated by combining the public verification key, the random number, and MaxCacheTime (e.g., ServerData=Uauth.pub|MaxCacheTime|serverNonce|Sign(RPVerifyKey, Uauth.pub|MaxCacheTime|serverNonce)). In one embodiment, the verification response includes more than one verification key (e.g., one for each verifier), and the signature can be generated by all of these keys (e.g., together with the random number and MaxCacheTime).

In one embodiment, the remainder of the transaction diagram in FIG5B operates substantially as shown in FIG5A. At 525, the transaction device may transmit identity information (e.g., a transaction device identification code), a random challenge (random number), and optionally, transaction text that completes the transaction in a defined syntax. The random challenge/random number will then be cryptographically bound to the verification response. This mechanism allows the device to verify that the user verification is freshly generated and not already cached.

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

At 526, to generate a verification response, an authentication user interface is displayed to guide the user to perform authentication on the client using a specific authenticator (e.g., swiping a finger on a fingerprint sensor, entering a PIN, speaking into a microphone, etc.). Once the user provides authentication, the authentication engine on the client verifies the user's identity (e.g., comparing the authentication data collected from the user with user verification reference data stored in the authenticator's secure storage device) and encrypts and/or generates a signature on the random challenge (and possibly on the transaction device ID and/or transaction text) using a private key associated with the authentication device. The authentication response is then transmitted to the transaction device at 527.

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

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

At 530, the transaction device may transmit a verification 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 FIG6 , in one embodiment, a mobile application 601 is executed on a client to perform the operations described herein in conjunction with a verification client 602 (which may be the secure transaction service 201 and interface 202 shown in FIG2B ). Specifically, 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 executed 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 verification requests 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 cacheable verification requests (as discussed in detail above).

In one embodiment, the verification client 602 can identify the relying party and any authorized mobile applications 601 with an "AppID," which is a unique code associated with each application available to the relying party. In some embodiments where the relying party offers multiple online services, a user can have multiple AppIDs with 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" that identify the permitted mechanisms and/or application types for connecting to 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., an Android application, an iOS application, etc.). Each of these items may be identified using a different "FacetID," which the relying party may provide to the verification engine as shown.

In one embodiment, the calling mobile application 601 passes its AppID to the API exposed by the verification client 602. On each platform, the verification client 602 identifies the calling application 601 and determines its FacetID. The verification client then resolves the AppID and checks whether the FacetID is included in the TrustedApp list provided by the relying party 451.

In one embodiment, the cacheable authentication request described above may be implemented using a bearer token such as that shown in Figures 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 authentication response, and the binding of the token to the authentication response without requiring another "online" connection to the token issuer (relying party).

Two types of bearer tokens should be distinguished:

1. A token that can only be verified by a recipient (e.g., transaction device 450) using a different channel to the issuer (e.g., relying party 451). This type of token must exist between token issuance and token verification. This type of token is referred to herein as an "unsigned token."

2. A token that can be verified by the recipient because of its cryptographic structure (e.g., because it contains a digital signature as described below), which can be verified using data received from the token issuer (this approach is suitable for use before a particular token is issued). This type of token is referred to herein as a "signed token."

The term "signed token structure" is used herein to refer to both the signed token containing the Uauth.pub key and the signed structure containing the token.

Bind the signed token to the verification key

As shown in Figure 7, in one embodiment, to bind a signed token to a verification key, the token issuer (e.g., relying party 451) (a) adds the verification public key (Uauth.pub) 702 to the (to-be-)signed token's to-be-signed portion 701; and (b) adds the signed token to the to-be-signed portion of the verification response. This allows the token recipient (e.g., transaction device 450) to verify the token by verifying the signature 703 (e.g., the public RPVerifyKey described above). If verification is successful, the token recipient can extract the public key (Uauth.pub) as previously discussed and use it to verify the verification response.

Bind an unsigned token to a verification key

As shown in Figure 8, to bind an unsigned token 802 to a 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.pub)). The signed structure can be verified by verifying the signature 803 using a public key associated with the private signing key (e.g., the RPVerifyKey pair described above). The public signing key needs to be shared with the token recipient (e.g., transaction device 450). Sharing can be done once after the signing key pair is generated, which is suitable for use before the first signed structure is generated.

The technology described in this article supports both "fully offline" specific implementations (i.e., the transaction device 450 is not connected to the relying party 451 at the time of the transaction) and "semi-offline" specific implementations (i.e., the transaction device 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 a fully offline situation, it is still expected that the transaction device 450 will occasionally connect to the relying party 451 via the host. For example, the host can collect all responses stored in the transaction device 450 to send to the relying party, and can also update (if necessary) the 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 as well as transaction confirmation.Even in the case of transaction confirmation, if the transaction device 450 submits the transaction text together with the authentication response to the relying party 451, the relying party 451 can verify the transaction.

The technology described in this article has several different use cases/applications. For example:

1. A paying user has registered their authenticator (e.g., a smartphone) with a payment service provider (PSP). The user wants to use a point-of-sale (PoS) device authorized by the PSP to authenticate payments at certain merchants, but the PoS does not have a reliable and permanent online connection with the PSP (e.g., on a bus). In this example, the PoS can be implemented as a transaction device 450, and the PSP can be implemented as a relying party 451 as described above, thereby allowing transactions to proceed despite the lack of a reliable and permanent connection.

2. The IoT company has installed several embedded devices (for example, in factories, buildings, etc.). Maintenance of these devices is performed by technicians employed by the contractor. To perform maintenance, the technician must authenticate himself/herself to the device to prove his/her qualifications for the task. The following assumptions are made (based on realistic framework conditions):

a. A technician cannot perform registration on every such device (due to the large number of such devices).

b. Due to the large number of technicians and the significant turnover of such technicians, it is not possible to ensure that the list of qualified technicians on each device is always up to date.

c. Neither the device nor the technician's computer had a reliable network connection at the time of maintenance.

Using the techniques described above, a company can inject a trust anchor (e.g., a public RPVerifyKey) into all devices once (e.g., at installation time). Each technician then registers with a contracted party (e.g., relying party 451, which can 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 can be implemented in any system in which a client with authentication capabilities registers with a relying party and authentication operations are performed between the 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 relying party's origin server with which the client has registered). In this case, the client receives a cacheable authentication request from the origin server and caches the authentication request. Once an authentication response is required, the client calculates the authentication response and sends it to the device.

In another embodiment, the client adds the channel binding data (received in the verification request) to the response in a cryptographically secure manner. By doing this, the original server of the relying party can verify that the request has been received by a legitimate client (rather than a middleman).

In one embodiment, the relying party adds additional verified data to the response, such as a Uauth.pub key (which allows the device to verify the verification or transaction confirmation response) without having to contact the relying party server to retrieve the approved Uauth.pub key. In another embodiment, the relying party requires the client's user to successfully perform verification before issuing a "cacheable" verification request (to prevent denial of service attacks). In one embodiment, the relying party requires the client to indicate whether the requested request is cacheable or non-cacheable. If cacheable, the relying party may require additional verification data in the response (e.g., the MaxCacheTime described above).

In one embodiment, a device (such as transaction device 450) does not establish a direct network connection with a relying party, but instead uses a separate computer (sometimes referred to herein as a "host") to "sync" with the relying party. The host retrieves all verification 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 no revoked keys are used in the verification responses.

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

In one embodiment, the client's authenticator adds the current time, Ta, as an extension to the authentication response (before signing the authentication response). The device/transaction device can compare this 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 two minutes (abs(Td-Ta)<2min)).

In one embodiment, the relying party adds a verified (ie, signed) expiration time to the cacheable request. As described above, the device/transaction device will only accept the response and regard it as valid if it receives the response before the expiration time.

In one embodiment, the relying party adds a validated (i.e., signed) data block (e.g., the "signed token structure" mentioned above) to the cacheable request, which 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 only accept the response and consider it valid if the signed data block can be verified as valid and the content is 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 uses the online connection with the relying party to verify the authenticity of the unsigned token at the time of the transaction.

Figure 9 illustrates exemplary "offline" and "semi-offline" authentication scenarios according to one embodiment of the present invention. In this embodiment, a user with computing device 910 has already established a relationship with relying party 930 and can authenticate with it. However, in some cases, the user wishes to perform a transaction (e.g., verify a transaction confirmation) with device 970, which has already established a relationship with relying party 930 but not necessarily with the user's computing device 910. For purposes of this embodiment, if connection 920 and connection 921 are not present or unstable at the relevant time (e.g., when the user's computing device 910 authenticates with device 970, or when the transaction is conducted between the user's computing device 910 and device 970), the transaction is considered "fully offline." For purposes of this embodiment, if connection 920 between the user's computing device 910 and relying party 930 is unstable, but connection 921 between device 970 and relying party 930 is stable, the transaction is considered "semi-offline." Note that in this embodiment, connection 922 between the user's computing device 910 and device 970 is required to be stable at the relevant time. It is also desirable for the authenticator to be connected to the user's computing device 910. The 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), 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 apparatus

FIG10 is a block diagram illustrating an exemplary client and server that may be used in some embodiments of the present invention. It should be understood that although FIG10 illustrates various components of a computer system, it is not intended to represent any particular architecture or manner of interconnecting components, as such details are not germane to the present invention. It should be understood that other computer systems having fewer or more components may also be used with the present invention.

As shown in Figure 10, computer system 1000, which is a form of data processing system, includes a bus 1050 that is 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 1050 can be connected to each other through various bridges, controllers, and/or adapters as are well known in the art. The processing system 1020 can retrieve instructions from the memory 1030 and/or the non-volatile memory 1040 and execute these instructions to perform the operations described above. The bus 1050 interconnects the above components 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), a cursor control (e.g., a mouse, touch screen, touchpad, etc.), a keyboard, etc.), and an optional wireless transceiver 1090 (e.g., Bluetooth, WiFi, infrared, etc.).

Figure 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 computer, or a handheld computing device (which may include a mobile phone, a media player, and/or a gaming system). For another example, data processing system 1100 may be a network computer or an embedded processing device within another device.

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

Memory 1110 can store data and/or programs for execution by data processing system 1100. Audio input/output 1140 can include a microphone and/or speaker to (for example) play music, and/or provide telephone functionality through the speaker and microphone. Display controller and display device 1160 can include a graphical user interface (GUI). Wireless (e.g., RF) transceiver 1130 (e.g., WiFi transceiver, infrared transceiver, Bluetooth transceiver, wireless cellular phone transceiver, etc.) can be used to communicate with other data processing systems. The 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. Optional other input/output 1150 can be a connector for the base.

Embodiments of the present invention may include the various steps set forth above. These steps may be embodied as machine-executable instructions that cause a general-purpose processor or a special-purpose processor to perform certain steps. Alternatively, these steps may be performed by specific hardware components that contain hard-wired logic for performing these steps, or by any combination of programmed computer components and custom hardware components.

Element of the present invention can also be provided as machine-readable medium for storing machine executable program code.Machine-readable medium can include but is not limited to floppy disk, optical disk, CD-ROM and magneto-optical disk, ROM, RAM, EPROM, EEPROM, magnetic card or optical card or other types of medium/machine-readable medium that are suitable for storing electronic program code.

Throughout the foregoing description, for the purpose of explanation, many specific details have been set forth in order to provide a thorough understanding of the present invention. However, it will be readily 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. In some embodiments, virtually any type of client or peer data processing device may be used, including, for example, a desktop computer or a workstation computer. Therefore, the scope and spirit of the present invention should be determined based on the appended claims.

Embodiments of the present invention may include the various steps set forth above. These steps may be embodied as machine-executable instructions that cause a general-purpose processor or a special-purpose processor to perform certain steps. Alternatively, these steps may be performed by specific hardware components that contain hard-wired logic for performing these steps, or by any combination of programmed computer components and custom hardware components.

Claims (15)

1. A method for verifying a client using a dependent direction transaction device, comprising: Register the client's authenticator with the dependent party, the registration allowing the client's user to remotely authenticate the user with the dependent party via the network; At least a first verification structure is generated at the dependent party using a first verification key associated with the verifier and a signature generated by the first verification key; The first verification structure is cached on the client. Provide the transaction device with a second verification key corresponding to the first verification key; and A verification transaction is performed between the client and the transaction device, wherein the client uses a second verification key associated with the first verification key to generate a second verification structure, the transaction device uses the second verification key to verify the signature on the first verification structure, and uses the first verification key to verify the second verification structure, wherein the first verification key and the second verification key are the same key, and/or the first verification key and the second verification key are the same key. 2. The method according to claim 1, wherein the first verification key is a private key used to generate the signature, and the second verification key provided to the transaction device is a corresponding public verification key capable of verifying the signature. 3. The method of claim 1, wherein the second verification key includes a private verification key associated with the verifier, and the first verification key is a corresponding public verification key. 4. The method of claim 1, wherein the first verification key includes a public key (Uauth.pub) associated with the verifier, and the signature is generated using the first verification key on at least the public key. 5. A method for verifying a client using a dependent direction transaction device, comprising: Register the client's authenticator with the dependent party, the registration allowing the client's user to remotely authenticate the user with the dependent party via the network; At least a first verification structure is generated at the dependent party using a first verification key associated with the verifier and a signature generated by the first verification key; In response to a user request to initiate a transaction through the transaction device, the first verification structure is stored on the transaction device; Provide the transaction device with a second verification key corresponding to the first verification key; A verification transaction is performed between the client and the transaction device, wherein the client uses a second verification key associated with the first verification key to generate a second verification structure, the transaction device uses the second verification key to verify the signature on the first verification structure, and uses the first verification key to verify the second verification structure, wherein the first verification key and the second verification key are the same key, and/or the first verification key and the second verification key are the same key. 6. The method of claim 5, wherein the first verification key includes a public key (Uauth.pub) associated with the verifier, and the signature is generated using the first verification key on at least the public key. 7. The method of claim 6, wherein the first verification structure comprises a combination of the following: a random number generated by the dependent party, the public key, and the signature generated on the combination of the random number and the public key. 8. The method of claim 6, wherein the first verification structure comprises a combination of the following: a random number generated by the dependent party, cached timing data indicating the amount of time the first verification structure can be cached on the client, the public key, and the signature generated on the combination of the random number, the cached timing data, and the public key. 9. The method of claim 6, wherein the second verification structure comprises a random number or a value provided by the transaction device, and a signature generated by applying the second verification key to at least the random number and/or the value provided by the transaction device. 10. The method of claim 6, wherein the second verification structure includes a signature generated by applying the second verification key to transaction text securely displayed on the client during a transaction with the transaction device. 11. The method of claim 10, wherein the signature is verified by the transaction device and/or the dependent party using the first verification key. 12. A method for verifying a client using a dependent direction transaction device, comprising: Register the client's authenticator with the dependent party, the registration allowing the client's user to remotely authenticate the user with the dependent party via a network, wherein the authenticator includes a biometric device to be registered; At least the first verification key associated with the verifier is used to generate the first verification structure through the dependent party; The first verification structure is cached on the client; and A verification transaction is performed between the client and the transaction device, wherein the client uses a second verification key associated with the first verification key to generate a second verification structure, the transaction device uses an online or out-of-band connection with the dependent party to verify the first verification structure, and uses the first verification key to verify the second verification structure, wherein the first verification key and the second verification key are the same key. 13. The method of claim 12, wherein the first verification key includes a public key (Uauth.pub) associated with the verifier. 14. The method of claim 13, wherein the first verification structure comprises a combination of: a random number generated by the dependent party, the public key, and a signature generated on the combination of the random number and the public key. 15. The method of claim 13, wherein the first verification structure comprises a combination of: a random number generated by the dependent party, cached timing data indicating the amount of time the first verification structure can be cached on the client, the public key, and a signature generated on the combination of the random number, the cached timing data, and the public key.