HK1219326B - Advanced authentication techniques and applications - Google Patents

Description

Advanced Verification Techniques and Applications

Background Art

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of and priority to co-pending U.S. Provisional Patent Application No. 61/804,568, filed on March 22, 2013, entitled “Advanced Methods of Authentication And Its Applications.”

This application is a continuation-in-part of U.S. patent application Ser. No. 14/066,384, filed on Oct. 29, 2013, and entitled “Apparatus and Method For Implementing Composite Authenticators.”

This application is also a continuation-in-part of U.S. patent application 14/145,439, filed on December 31, 2013, entitled “System and Method For Non-Intrusive, Privacy-Preserving Authentication,” which also claims the benefit of and priority to co-pending U.S. provisional patent application No. 61/804,568, filed on March 22, 2013, entitled “Advanced Methods of Authentication And Its Applications.”

This application is also a continuation-in-part of U.S. patent application Ser. No. 14/145,466, filed on Dec. 31, 2013, entitled “System and Method For Adaptive User Authentication,” which also claims the benefit of and priority to co-pending U.S. provisional patent application Ser. No. 61/804,568, filed on Mar. 22, 2013, entitled “Advanced Methods of Authentication And Its Applications.”

This application is also a continuation-in-part of U.S. patent application No. 14/145,533, filed on December 31, 2013, entitled “System and Method For Location-Based Authentication,” which also claims the benefit of and priority to co-pending U.S. provisional patent application No. 61/804,568, filed on March 22, 2013, entitled “Advanced Methods of Authentication And Its Applications.”

This application is also a continuation-in-part of U.S. patent application No. 14/145,607, filed on December 31, 2013, entitled “System and Method For Confirming Location Using Supplemental Sensor and/or Location Data,” which also claims the benefit of and priority to co-pending U.S. provisional patent application No. 61/804,568, filed on March 22, 2013, entitled “Advanced Methods of Authentication And Its Applications.”

Technical Field

The present invention generally relates to the field of data processing systems. More particularly, the present invention relates to advanced user authentication techniques and associated applications.

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: No. 13/730,761, Query System and Method to Determine Authentication Capabilities; No. 13/730,776, System and Method for Efficiently Enrolling, Registering, and Authenticating With Multiple Authentication Devices; 13/730,780, System and Method for Processing Random Challenges Within an Authentication Framework; No. 13/730,791, System and Method for Implementing Privacy Classes Within an Authentication Framework; No. 13/730,795, 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 over a network with one or more servers (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.

Authenticators, such as those described above, require some form of user interaction, such as swiping a finger or entering a password. These "normal" authenticators are designed to authenticate a user at a given point in time. Alternatively, "silent" authenticators can be used to authenticate a user's device (rather than the user) at a given point in time. These silent authenticators can rely on information extracted from the user's device and do not require user interaction (e.g., sending a machine ID).

However, in some use cases, requiring explicit user interaction presents too much friction (e.g., near field communication (NFC) payments, frequently used applications that require authentication but are not tied to high-value transactions), while "silent" authentication techniques (such as sending a machine ID) are insufficient to ensure that the device is still in the possession of the legitimate user.

The research community has proposed several "continuous" authentication methods, such as Anthony J. Nicholson, "Mobile Device Security Using Transient Authentication", "IEEE TRANSACTIONS ON MOBILE COMPUTING VOL. 5, NO. 11, pp. 1489-1502 (November 2006); Mohammad O. Derawi, "Unobtrusive User-Authentication on Mobile Phones using Biometric Gait Recognition" (2010); Koichiro Niinuma, Anil K. Jain, "Continuous User Authentication Using Temporal Information”(Koichiro, Niinuma, Anil, K, Jain. Continuous user authentication using temporal information. http://www.cse.msu.edu/biometrics/Publications/Face/NiinumaJain_ContinuousAuth_SPIE10.pdf). Some of these methods have even been adopted by industry, such as BehavioSec, “Measuring FAR/FRR/EER in Continuous Authentication,” Stockholm, Sweden (2009). These methods generally provide a level of assurance that the legitimate user still has possession of the device without adding friction to the authentication process, but these methods focus on a single modality (i.e., using a wearable token, gait recognition, facial and clothing color recognition, and keyboard input from the user).

However, there is a problem that directly providing location data or other personal data (e.g., facial images, clothing color, gait or typing characteristics...) or environmental data (e.g., temperature, humidity, WLAN SSID...) to relying parties to supplement risk assessments violates user privacy in some regions of the world. Therefore, more advanced remote verification technologies are needed that are both non-intrusive and fully protect the privacy of end users.

Additionally, the strength of current authentication methods (e.g., passwords, fingerprint authentication, etc.) is nearly constant over time, but the resulting risk varies based on the current environment in which authentication is performed (e.g., the machine being used, the network to which the machine is connected, etc.) It would be advantageous to select and/or combine authentication modalities based on the currently detected risk.

When considering increasing the assurance level of authentication, we typically think of increasing the assurance level of explicit authentication methods, such as requiring a more complex password or using more accurate biometrics, such as fingerprint or facial recognition. In reality, the assurance level of authentication (or the transaction risk derived from it) also depends on other data, such as whether the authentication is performed from the same device as before, and whether the location of the authentication is actually close to the location of the last successful authentication (for example, it seems unrealistic for a person to authenticate in San Francisco at 1 p.m. and in Tokyo at 2 p.m. on the same day).

Passwords remain the primary explicit authentication method. Unfortunately, passwords are vulnerable to attacks, and those attacks are highly scalable. Furthermore, entering a password is cumbersome, especially on small devices like smartphones. Consequently, many users don't use password-based protection to lock their phones, or they use a trivial PIN code.

Some smartphones are using fingerprint sensors to provide a more convenient way to authenticate. Using biometric forms of authentication has been criticized for not providing sufficient resistance to spoofing attacks and for introducing privacy issues due to the potential failure to properly protect biometric reference data.

Various "fusion" approaches have been proposed that combine multiple biometric modalities. Some address usability by reducing the false rejection rate (FRR), while others address security by reducing the false acceptance rate (FAR). Consequently, these approaches have proposed static fusion algorithms. Unfortunately, this approach still results in varying assurance levels depending on the "other inputs" (as described above).

For certain categories of transactions, the risk associated with the transaction may be inseparable from the location where the transaction is being performed. For example, it may be inappropriate to allow transactions that appear to originate from restricted countries (such as those listed on the U.S. Office of Foreign Assets Control list, such as Cuba, Libya, North Korea, etc.). In other cases, it may be desirable to allow transactions only if stronger authentication mechanisms are used; for example, transactions conducted from within a company's physical location may require less authentication than transactions conducted from a Starbucks located in a remote area where the company does not have business.

However, reliable location data may not be readily available for a variety of reasons. For example, the end user's device may not have GPS capabilities; the user may be located in a location where Wi-Fi triangulation data is unavailable or unreliable; or the network provider may not support cell tower triangulation to augment GPS or Wi-Fi triangulation. Other methods for inferring a device's location may not provide a sufficient level of assurance to meet an organization's needs; for example, a reverse IP lookup used to determine geographic location may not be granular enough or may be masked by a proxy designed to obscure the true network origin of the user's device.

In these cases, organizations seeking to assess the riskiness of a transaction may need additional data to provide them with additional assurance that the individual is located within a specific geographic region to drive the verification decision.

Another challenge for organizations deploying authentication is matching the "strength" of the authentication mechanism to the inherent risks presented by the specific user's environment (location, device, software, operating system), the requests made by the user or device (requests to access restricted information or perform specific actions), and the organization's management policies.

Until now, organizations have had to rely on a fairly static response to user authentication needs: they assess the risks users face during the course of their normal operations, as well as any applicable regulatory mandates, and then deploy authentication solutions to mitigate those risks and achieve compliance. To do this, organizations often need to deploy multiple authentication solutions to address the diverse range of risks different users may face, which can be extremely expensive and cumbersome to manage.

The technology described in the co-pending application provides an abstraction that allows organizations to identify existing capabilities on user devices that can be used for authentication. This abstraction eliminates the need for organizations to deploy multiple different authentication schemes. However, organizations still need a way to invoke the "correct" authentication mechanism when necessary. Existing implementations do not provide organizations with the ability to describe which authentication mechanism is applicable in which situations. As a result, organizations will likely need to codify their authentication policies, which makes the solution brittle and requires future code changes to use new authentication devices/tokens.

Today, electronic financial transactions are primarily conducted over the World Wide Web using browser applications. Websites like Amazon.com, Dell, and Walmart sell billions of dollars worth of goods through their online portals, while banks and brokerage firms allow their customers to transfer billions of dollars between accounts online. One challenge facing these websites and others is detecting fraudulent activity. Fraudulent transactions can cost these companies billions of dollars.

The first line of defense against fraudulent transactions is the user's password. However, criminals can obtain passwords through a variety of techniques. Sometimes, passwords lack sufficient complexity and can be easily guessed or determined through brute-force attacks. Other times, malware, worms, or viruses infect a user's computer. Passwords can be obtained by logging keystrokes or scanning memory or hard drive storage devices. If the physical device is stolen, the password can be retrieved from the data stored in the memory or storage device. Once the password is compromised, criminals can access accounts and withdraw or transfer funds.

To help prevent losses due to compromised user passwords, websites that process financial transactions employ risk assessments, using various metrics to determine whether the person initiating the transaction is actually the account holder. Factors such as the time of transaction, location, and environment are all good ways to assess whether a transaction is risky. For example, if a user typically does not perform any activity on their account at night, they will be less likely to initiate a transaction at 3:00 AM than at 3:00 PM. Similarly, if a user lives in the United States but initiates a transaction in South Korea, this location discrepancy would be a warning sign. Finally, if the amount being processed is significantly different in magnitude than usual, this is another sign of potential fraud.

Unfortunately, web browsers place very strict restrictions on what information websites can access from client systems. Because browsers expose users' machines to the outside (and potentially malicious) world, leaking any unnecessary data creates a security risk. Of course, it's possible to record transaction times, transaction locations (e.g., via the user's IP address), and transaction amounts. Websites currently use all of this data to determine whether a transaction is fraudulent. However, beyond this basic snippet of information provided by the browser, websites lack additional information to use for risk assessment. Due to the limitations on what information browsers can access, risk assessments of user transactions are not very accurate.

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 equipped with a biometric device;

FIG2 illustrates one embodiment of a non-intrusive privacy preserving authenticator (NIPPA);

FIG3 graphically illustrates the operation of one embodiment of the present invention during and after a “valid user state”;

FIG4 illustrates an embodiment of a non-intrusive privacy-preserving authentication method;

FIG5 illustrates a distance function for location-based authentication in one embodiment;

FIG6 graphically illustrates the operation of one embodiment of the present invention using an extended valid user status window;

FIG7 illustrates an adaptive verification module according to an embodiment of the present invention;

FIG8 illustrates an embodiment of an adaptive verification method;

FIG9 graphically illustrates adaptive verification according to one embodiment;

FIG10 illustrates one embodiment of a composite validator having multiple components.

FIG11 illustrates one embodiment where two validators share components.

12 illustrates one embodiment of an authenticator including component authentication logic that manages component authentication key (CAK) pairs used to authenticate components.

FIG13 shows a transaction diagram illustrating one embodiment of authentication between two components.

FIG14 illustrates a static verifier according to one embodiment of the present invention.

FIG15 illustrates a dynamic validator according to one embodiment of the present invention.

FIG16 illustrates an exemplary system architecture upon which embodiments of the present invention may be implemented.

FIG17 illustrates one embodiment of a system for executing a location-aware application for authentication policies;

FIG18 illustrates an exemplary set of authentication policy rules;

FIG19 illustrates a method according to one embodiment of the present invention;

FIG20 illustrates an embodiment of the present invention in which location is determined or confirmed by the proximity of other peer devices or network devices;

FIG21 illustrates one embodiment of a verification system using environmental sensors;

FIG22 illustrates one embodiment of a verification method using an environmental sensor;

FIG23 illustrates one embodiment of a system for adaptively applying authentication policies;

FIG24 illustrates one embodiment of a method for adaptively applying authentication policies; and

FIG25 illustrates an exemplary client equipped with a biometric device;

FIG26 illustrates one embodiment of a verification engine including an eye tracking module and a facial recognition module;

FIG27 illustrates an exemplary heat map of a web page employed in one embodiment of the present invention;

28A-28B illustrate exemplary text, graphics, photos, videos, white space, and other content that may be displayed to an end user;

FIG29 illustrates one embodiment of a method for performing authentication based on eye tracking and facial recognition;

FIG30 illustrates different architectural arrangements in which embodiments of the invention may be implemented.

FIG31 illustrates one embodiment of a client-side architecture including a client-side risk assessment agent;

FIG32 illustrates exemplary types of client configuration data used by the client risk assessment agent;

FIG33 illustrates one embodiment of a method for performing client risk assessment during authentication;

FIG34 illustrates one embodiment of a client performing a secure transaction with a local device;

FIG35 illustrates one embodiment of a client architecture for performing secure transactions with a local device;

FIG36 illustrates one embodiment of a method for performing a secure transaction with a local device;

FIG37 illustrates one embodiment of a system for user confirmation of online transactions;

FIG38 shows details of one embodiment of a client used in a system for user confirmation of online transactions;

FIG39 illustrates one embodiment of a method for user confirmation of online transactions;

FIG40 illustrates one embodiment of a system for delegating trust from a trusted client device to a new client device;

FIG41 illustrates additional details of one embodiment of a system for delegating trust from a trusted client device to a new client device;

FIG42 illustrates one embodiment of a method for delegating trust from a trusted client device to a new client device;

FIG43 illustrates one embodiment of a system for synchronizing private data between devices;

FIG44 illustrates one embodiment of a method for adding a device to a circle of trust;

FIG45 illustrates one embodiment of a method for synchronizing data between devices;

46A-46B illustrate different exemplary architectural arrangements in which embodiments of the invention may be implemented.

47 is a transaction diagram illustrating how an authentication device on a client device may be discovered.

Figure 48 is a transaction diagram showing how a user may register with an authentication device.

Figure 49 is a transaction diagram showing how keys can be registered into an authentication device.

Figure 50 is a transaction diagram showing how user authentication can be implemented within the authentication framework.

Figure 51 is a transaction diagram showing how transaction details can be verified.

Figure 52 shows a query policy filter implemented according to one embodiment of the present invention.

Figure 53 is a transaction diagram showing how the registration operation of the query strategy is implemented in one embodiment of the present invention.

Figure 54 illustrates one embodiment of an architecture for implementing multiple authentication device processing.

Figures 55A to 55C illustrate three embodiments of the present invention for multi-authentication device processing.

56A-56B illustrate transaction diagrams for detecting and responding to a random challenge timeout.

Figure 57 shows an architecture for implementing privacy classes according to one embodiment of the present invention.

Figure 58 is a transaction diagram for implementing privacy categories according to one embodiment of the present invention.

Figure 59 illustrates one embodiment of an architecture for verifying transactions using signatures.

60-61 illustrate exemplary embodiments of a computer system for implementing embodiments of the present invention.

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 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.

As used herein, the term "local" refers to the fact that a user is conducting a transaction in person at a specific location, such as at an automated teller machine (ATM) or a point-of-sale (POS) retail checkout. However, as discussed below, the authentication techniques used to authenticate a user 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 (such as ATMs and retail points of sale) are described herein, it should be noted that the underlying principles of the present invention may be implemented in the context of any system in which a transaction is initiated locally 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 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.

A. Non-Intrusive Privacy-Preserving Verification

One embodiment of the present invention trains the authentication system to recognize non-intrusive authentication scenarios using "normal" authentication techniques (e.g., swiping a finger, entering a code, etc.) Additionally, one embodiment returns the authentication status of the device to the relying party when authentication is required, rather than sensitive information such as a machine ID.

Some embodiments of the present invention described below may work completely frictionlessly (i.e., without requiring any explicit user authentication). Behavioral or other techniques may be utilized to continuously measure an assurance level that indicates the current assurance that the device is in the possession of an authorized user. The assurance level may be calculated, for example, based on the time that has elapsed since the last explicit user authentication (e.g., SIM card or phone unlock using a PIN or finger swipe). Assuming the amount of time that has elapsed is within a certain threshold (e.g., 5 seconds, 5 minutes, 1 hour, etc.), the device may be considered to be in a "legitimate user state" and the assurance level may be set to a maximum value (e.g., 100 on a standardized scale of -100 to 100).

After the legitimate user state, the assurance level can be measured based on a combination of the time that has passed since explicit user authentication and other variables that indicate that the device is in the possession of an authorized user (e.g., based on non-intrusive input detected from the device's sensors). For example, the user's biometric gait can be measured using an accelerometer or other type of sensor and software and/or hardware designed to generate a gait "fingerprint" from the user's normal walking pattern. In addition, the distance to the legitimate user's frequented destinations can be tracked, stored, and subsequently used to determine the assurance level. For example, if the user is connecting to the relying party from a location known to be the user's home or office, the assurance level can be set to a relatively high value, while if the device is connecting from an unknown or remote location, the assurance level can be adjusted to a lower level.

Various other types of non-intrusive measurements can be performed to determine whether a device is in the possession of an authorized user, including, for example, the identity of the network or device to which the client device is connected, such as a Bluetooth device, a near-field communication (NFC) device, a Wi-Fi device (such as a router or access point), a smartwatch, other computing devices, a Nymi wristband, and the like. Wi-Fi devices can include visibility of accessible Wi-Fi networks, such as a personal Wi-Fi router in a home, and Wi-Fi-enabled computers used by coworkers or family members. Additionally, certain specific characteristics of the client device, such as accelerometer characteristics and digital camera sensor pattern noise, can be utilized for non-intrusive measurements. Touchscreen gestures during normal user interaction can also be analyzed and stored as reference data, and user typing behavior during normal user interaction can be analyzed and stored as reference data. Of course, the foregoing are merely a few examples; the underlying principles of the present invention are not limited to any set of non-intrusive variables.

The end result is that a level of assurance that the legitimate user still possesses the device can be sent to the relying party in the verification response. In one embodiment, the assurance level is "signed" or otherwise verified by a key (e.g., a relying party-specific key established and certified during the registration phase, as discussed below). In one embodiment, the assurance level is normalized to a value between -100 and 100, where -100 means "almost certain it is not the legitimate user," 0 means "don't know," and 100 means "almost certain it is the legitimate user."

In one embodiment, if the assurance level is unacceptable for the intended transaction, the relying party may require the client device to respond using an additional "normal" authenticator. Regardless of the level of authentication required, one embodiment does not disclose personal data to the relying party, but rather uses a cryptographic key specific to a particular relying party to authenticate the authenticator to the relying party.

FIG2 shows one embodiment of an architecture for providing non-intrusive privacy-preserving authentication, which includes a non-intrusive privacy-preserving authenticator (NIPPA) 210, and the non-intrusive privacy-preserving authenticator (NIPPA) 210 includes an assurance calculator 212 for determining a current assurance level based on input from a non-intrusive authentication mechanism 230 (e.g., location, gait measurement, etc.) and one or more explicit user authentication devices 220 to 221 (e.g., fingerprint sensor, input device for entering ID code, etc.). In one embodiment, the explicit user authentication devices 220 to 221 include the same or similar architecture as shown in FIG1.

In the embodiment shown in FIG2 , non-intrusive authentication 230 includes a location authentication module 231 for performing location-based authentication using a location sensor 241 and historical or user-specified location data stored in a user/location data storage device 245 (e.g., which may be implemented as a file system or database). By way of example and not limitation, location sensor 241 may include a GPS device and/or a module for detecting the current access point or cell tower to which client 200 is connected (which may be used to estimate the device's current location). Any sensor capable of providing data related to the user's location may be used. Location authentication module 231 determines the impact of the client device's current location on the assurance level. For example, if the device is currently located at "home" or "office" (based on historical or user-specified location data 245), the assurance level may be adjusted upward, while if the device is currently located at a remote, unknown location, the assurance level may be adjusted downward. In addition to automatically training the system during a "legitimate user state" (as described herein), in one embodiment, users have the ability to manually designate certain locations as "trusted" and therefore having a high assurance level (e.g., when the user is at home or at the office). The result of the location verification module 231 is provided to the assurance level calculation module 212 , where the result of the location verification module 231 may be incorporated into the current assurance level calculation.

The user behavior verification module 232 relies on one or more user behavior sensors 242 to determine the degree to which the current user behavior is consistent with historical user behavior (stored in the user and location data storage device 245). For example, the user behavior sensor 242 may provide accelerometer measurements, which the user behavior verification module may use to determine the gait of the user currently holding the device 200. The user behavior verification module may then compare these measurements with the user's known gait (collected after a previous explicit user verification and stored in the storage device 245) to derive a confidence level that the device is held by a legitimate user. The result is provided to the assurance calculation module 212, where it is then factored into the current assurance level calculation.

Various other/additional verification devices 233 may collect data from other/additional sensors 243 to perform verification calculations, the results of which are provided to the assurance calculation module 212 to be factored into the current assurance level calculation.

2 as separate modules, the location verification module 231, the user behavior module 232, and any other verification modules 233 may form part of the assurance calculation module 212. The basic principles of the invention may be implemented using various different logical arrangements of modules.

As shown, in one embodiment, the assurance calculation module 212 relies on the timer 211 when measuring the amount of time that has passed since the last explicit user authentication. As discussed in detail below, the amount of time that has passed since the last explicit user authentication can be used to determine whether the device is currently in a "legitimate user state" and adjust the assurance measurement value accordingly.

Once the assurance calculation module 212 has determined the current assurance measurement, it can transmit the measurement to a relying party (in one embodiment, a cloud service) established via the secure communication module 213. For example, each verifier 220 to 221 (including the non-intrusive verifier 230) can exchange a relying party-specific and certified key in a registration operation (before verification). The assurance level returned in the verification operation can be part of a message signed/encrypted with the relying party-specific verification key. In addition, as discussed below, the message can also include a random number generated by the relying party (e.g., a random challenge).

In one embodiment, secure storage 225 is a secure storage provided for storing authentication keys associated with each authenticator and used by secure communication module 213 to establish secure communications with relying parties.

As mentioned, in one embodiment, NIPPA 210 utilizes existing (explicit) user authentication techniques (e.g., password-based system login, SIM card unlocking, etc.) to maintain the "legitimate user" status within a defined time window (up to T1 seconds) after each such successful authentication. NIPPA 210 can periodically measure user behavior from various sensors 241 to 243, and when in the "legitimate user" state, NIPPA 210 can update its internal reference data vector based on the measurements. When not in the "legitimate user" state, NIPPA 210 can calculate a normalized "distance" from the reference data vector based on the current measurements. This "distance" is considered to be the certainty that the legitimate user still holds the authenticator.

When asked to authenticate a user, NIPPA 210 may check to determine if the user is in the "valid user" state. If so, authentication is deemed successful and the maximum assurance level (e.g., 100) is returned. If the user is not in the "valid user" state, NIPPA 210 may return the assurance level calculated by assurance calculation module 212 based on the latest measurement. NIPPA 210 may then combine the assurance level with the time difference td (td=tc-tm) between the corresponding measurement tm and the current time tc. In one embodiment, this process is accomplished using the following logic:

(1) If (Guarantee Level>=0), then Resulting Guarantee Level=Guarantee Level*(Maximum (T0-td,0)/T0), where T0 is the maximum acceptable time difference; and

(2) If (guarantee level < 0), then the obtained guarantee level = guarantee level.

FIG3 illustrates the operation of one embodiment of the present invention according to the above formula. At time t1, the user performs explicit authentication (e.g., swiping a finger, entering a PIN to unlock a SIM card, etc.). The time window up to t1+T1 is considered the "valid user" state. As mentioned, the non-intrusive authenticator can be trained within the valid user state. For example, the user's gait can be measured, and/or the locations visited by the user can be recorded and subsequently used to perform non-intrusive authentication.

At time t2 (not in the authorized user state), the assurance calculation module 212 calculates the assurance level based on the non-intrusive verifier. The result is a positive value, which means that the device is likely under the full control of the authorized user. After this calculation, the assurance level decreases over time (for example, the authorized user may expose the device to unauthorized persons). For example, at time t3, the assurance level has become significantly lower than the value at time t2. In one embodiment, the non-intrusive assurance level is only calculated periodically to avoid consuming excessive power and CPU performance.

At t5, another non-intrusive assurance level calculation occurs. This time, the result is negative, indicating that the device is likely not under the full control of the legitimate user. This negative assurance level does not change until another calculation is performed based on the non-intrusive authenticator (e.g., at time t6).

A method according to one embodiment is shown in Figures 4 to 5. The method may be implemented within a system architecture such as the system architecture shown in Figure 2, but is not limited to any particular system architecture.

At 401, an explicit authentication event occurs, such as swiping a finger on a fingerprint sensor or entering a PIN to unlock the device. A timer may also be started to measure the time that has elapsed since the explicit authentication event. At 402, a valid user state is entered; at 403, various aspects of the user's behavior may be measured and stored for later reference (e.g., location, user gait, etc.). If, at 404, it is determined that an authentication request occurred during the valid user state (e.g., resulting from a transaction with a relying party), a maximum assurance level is selected at 405 and sent to the relying party at 420.

At 406, the system exits the legitimate user state (e.g., because a timer indicates that a specified amount of time has elapsed). At 407, the system periodically measures user behavior by comparing data from the sensors with the internal reference data stored in operation 403. For example, measurements associated with the user's gait (collected while in the legitimate user state) can be compared with current gait measurements (collected at 407), and a correlation between the two (referred to as the "distance" from the reference data) can be calculated. If, at 408, it is determined that a verification request was received while not in the legitimate user state, then, at 409, a current assurance level is calculated based on the distance from the internal reference data and possibly the time since the explicit verification event. The assurance level is then transmitted to the relying party at 420.

5 , if it is determined at 501 that the assurance level transmitted to the relying party is acceptable for the current transaction with the user, the relying party may send a response to the client device indicating successful authentication. If not, at 503, the relying party may send a response to the client device indicating that additional authentication is required (e.g., if non-intrusive authentication is insufficient, explicit user authentication may be required).

In an alternative embodiment, a relying party may initially specify the assurance level required for a particular transaction, and the system will ensure that the required assurance level is met, possibly using explicit user authentication if non-intrusive authentication techniques are insufficient. The system may then send an indication of successful authentication (rather than an assurance level) to the relying party.

As described above, one embodiment of the present invention calculates distance from a set of known user locations to determine the assurance level. Referring to Figure 6, a "distance" function may be calculated as follows using location based measurements (such as GPS, for example).

In a pre-processing operation, all measured locations (Ln) are assigned to their nearest "zone." A zone is defined as a circle with a radius r (e.g., 10 meters). These zones are set so that all Ln are covered by a minimum number of zones. All zones that cover fewer than M locations are removed from the zone set (i.e., because these locations are not considered "frequent" locations for the user).

Next, the distance (d) is determined using "Distance = (distance from current position (Lc) to the nearest center of region (Rn)) / r," where r is the radius of the region. If Lc is within the existing region, this value is less than or equal to 1; if Lc is outside, this value can be much larger. The guarantee level is then calculated using the following formula: Guarantee Level = Maximum (100 - 50 * floor (d), -100); the guarantee level value is in the range of -100 to 100.

In some of the above embodiments, it is assumed that the legitimate user still possesses the client device within a specific time window after explicit authentication, or that the current behavior is very similar to the measured behavior. However, the above embodiments only update the behavior reference data within a specific time window after explicit authentication.

As shown in FIG7 , one embodiment of the present invention uses an extended time window in addition to the standard time window of legitimate user status to update the behavioral reference data (i.e., train the system). Thus, the entire time window (including the standard time window and the extended time window) can be defined as follows: (1) if within the legitimate user status time window (i.e., t1...t1+T1) after successful explicit user authentication, or (2) if the returned assurance level will be above a certain threshold T (e.g., T=90, at, for example, t2, t4, etc.). Setting the threshold to 0 is undesirable because it would make it easy for an attacker to "turn" the behavioral reference in his favor.

B. Adaptive Verification Technology

FIG8 illustrates one embodiment of the present invention for implementing adaptive authentication techniques. As in the embodiments discussed above, this embodiment includes one or more non-intrusive authentication modules 230 for performing non-intrusive authentication (e.g., based on location, sensed user behavior, etc.), and one or more explicit authentication modules 222 for performing explicit user authentication (e.g., requiring a PIN, fingerprint scan, etc.). Additionally, as in the previous embodiments, an assurance calculation module 212 calculates assurance based on, for example, the time since the last explicit authentication (provided by a timer 211) and/or authentication data provided by the various authentication modules 230, 222. A secure communication module 213 establishes secure communication with a relying party 250 (e.g., using a secure encryption key, as discussed above).

In one embodiment, adaptive authentication module 800 dynamically selects among available non-intrusive authentication techniques and explicit/intrusive authentication techniques to derive a sufficient level of assurance for the current transaction with relying party 250. Alternatively, or in addition, adaptive authentication module 810 on relying party 250 may perform authentication selection techniques to derive a sufficient level of assurance. Regardless of whether the authentication selection techniques are implemented on client device 200 (via adaptive authentication module 800) or on relying party 250 (via adaptive authentication module 810), the underlying principles of the present invention remain the same.

In addition, the "relying party" 250 shown in Figure 8 can represent a trusted third-party server that can implement the verification techniques described herein on behalf of the relying party and provide the results to the relying party. Therefore, although the embodiments of the present invention are described in terms of a "relying party," the basic principles of the present invention can be implemented using servers outside the perimeter of the network operated by the relying party.

As discussed in more detail below, in one embodiment, the adaptive verification module 810 includes a risk engine 812 to determine a risk level based on variables associated with the client device (e.g., based on the current IP address, the round-trip delay of the IP packet, etc.). Additionally, an assurance level gain analysis component 811 can determine the amount by which the current assurance level must be increased to achieve an acceptable assurance level. Although these elements are shown in FIG8 as components of the adaptive verification module 810 of the relying party, these elements can also be implemented within the adaptive verification module 800 of the client while still complying with the underlying principles of the present invention.

In one embodiment, once client device 200 connects to relying party 250 (e.g., to initiate a transaction), risk engine 812 determines the risk (or assurance level) based on all currently available data. The available data may include, for example, the geographic location of client device 200 (e.g., derived from the IP address or provided by the mobile network operator), the round-trip latency of packets transmitted between client device 200 and relying party 250, the number of network hops sent between client device 200 and relying party 250, a specific "user-agent" string sent by the user agent executing on client device 200, and the like. In one embodiment, risk engine 812 then evaluates this data to derive an implicit "risk score" (or an initial assurance level that is inversely correlated to the risk score), which can be used to determine the amount of additional assurance required to authenticate the user for a given transaction.

In one embodiment, based on the implicit risk score, the adaptive authentication module on the relying party 810 or client device 800 determines a set of one or more authentication modules 222, 230 that are likely to increase the overall assurance level to the level required for the intended transaction (i.e., when combined with the initial assurance level/implicit risk score). In one embodiment, the assurance level gain analysis module 811 determines the required gain, and the adaptive authentication module 800, 810 obtains an indication of the required assurance level gain as a parameter. The adaptive authentication module 800, 810 then uses this "gain" parameter to determine a set of the most convenient authentication techniques (non-intrusive 230 and/or explicit 222) to achieve (at least) the required gain. The adaptive authentication module 800 may include a formal description of the selected authentication technique set in its response to the relying party 250 (e.g., as a verified extension). The relying party 250 may then verify whether the resulting overall assurance level meets the required level.

By way of example and not limitation, the adaptive authentication module 800 may combine multiple forms of authentication, such as device fingerprinting (e.g., identifying sensor defects or camera sensor pattern noise); environmental information (e.g., GPS-based location; location derived from a WIFI network; the presence of a wired or wireless connection to other gadgets (such as Nymi), smart watches (pebbles), or peripherals (such as headphones); behavioral data (e.g., how the user removes the device from a pocket, typing behavior, gait, etc.); time since the device was in a "trusted" state; and the results of possible new explicit authentication using one or more forms of authentication (biometric or otherwise) required to achieve the desired (remaining) gain in assurance level.

The result of the above techniques is that the user can select the most convenient authentication method. If the device is a smart phone, this may simply be obtaining access to the phone (see above). Instead of requiring the user to select an authentication method and subsequently requiring the user to perform another explicit authentication, the relying party 250 may send an indication of the required assurance level gain to the adaptive authenticator 800, 810, which identifies a set of minimally invasive authentication techniques. The adaptive authentication module 800, 810 does not always require explicit (invasive) user authentication (such as entering a PIN or swiping a finger), nor is it based solely on non-invasive forms. Instead, such an authenticator selects the appropriate combination of all available forms (on the client side) to achieve the required assurance level gain.

As discussed in detail above, the time since the device was in a trusted state is very important because forms of intrusion/spoofing can take time. For example, if a user's phone is lost and someone attempts to hack into the phone, it may take a day to capture a fingerprint from the display, create a suitable rubber finger ring, and then use it to gain access. Therefore, requiring a PIN to be entered after 24 hours or less has passed since the last time it was in a trusted state will be sufficient to protect against this type of attack. The next level of attack is an attack that captures the fingerprint before gaining access. These attacks are less commonly seen in practice. However, if the relying party 250 needs to protect against such attacks, the adaptive authentication modules 800, 810 may need to consider location data or the presence of other gadgets or peripherals in order to accept biometric forms.

A method according to one embodiment of the present invention is shown in Figure 9. As discussed above, a "relying party" as used herein may be the actual party relied upon for accurate authentication of a user or may be a third party service authenticating a user on behalf of the relying party.

At 901, a client device connects to a relying party to perform a transaction (e.g., a transaction to log into an online account, a monetary transaction, etc.). At 902, the relying party analyzes any available data associated with the client device and determines a risk value and a desired assurance level gain required to authenticate the user. For example, such data may indicate that the user is connecting to the relying party from an unknown network location (e.g., a foreign country that the user has never been to before) and/or that the number of network routing hops or latency between the client and the relying party is above a threshold. In such cases, the risk value may be set to a relatively high value (or, conversely, the implicit assurance level may be lower). However, if the user has recently explicitly authenticated to the device (e.g., by entering a PIN), this may tend to lower the risk level (or increase the implicit assurance level).

The assurance level gain can be determined based on the assurance level required to complete the transaction. For example, it can be calculated using a formula such as: Implicit Assurance Level + Assurance Level Gain = Required Assurance Level, or Assurance Level Gain = Required Assurance Level - Implicit Assurance Level. Various other formulas can be used to determine the assurance level gain while still complying with the underlying principles of the present invention.

At 903, an indication of a desired assurance level gain is received. If, at 904, it is determined that non-intrusive authentication techniques are sufficient to achieve the assurance level gain, then at 905, the user is authenticated using these techniques. If not, at 907, one or more explicit authentication forms are implemented, possibly in conjunction with one or more non-intrusive authentication forms. As mentioned, the form that is least onerous for the end user may be selected (e.g., based on user-specified preferences).

FIG10 graphically illustrates how the embodiment of the present invention described above can evaluate assurance levels to determine a form of authentication. At time t1, the user performs explicit authentication (e.g., swiping a finger, entering a PIN, etc.). At time t2, the relying party requests authentication with an assurance level gain of al4. The non-intrusive form of authentication achieves an assurance level al1 that is higher than al4, so no explicit authentication needs to be triggered.

Conversely, at time t4, the relying party requires verification with an assurance level gain of al4. The non-intrusive verification form will only achieve al5 at that time (as shown in the figure). Therefore, in this case, the adaptive verifier module will select at least one explicit verification form to increase the assurance level from al5 to al4.

One embodiment of the present invention employs implicit location-based authentication techniques in a manner that protects the privacy of the end user. As mentioned above, sharing a user's current location (e.g., provided by GPS) with a relying party can create serious privacy issues. Consequently, users are often reluctant to share such data.

To address these issues, one embodiment of the present invention uses geographic location as a factor when performing implicit user authentication, but does not disclose the user's location to the relying party. This embodiment can be implemented alone or in combination with the other non-intrusive authentication techniques 230 and/or explicit authentication techniques 222 described above (e.g., as part of a larger, comprehensive authentication process). Rather than transmitting the actual location from the client device, the user's privacy can be protected by transmitting only a level of assurance based (at least in part) on the data's geographic location.

One embodiment uses the following operations to enroll and register a user/device with a relying party:

1. The user selects and specifies one or more locations where they typically authenticate to the website. These locations can be within a predetermined number of miles or within a specific location (e.g., office, home, transportation routes, etc.). The selected locations can be stored locally on the client device and not transmitted to the relying party. These operations can be performed by the location verification module 231 described above.

2. In one embodiment, after enrollment is complete, the client device shares a key with the relying party via a secure communication channel (eg, using secure communication module 213 and other enrollment techniques described herein).

In one embodiment, during verification the following operations are performed:

1. The client device determines its current location using one or more geolocation techniques (e.g., using a location sensor 241 such as an embedded GPS chip to retrieve the current location).

2. The location verification module 231 on the client compares the current location with the already registered locations and generates a score indicating the distance (e.g., from 0 to 100). The assurance calculation module 212 can then incorporate the score into the assurance calculation (as described above).

3. The client device generates a signature, signs the score/assurance level, and sends it to the relying party 250 for final verification.

C. Composite Validator

Some embodiments of the invention described herein employ client-side "authenticators" that incorporate the following security-related functionality:

1. Store and use cryptographic verification keys

2. Generate, store, and use password-verified keys

3. Local user authentication or verification of user existence

4. Safely display information to end users

In one embodiment, some of the above functions (e.g., 3 and 4) are optional. In addition, one embodiment of the present invention includes a validator that implements the following security goals:

1. Ensure that attestation keys: (a) are only used to attest to attestation keys generated and protected by the FIDO Authenticator; and (b) never leave the FIDO Authenticator boundary.

2. If support for local user authentication (sometimes also called "user verification") is required, ensure that: (a) authentication cannot be bypassed/forged by software applications (e.g., malware that "enters" a PIN into the authenticator); (b) the confidentiality of the authentication data is protected (e.g., malware cannot access either the user-entered PIN or the reference data); and (c) user authentication is required before generating new authentication keys and before using such authentication keys.

One way to implement the authenticator is to implement all components responsible for the above functionality in a single module protected by a single protective shell. For example, the entire authenticator can be implemented in a trusted application (TA) running in a trusted execution environment (TEE) (e.g., on a client platform that supports trusted execution). In this specific implementation, the TA is signed, ensuring that the authenticator cannot be modified and that the TEE protects the TA during execution.

In one embodiment of the present invention, each authenticator is logically subdivided into multiple independent components, each of which includes independent security and authentication capabilities. For example, in Figure 11, rather than implementing all of the components responsible for the above functions in a single module protected by a single shell, the authenticator 1100 is implemented using two separate independent authenticator components: the user verification component (UVC) 1101 and the authenticator kernel (AK) 1103, each of which has its own protection logic 1110 and 1112, respectively. In this example, the AK 1103 securely manages the confirmation key 1104 and the verification key 1105 for the authenticator 1100, and the UVC 1101 manages the user authentication/presence function 1106 and the secure display function 1107 (specific examples of which are described below and in the co-pending applications).

As discussed in detail below, the protection logic 1110, 1112 of each component may include a component verification engine for verifying each component to one or more other components executing on the client device (e.g., see FIG. 13 and associated text). In addition, the protection logic may utilize additional hardware/software protection mechanisms built into the client platform (e.g., such as secure elements (SEs), trust chain technology, trusted user interface technology, OS-based protection mechanisms, etc.). Details associated with each of these embodiments are set forth below.

FIG12 illustrates an embodiment of the present invention, in which a plurality of logical validators 1201 and 1202 are constructed from a set of protected validator components. Specifically, the component building blocks for logical validator 1201 include a user verification component (UVC) 1210 for managing user verification and presence; a display component (DC) 1212 for ensuring that the information displayed to the end user is exactly what is confirmed by the transaction (i.e., "What You See Is What You Sign" or WYSIWYS); and an authenticator kernel (AK) component 1214 for securely managing attestation keys 1215 (used to verify the model and/or integrity of the validator to relying parties as part of the registration process) and verification keys 1216 (used to establish secure communications with relying parties using unique verification keys for each relying party). The component building blocks for logical validator 1202 include a UVC 1220 for managing user verification and presence, and an authenticator kernel (AK) component 1214 for securely managing attestation keys 1215 and verification keys 1216. Thus, in this example, multiple logical validators share the same base AK component 1214 for managing and protecting keys. In other embodiments of the present invention, other types of components may be shared between multiple validators. As discussed above, each component has its own independent protection logic to ensure that the security goals stated above are met.

An authenticator built from multiple components in this way is called a "composite authenticator" because it consists of separate, independent components, each with its own protective shell. One benefit of the composite authenticator approach is that once a component is built for one authenticator, it can be used across multiple authenticators, making it possible to build new secure authenticators more efficiently. For example, as shown in Figure 12, the same authenticator kernel component 1214 is shared between two logical authenticators 1201 and 1202. In addition, each authenticator component can be implemented in a manner optimized for its specific needs. By way of example and not limitation, an authenticator based on facial recognition (whose biometric segmentation and matching algorithm may be too large to be implemented within a secure element (SE) or trusted execution environment (TEE)) can still utilize the SE/TEE to protect its confirmation key and user authentication key. In this example, the user authentication component (e.g., including the segmentation and matching algorithm) can run outside the SE/TEE, while the authentication kernel component can be implemented within the SE/TEE. Similarly, a fingerprint-based authenticator implemented in a TEE can still utilize the SE authentication kernel to protect its attestation keys and user authentication keys and thus resist hardware-based attacks (e.g., such as differential power analysis (DPA)).

In one embodiment, the following security measures are implemented to provide an acceptable level of security for the component verifier described herein (e.g., "acceptable" for meeting the security goals specified above). These security measures will be described with reference to FIG13 , which shows additional details associated with the various components 1210, 1212, 1214 used to implement the verifier 1201 in FIG12 .

1. Security Measures (SM) 1 : In one embodiment, each component (e.g., user authentication component 1210, display component 1212, or authentication kernel 1214 shown in Figures 12-13) has its own "component authentication key" pair (CAK) (e.g., CAK pairs 1304, 1305, and 1306, respectively) used to register with other components (possibly mutually) and authenticate messages sent to them. As indicated in Figure 13, each component 1210, 1212, and 1214 includes component authentication logic 1301, 1302, and 1303, respectively, for entering into inter-component authentication transactions using CAK pairs 1304, 1305, and 1306, respectively. In one embodiment, CAK pairs 1304, 1305, and 1306 are public/private key pairs, but the underlying principles of the invention are not limited to this specific implementation. In this implementation, each component is provided with the public keys of the components with which it needs to authenticate. For example, UVC 1210 knows the public keys of DC and AK (or at least can verify the public keys) 1321; DC 1212 knows the public keys of UVC and AK 1321; AK 1214 knows the public keys of DC and UVC. In one embodiment, at startup, a component initially enters into a registration transaction with other components it must communicate with by sharing their public keys. The component can then authenticate itself to those components using the techniques described below.

2. Security Measure (SM) 2 : Each component can authenticate other components from which it receives messages by verifying their public CAKs. For example, in Figure 13, AK 1214 can verify the public CAKs of all UVCs 1210 and DCs 1212 it supports (i.e., the public keys in CAK pairs 1304 and 1305). If mutual authentication is implemented, the UVCs and DCs can also verify the public CAK of AK 1214 (i.e., in CAK pair 1306).

Figure 14 is a transaction diagram illustrating how authentication between two components (AK 1214 and DC 1212) can be implemented. At transaction 1400, the AK's component authentication logic 1303 generates a challenge and sends it to the DC's component authentication logic 1302 in transaction 1401. In one embodiment, the challenge is a random number or nonce selected by the component authentication logic 1303. In operation 1402, the DC's component authentication logic 1302 generates a signature for the challenge using the private key from its CAK pair 1305 and may also generate additional data (e.g., whether the user has approved the contents of the transaction). As will be understood by those skilled in the art, generating the signature may involve applying a hash function to the challenge using the private key. At transaction 1403, the DC's component authentication logic 1302 sends the signature back to the AK's component authentication logic 1303 for verification. The AK's component authentication logic 1303 now knows the challenge (e.g., the nonce it previously generated), the signature generated using the DC's CAK pair's private key, and the DC's CAK pair's public key. In transaction 1404, AK's component verification logic 1303 uses the public key of DC's CAK pair to verify the signature using the random number, thereby verifying DC. If mutual authentication is implemented, DC can also use a set of public keys similar to transaction verification AK1214.

3. Security Measures (SM) 3 : Depending on the specific implementation, additional security mechanisms may be utilized to protect communications between components. These additional security mechanisms are illustrated in FIG13 as supplementary hardware/software protection mechanisms 1310. By way of example and not limitation, these hardware/software protection mechanisms 1310 may include those built into the client platform, such as secure elements (SEs), chain-of-trust technology, trusted user interface technology, OS-level access control mechanisms, white-box encryption, code obfuscation, and runtime integrity protection, among others. By utilizing, for example, TrustZone ^™ or similar technology, the operating system can restrict access to the AK's application programming interface (API) to only trusted programs (e.g., such as legitimate UVC and DC). As another example, the operating system can also add a UVC or DC packet identifier to any API call to the AK. However, it should be noted that the underlying principles of the present invention are not limited to the specific hardware/software protection mechanisms discussed above.

For example, in one embodiment, AK 1214 is implemented as a small program in a secure element that provides a good protection mechanism for cryptographic keys but has no user interface. UVC 1210 can be implemented as a combination of hardware (e.g., a fingerprint sensor) and a trusted application within a trusted execution environment, both leveraging ARM TrustZone or similar technology. DC 1212 can be implemented as a trusted application using the "Trusted User Interface" capability as defined by the global platform. Thus, in this embodiment, when a user swipes their finger across the fingerprint sensor, the trusted application launches and verifies the fingerprint data against stored reference data. The trusted application then sends the score to AK 1214, implemented as a secure element, which then enters a series of authentication transactions with relying party 1320 to authenticate the user (e.g., as described in the co-pending application).

Additionally, a different UVC can be implemented as a software component running in a rich OS (e.g., Android) using a combination of white-box encryption, code obfuscation, and runtime integrity protection. This UVC can, for example, use an integrated camera and facial recognition software. Another UVC can be implemented as a trusted application or software running on a rich OS using a combination of white-box encryption, code obfuscation, and runtime integrity protection and providing a PIN-based user authentication method.

Therefore, the component-based approach described herein can easily adapt to the requirements of different authentication technologies. For example, some types of authentication (such as voice recognition and facial recognition) need to be implemented as software components using common rich operating systems due to their large storage requirements and hardware interface requirements. All of these different types of authentication can be implemented in a secure and trusted manner using different UVC components using the same AK component (which can be implemented as a secure element as discussed).

It should be noted that, using the above method, the various components logically communicate using cryptographically protected (e.g., signed) messages. This logical communication may still be "facilitated" by some other entity (e.g., such as the secure transaction logic discussed below). Furthermore, in one embodiment, the inter-logical component messaging described herein is transparent to the relying party 1320, which directly engages in authentication and verification transactions with the authenticator kernel 1214 (e.g., using authentication key 1215 and verification key 1216, respectively). In one embodiment, the AK uses authentication key 1215 to verify the authenticator's model and/or integrity during registration. For example, a relying party may send a challenge signed by the AK using authentication key 1215. The relying party then verifies the signature using the corresponding key (e.g., using the public key if the authentication key is private). Once the authenticator has registered with a relying party, a verification key 1216 is assigned to that relying party. The AK then uses the verification key 1216 associated with the relying party to ensure secure communication with that relying party after registration.

As an additional security measure, in one embodiment, the component verification logic 1301 - 1303 of each component may delete its CAK pair if a component compromise is detected.

Two different types of composite verifiers can be implemented using the underlying principles of the invention: a "static" composite verifier and a "dynamic" composite verifier.

Static Composite Validator

15 , in one embodiment, a composite validator 1501 having the following characteristics is referred to herein as a “static” composite validator:

1. For each authenticator 1501, the relying party 1320 has/needs access to a public certification key (corresponding to the certification key pair 215, not the public "Component Authentication Key" (CAK) 1304, 1306); and

2. For each supported component combination (eg, UVC, DC, and AK), a specific authenticator attestation ID (AAID) 1505 has been pre-assigned.

15, for a static composite authenticator, each distinct authenticator 1501 is identified by its specific AAID 1505. The AK possesses one or more attestation keys 215 and also selects a predefined AAID (and associated attestation key) to use when performing transactions with a relying party 1320.

Because CAK pairs are never shared with relying parties 1320, CAK pairs can be specific to the authenticator without affecting the privacy of the user. This also means that such keys can be revoked individually in the event of a successful intrusion into an independent component being detected. Because the CAK is not used as a (publicly visible) "verification key", an intrusion into a component is not considered equivalent to an intrusion into the authenticator. Additionally, because the communication and security mechanisms of the composite authenticator 1501 are not visible outside the authenticator, the specific implementation of the static composite authenticator does not affect the specifications defining the interaction between the authenticator 1501 and the relying party 1320. In one embodiment, each component 1510, 1514 is assigned a unique component ID which may be similar to an AAID, but which is only associated with the AK 1514 (and not with the RP or any other external entity).

As an additional optimization, in one embodiment, the Online Certificate Status Protocol (OCSP, RFC2560 ) can be used as a revocation verification method (e.g., "validation") for each CAK certificate. More specifically, the AK 1514 can require a sufficiently recent OCSP response for the UVC or DC certificate associated with the public CAK in order to accept an incoming message. The AK 1514 can also have a single confirmation key for all AAIDs, or the AK 1514 can optionally have a separate confirmation key for each AAID, or a combination thereof.

In one embodiment, the AK may maintain a static list of AAIDs. Alternatively, the AAID may accept AAIDs received from an external entity (e.g., UVC/DC) as part of a signed "AAID Update" message used to update the list. In one embodiment, the AAID Update message has the following structure: Signature(signing_key, AAID | AK component ID | UVC/DC's public CAK). The AK vendor may own a private signing_key. The public signing_key is either directly part of the AK's TrustStore (in a TrustStore implementation) or can be verified using a certificate stored in the TrustStore (i.e., linked to such a certificate).

The architecture of the user device 1500 shown in Figure 15 also includes a browser/application 1510 for establishing communication with the relying party 1320, and secure transaction logic 1520 for enabling communication with the authenticator. For example, as shown in the figure, in one embodiment, the secure transaction logic 1520 implements message passing between the components 1510 and 1514 of each authenticator 1501 by exposing an application programming interface (API) to various components. Therefore, in this embodiment, all communication between the components (such as the exchange of registration data and messages) occurs via the secure transaction logic 1520. For example, the secure transaction logic 1520 can be implemented as the "secure transaction service" described in the co-pending application (multiple sections of which are set forth below). The browser/application 1510 can be used to establish communication with the relying party 1320 via a network (such as the Internet).

Dynamic Composite Validator

Referring to FIG. 16 , a composite validator 1601 having the following characteristics is a “dynamic composite validator” if:

1. "Authentication Key" (CAK) 1604, 1604 is treated as a certification key, so that relying party 1320 has and needs the relevant public key to verify the certification message (e.g., called "Key Registration Data" in the OSTP specification); and component

2. Relying Party 1320 receives multiple AAIDs 1602, 1603 (depending on the number of components in Authenticator 1601). In one embodiment, Relying Party 1320 receives the AAIDs 1602, 1603 of all components 1610, 1614 of Authenticator 1601 as part of a registration message sent from AK 1614 via Secure Transaction Logic 1620 and Browser/Application 1610. Although FIG16 shows only UVC 1610 and AK 1614, alternative embodiments (such as that shown in FIG3) send the AAIDs of AK, DC, and UVC to RP 1320. However, as mentioned, the underlying principles of the present invention are not limited to any particular set of components for implementing an authenticator. In one embodiment, the registration message sent to RP 1320 also has multiple (linked) signatures, one of which has the AK's authentication key 1605, and one signature for each of the other components (e.g., the UCC's authentication key 1604 and the DC's authentication key (not shown)). As mentioned, in one embodiment, the AK 1614 includes the other component's confirmation message in its own confirmation message to the RP 1320 if and only if the communication with the other component is trusted.

Thus, a dynamically composed authenticator 1601 is implemented by dynamically combining multiple components (or, in other words, combining two authenticators to obtain a new authenticator). Because the CAK is associated with the RP in this implementation, in one embodiment, to protect the user's privacy, the CAK should not be specific to the authenticator. Instead, the CAK is either pre-generated/injected as a shared key or verified using a Direct Anonymous Authentication (DAA) scheme, which is a cryptographic protocol that enables authentication of a trusted platform while protecting the user's privacy. Because multiple AAIDs and chained authentication messages are visible to the RP, the specific implementation of the dynamic composite authenticator affects the authentication specification used between the authenticator 1601 and the relying party 1320.

UVC/DC Assertion Verification

Regardless of whether a dynamic or static authenticator is used, in one embodiment, UVC 210 and DC 212 send their output data, such as the user verification result (UVC) and the user's acceptance of the displayed transaction text (DC), to AK 214 so that it can be processed according to the authentication specifications adopted between AK 214 and relying party 1320.

For registration, in an embodiment with a static authenticator, UVC 210 and DC 212 may send a key registration message to AK 214 that includes a component ID (instead of an AAID), where a component ID is an identifier similar to an AAID but associated only with an AK. In one embodiment, the user authentication key of the key registration message is empty, and the key registration message is signed by a CAK instead of a certification key.

For authentication, in one embodiment, UVC 210 and DC 212 create a message signed by the CAK (not the User Authentication Key).

In one embodiment of the present invention, the following verification steps are performed by the AK:

1. Look up the internal truststore that contains a list of acceptable public CAKs. Public CAKs can either be stored directly in the TrustStore, or there can be a public key certificate for each CAK that chains to a root certificate in the TrustStore.

2. The AK verifies the signature of the incoming data from the UVC and/or DC using the public CAK (eg, as discussed above with respect to SM1 and SM2).

3. Verify additional platform-specific protection mechanisms, such as package IDs for incoming data, or use similar platform-provided protection mechanisms.

4. Verify the revocation status of the certificate containing the public CAK of the UVC or DC. Because the AK is only interested in revocation information for a very small number of certificates/keys (i.e., the current UVC or DC's certificate/key), revocation verification using the Online Certificate Status Protocol (OCSP) (mentioned above) can be used. Assuming the AK has no network connectivity, the OCSP response is expected as part of the incoming data from the UVC and/or DC.

Optimized verification method

A further optimization may be implemented in one embodiment where asymmetric key operations are prohibitively expensive compared to symmetric key operations. In this case, the key registration message created by the UVC and/or DC and sent to the AK contains the symmetric key SK (e.g., in place of an empty User Authentication Key field as described above). The modified key registration data message generated by the UVC and sent to the AK may be encrypted using the AK's public CAK (or some other trusted public key belonging to the target component). The modified signature message generated by the UVC and/or DC and sent to the AK is not asymmetrically signed using the CAK, but is instead protected using a hash-based message authentication code (HMAC) calculated using SK. The AK verifies the HMAC using the symmetric key received as part of the key registration data message.

D. Location-aware verification technology

One embodiment of the present invention implements an authentication policy that allows for the selection of an authentication mechanism based on the physical location of the client device being authenticated. For example, the client and/or server can determine the physical location of the client device and feed that location into a policy engine that evaluates a set of ordered policy rules. In one embodiment, these rules specify a location category and one or more authentication mechanisms that must be applied if the client location matches the location definition in the rule.

As shown in Figure 17, one embodiment of the present invention includes a client device 1700 having an authentication policy engine 1710, which is used to implement the location-aware authentication policy described herein. Specifically, this embodiment includes a location category determination module 1740 that uses the current location of the client device 1700 provided by a location sensor 1741 (e.g., a GPS device) to identify a current location "category". As discussed in detail below, different location "categories" can be defined, including known geographic points and/or areas. The location category data can be continuously updated and stored in a permanent location data storage device 1745 (e.g., a flash memory device or other permanent storage device). The location category determination module 1740 can then compare the current location provided by the sensor 1741 with the defined "categories" to determine the current location category of the client device 1700.

In one embodiment, the relying party 1750 specifies a verification policy for each transaction to be implemented by the verification policy engine 1710 (as indicated by the dotted line from the relying party to the verification policy engine). Thus, the verification policy can be uniquely customized for the verification requirements of each relying party. In addition, the required verification level (as defined by the verification policy) can be determined based on the current transaction. For example, a transaction requiring the transfer of a large amount of money may require a relatively high verification assurance threshold, while a non-monetary transaction may require a relatively low verification assurance threshold. Therefore, the location-aware verification technology described herein may be sufficient for some transactions, but for some transactions, it may be used in combination with more stringent verification technologies.

In one embodiment, the location category determination module 1740 provides the determined category to the verification policy module 1711, which implements a set of rules to identify the verification technique 1712 to be used for the determined category. By way of example and not limitation, FIG18 illustrates a set of exemplary rules 1 through 5 that specify one or more verification techniques 1 through 5 that may be used for each defined location category 1 through 5. Although illustrated as a tabular data structure in FIG18 , the underlying principles of the present invention are not limited to any particular type of data structure for implementing a rule set.

Once the authentication policy engine 1710 selects a set of authentication techniques 1712, the authentication policy engine 1710 may implement these techniques using one or more explicit user authentication means 1720-1721 and/or non-intrusive authentication techniques 1742-1743 to authenticate the user to the relying party 1750. By way of example and not limitation, explicit user authentication 1720-1721 may include requiring the user to enter a password such as a PIN, fingerprint verification, voice or facial recognition, and retinal scan, among others.

Non-intrusive authentication techniques 1742-1743 may include user behavior sensors 1742 that collect data related to user behavior for use in authenticating the user. For example, a user's biometric gait may be measured using an accelerometer or other type of sensor 1742 and software and/or hardware designed to generate a gait "fingerprint" of the user's normal walking pattern. As discussed below, other sensors 1743 may be used to collect data for authentication. For example, network data may be collected to identify network/computing devices (e.g., known peer computers, access points, cell phone towers, etc.) in the local vicinity of the client device 1700.

In one embodiment, secure storage 1725 is a secure storage for storing verification keys associated with each verification device 1720 to 1721. As discussed below, the verification keys may be used to establish a secure communication channel with relying party 1750 via secure communication module 1713.

Various different location "categories" may be defined consistent with the underlying principles of the present invention. By way of example and not limitation, the following location categories may be defined:

Category 1: The client is within a given radius of a specified location. In this category, if the current client location is within an area bounded by a circle with a given radius centered at the specified latitude and longitude, the associated authentication policy is applied.

Category 2: Client is located within a specified bounded area. In this category, if the client is located within an area bounded by a polygon (eg, a closed polygon) defined by a set of ordered latitude and longitude pairs, then the associated authentication policy is applied.

Category 3: Client is outside the specified boundary. In this category, if the client is outside the area bounded by a polygon (eg, a closed polygon) defined by an ordered set of latitude and longitude pairs, the associated authentication policy is applied.

In one embodiment, additional categories are defined using Boolean combinations of the categories and policy rules defined above. For example, the Boolean operations AND, OR, NOT, and nesting of Boolean operations allow for the expression of complex conditions. Such policies can be used, for example, to implement policies that apply when a client is located in one of a variety of facilities owned by a company.

The current physical location of the client (generally represented in FIG. 17 as location sensor 1741 ) may be determined using a variety of different mechanisms, including but not limited to the following:

GPS: Embedded GPS sensors can directly provide details of the client's location. New emerging standards attempt to increase location verification, aiming to provide capabilities that address shortcomings in current GPS solutions.

Geographic IP Lookup: A rough approximation of the client's location can be determined using a reverse lookup of the client's IP address. However, the reliability of the location obtained through this method requires cross-checking the IP address against a blacklist of known compromised hosts, anonymizing the proxy provider, or a similar scheme designed to obfuscate the host's source IP address.

Cell Tower Triangulation: Integration between the client, server, and wireless carrier infrastructure allows the client and server to determine physical location with high resolution using cellular signal strength triangulation.

Wi-Fi access point triangulation: A higher-resolution method for determining physical location is to triangulate the signal strength of nearby Wi-Fi access points with known physical locations. This method is particularly effective for determining the location of devices within a facility.

Position displacement inference: The exact location of the device may not be known, but the statistical probability of the location can be used as an approximation for the purpose of evaluating strategies. This can be calculated by recording the change in the device's position relative to a starting point with a known location; the user's device may have had a known starting point in the past and has moved a known or estimated distance and orientation during that time, allowing an approximate location to be calculated. Possible methods for calculating displacement from a starting point may include using measurements collected from accelerometers (i.e., using accelerometers to measure how far the user has walked based on gait measurements), changes in signal strength from a set of known fixed signal sources, and other methods to infer distance traveled.

One embodiment of a method for implementing a location-aware authentication strategy is shown in Figure 19. The method may be performed within the context of the system architectures shown in Figures 17-18, but is not limited to any particular system architecture.

At 1901, the client's location is identified using one or more available technologies (e.g., GPS, triangulation, peer/network device detection, etc.). At 1902, one or more location categories (and possible Boolean category combinations) are identified for the current location based on a set of existing policy rules. At 1903, one or more authentication techniques are identified based on the location category. For example, if the client device is currently located at a location known to be the user's home or office, or within a defined radius of another trusted location, minimal authentication (or no authentication) may be required. Conversely, if the client device is currently located at an unknown location and/or a location known to be untrustworthy, more stringent authentication (e.g., biometric authentication, such as a fingerprint scan, PIN entry, etc.) may be required. At 1904, an authentication technique is employed, and if authentication is determined to be successful at 1905, then transactions requiring authentication are authorized at 1906.

As described above, the required level of authentication can be determined based on the transaction at hand. For example, transactions involving the transfer of large amounts of money may require a relatively high authentication assurance threshold, while non-monetary transactions may require a relatively low authentication assurance threshold. Thus, the location-aware authentication techniques described herein may be sufficient for some transactions, but for other transactions, they may be combined with more stringent authentication techniques.

If the verification is unsuccessful, the transaction is blocked at 1907. At this stage, the transaction may be permanently blocked or additional verification steps may be requested. For example, if the user entered an incorrect PIN, the user may be asked to re-enter the PIN and/or perform biometric verification.

Embodiments of the present invention described herein provide many benefits to verification systems. For example, the embodiments can be used to effectively prevent access from unauthorized locations, thereby reducing unauthorized access by limiting the locations (e.g., defined by location categories) where users are allowed to attempt verification. In addition, embodiments of the present invention can selectively require that stronger verification be performed to respond to location-specific risks. For example, a relying party can minimize the inconvenience of verification when a user is entering a transaction from a known location, while still maintaining the ability to require stronger verification when the user/client is connecting from an unknown or unexpected location. In addition, embodiments of the present invention enable location-aware access to information. Alternatively, a relying party can use location-centric policies to provide users with additional access to location-specific information. By way of example and not limitation, when a user at Walmart logs into their Amazon.com account on their mobile phone, they can be granted access to special offers from Amazon.com.

As described above, the location of the client device 1700 can be determined using a variety of different techniques. In one particular embodiment, the definition of "location" may not be associated with a set of physical coordinates (such as when using GPS), but rather may be defined by the presence of a set of peer devices or other types of network devices. For example, when working, the client's wireless network adapter (e.g., Wi-Fi adapter, Bluetooth adapter, LTE adapter, etc.) can always "see" a set of peer network devices (e.g., other computers, mobile phones, tablet computers, etc.) and network infrastructure devices (e.g., Wi-Fi access points, cell phone towers, etc.). Therefore, the presence of these devices can be used to verify that the user is at work. Other locations can be defined by the presence of devices in a similar manner, such as when the user is at home.

For example, using the techniques described herein, a location can be defined as "with my colleagues" or "at work," where the presence of a set of peer devices known to be owned by the user's colleagues can be used as a proxy for risk that needs to be mitigated by the authentication policy. For example, if a user is surrounded by a set of known peer devices or other types of network devices, the user can be considered to be less risky than if no known devices were detected.

FIG20 illustrates an embodiment in which a "location" is defined by a set of peer devices and other network devices. In the example shown, client device 1700 "sees" two different peer devices 2005 and 2006 (e.g., client computers, mobile phones, tablet computers, etc.); two different wireless access points 2010 and 2011; and two different cell phone towers 2020 and 2021. As used herein, client device 1700 can "see" without formally establishing a connection with each other device. For example, a client may see various peer devices connected to a work LAN and/or may see the wireless signals generated by those devices, regardless of whether the client is connected to those devices. Similarly, client device 1700 may see the Basic Service Set Identifiers (BSSIDs) of various different Wi-Fi access points (e.g., Wi-Fi from a nearby hotel, coffee shop, or work Wi-Fi access point). Client device 1700 may also see various different cell phone towers 2020 and 2021, potentially even those operated by different cell operators. The presence of these devices can be used to define a location "fingerprint" for the user's work location.

As shown, device proximity detection logic 2001 on client device 1700 can capture data related to visible devices and compare the results with historical device proximity data 2004. Historical device proximity data 2004 can be generated over time and/or through a training process. For example, in one embodiment, a user can (manually or when prompted by client 1700) specify when they are at work, home, or another location. In response, device proximity detection logic 2001 can detect nearby devices and permanently store the results as historical device proximity data 2004. When the user subsequently returns to that location, device proximity detection logic 2001 can compare the devices it currently "sees" with the devices stored as historical proximity data 2004 to generate correlations between the two. Generally speaking, the stronger the correlation, the more likely the client is located at the specified location. Over time, frequently seen devices can be prioritized over other devices in historical device proximity data 2004 (for example, because these devices tend to provide more accurate correlations with the user's work location).

In one embodiment, the verification policy engine 1710 may use the correlation results provided by the device proximity detection logic 2001 to determine the level of verification required by the user for each relying party 1750. For example, if there is a high correlation (i.e., above a specified threshold), the verification policy engine may not require the end user to perform explicit verification. Conversely, if the correlation between the user's current location and the historical device proximity data 2004 is low (i.e., below a specified threshold), the verification policy engine 1710 may require a stricter verification (e.g., biometric verification, such as a fingerprint scan and/or a request for a PIN).

In one embodiment, the device proximity detection logic 2001 identifies a group of other authenticated devices in the vicinity of the client. For example, if several of the user's colleagues have successfully authenticated, the risk associated with allowing the user to access certain data using a less reliable authenticator may be less, simply because the user is operating in the presence of his/her peers. In this embodiment, authentication tokens can be collected from peer devices using peer-to-peer communication via standards such as 802.11n, which can be used to prove that those peer devices have been authenticated.

In another embodiment, the device proximity detection logic 2001 may also detect a previously authenticated device (e.g., such as the user's mobile phone or tablet) that is paired with the user's client. The presence of another authenticated device used by the same user attempting authentication may be used as input to authentication decisions, particularly when accessing the same application.

In one embodiment, historical device proximity data 2004 is collected and shared among multiple devices, and can be stored and retained on an intermediate authentication service. For example, the history of multiple groups of peer devices and network devices in various locations can be tracked and stored in a central database on each device that can be accessed by the device proximity detection logic 2001. This database can then be used as input to determine the risk of an attempted authentication from a particular location.

E. Embodiments for Confirming Location Using Supplemental Sensors and/or Location Data

As described above, one embodiment of the present invention utilizes data from additional sensors 1743 of the mobile device to provide supplemental inputs to the risk calculation used for verification. These supplemental inputs can provide additional levels of assurance that can help confirm or refute the location of the end-user's device.

As shown in FIG21 , additional sensors 1743 that provide supplemental assurance regarding the device's location may include a temperature sensor 2101, a humidity sensor 2102, and a pressure sensor 2103 (e.g., a barometric or altimeter pressure sensor). In one embodiment, the sensors provide temperature, humidity, and pressure readings, respectively, which the verification policy engine 1710's supplemental data correlation module 2140 uses to correlate supplemental data 2110 known to be associated with the location provided by the location sensor 1741 (or derived using various other techniques described herein). Verification policy module 1711 then uses the correlation results to select one or more verification techniques 1712 for a given transaction. As indicated in FIG21 , supplemental location data 2110 may include data collected from external sources (e.g., the internet or other mobile devices) and local data sources (e.g., historical data collected during periods when the device is known to be in the possession of a legitimate user).

The supplemental data correlation module 2140 can use data provided by the additional sensors 1743 in a variety of different ways to establish correlations with the supplemental location data 2110. For example, in one embodiment, the supplemental location data 2110 includes current local weather conditions at the location provided by the location sensor 1741. The supplemental data correlation module 2140 compares the humidity, temperature, or air pressure collected from the additional sensors 1743 with the real-time local weather data 2110, identifying instances where the sensor data is inconsistent with the local conditions. For example, if the client device's GPS reading indicates that the device is outdoors, but the temperature, humidity, or air pressure is inconsistent with the local weather conditions, the supplemental data correlation module 2140 can generate a low correlation score and the location can be considered less trustworthy. As a result, the verification policy module 1711 can require a stricter verification technique 1712 (e.g., fingerprint, PIN entry, etc.) to approve the transaction.

As another example, the supplemental data correlation module 2140 can compare the altitude provided by the altimeter pressure sensor 2103 with the known geography or network topology of the claimed location (with the supplemental location data 2110), identifying discrepancies that indicate the claimed location is not authentic. For example, if a reverse IP lookup of the user's claimed location identifies the location as being in the Andes Mountains, but the altimeter data from the device indicates that the device is at sea level, the supplemental data correlation module 2140 can generate a low correlation score and the location can be considered less trustworthy. Due to the low correlation score, the verification policy module 1711 can attempt to use stronger verification to mitigate the higher risk of the transaction.

In one embodiment, the supplemental data correlation module 2140 compares the data collected from the sensor 1743 on the user's device with that of multiple other end users in the vicinity to identify anomalies that indicate the user is not operating in the same physical location as those known users. For example, if a group of authenticated users are identified as operating in the same physical area, and all of those users' devices indicate that the local temperature in that area is 10°C, the supplemental data correlation module 2140 may generate a low correlation score for the end user whose temperature sensor 2101 indicates a local temperature of 20°C. Consequently, the authentication policy 1711 may require that a stricter authentication technique 1712 be performed.

As another example, the supplemental data correlation module 2140 can compare current readings with historical data for a particular user. For example, as mentioned, the sensor data can be analyzed during a period when the user is known to be in possession of the device 1700 (e.g., a period after explicit authentication). The supplemental data correlation module 2140 can then look for gaps in the local data to identify suspicious behavior. For example, if the user's ambient temperature typically fluctuates between 10°C and 20°C and the user's current ambient temperature is 30°C, this may indicate that the user is not in a typical location, thereby generating a low correlation and causing the authentication policy module 1711 to request an additional level of scrutiny of the transaction.

The supplemental data correlation module 2140 can establish various different types of correlations between the sensor data and the supplemental location data while still complying with the underlying principles of the present invention. For example, various known correlation mechanisms can be used to determine the statistical relationship between the two sets of data. In one embodiment, the correlation score provided to the verification strategy engine 1711 includes a normalized value (e.g., between 0 and 1) indicating the level of correlation. In one embodiment, various threshold levels can be set for the difference between the detected sensor 1743 and the supplemental location data 2110. For example, if the temperature measured by the temperature sensor 2101 differs by more than 3 degrees from the current temperature (collected from another device or the internet), a first threshold can be triggered (causing the correlation score to become lower). Each additional 3 degrees difference from the current temperature can subsequently cause a new threshold to be met (causing a corresponding decrease in the correlation score). However, it should be noted that these are merely examples of one embodiment of the present invention; the underlying principles of the present invention are not limited to any particular manner of establishing correlations.

FIG22 illustrates a method according to one embodiment of the present invention. At 2201, the current location currently reported by the client device (e.g., via a GPS module on the device) is read. At 2202, supplemental location data is collected for the reported location, along with sensor data from the client device. As described above, the supplemental location data may be collected locally or remotely (e.g., from other clients and/or servers over the Internet), and may include data such as the current temperature, pressure, and/or humidity of the reported location. The sensor data may be provided by a temperature sensor, a barometric or altimeter pressure sensor, and/or a humidity sensor.

At 2203, a correlation is established between the supplemental location data and the sensor data provided by the device sensor. In one embodiment, a relatively high correlation will result in a relatively high correlation score at 2204, while a low correlation will result in a relatively low correlation score. As mentioned, in one embodiment, the correlation score is a normalized value (e.g., between 0 and 1) indicating the similarity between the sensor reading and the supplemental data.

At 2205, one or more authentication techniques are selected based (at least in part) on the relevance score. For example, if a relatively low relevance score is provided, a more stringent authentication technique may be selected, while if a relatively high relevance exists, a less stringent authentication technique (potentially one that does not require the end user to perform explicit authentication) may be selected.

If it is determined at 2206 that the user has successfully authenticated using the selected technique, then the transaction is allowed to proceed at 2207. If not, then the transaction is blocked at 2208.

The above-described embodiments achieve a number of benefits. For example, these embodiments provide additional levels of assurance for location data collected from other sources: allowing organizations to supplement location data collected from other sources (IP, GPS, etc.) in order to obtain additional assurance that the location is authentic. Additionally, embodiments of the present invention can prevent transactions from unauthorized locations, thereby reducing unauthorized access by limiting the locations from which users can even attempt authentication. Furthermore, these embodiments can force the use of stronger authentication in response to location-specific risks (e.g., a relying party can minimize the inconvenience of authentication when a user is accessing information from a known location, while still maintaining the ability to require stronger authentication when the user/client is accessing from an unknown or unexpected location, or a location that cannot be adequately proven using multiple inputs).

F. Adaptive application of authentication strategies based on client authentication capabilities

As shown in Figure 23, one embodiment of the present invention includes an adaptive authentication policy engine 2345 that allows an organization, for example, a relying party 1750 with a secure transaction service (hereinafter referred to as a "relying party"), to specify which types of authentication are appropriate for a particular interaction category. As shown, the adaptive authentication policy engine 2345 can be implemented as a module within the authentication engine 2311 executed at the relying party 1750. In this embodiment, the adaptive authentication policy engine 2345 is executed based on a policy database 2325, and the policy database 2325 contains data for existing authentication devices 2329, authentication device categories 2328, interaction categories 2327, and authentication rules 2326.

In one embodiment, authentication device data 2329 contains data associated with each of the explicit user authentication devices 1720-1721 known to be used with client 1700. For example, policy database 2325 may include an entry for a "validity model 123" fingerprint sensor, along with technical details about this sensor, such as how the sensor stores sensitive data (e.g., in cryptographically secure hardware, an EAL 3 certificate, etc.) and the false acceptance rate (an indication of how reliable the sensor is in generating user authentication results).

In one embodiment, the authentication device classes 2328 specify logical groupings of authentication devices 2329 based on their capabilities. For example, a specific authentication device class 2328 may be defined for (1) fingerprint sensors that (2) store sensitive data in cryptographically secure hardware that has passed EAL 3 certification, and (3) use a biometric matching process with a false acceptance rate of less than one in a thousand. Another device class 2328 may be (1) facial recognition devices that (2) do not store sensitive data in cryptographically secure hardware, and (3) use a biometric matching process with a false acceptance rate of less than one in two thousand. Thus, fingerprint sensors or facial recognition implementations that meet the above criteria will be added to the appropriate authentication device class 2328.

Authentication device classes can be defined using various individual attributes, such as the type of authentication factor (e.g., fingerprint, PIN, face), the hardware's security assurance level, the storage location of confidential information, the location where the authenticator performs cryptographic operations (e.g., in a secure chip or secure enclosure), and a variety of other attributes. Another set of attributes that can be used relates to where the "match" operation is performed on the client. For example, a fingerprint sensor can capture and store fingerprint templates in secure storage on the fingerprint sensor itself and perform all verification against those templates within the fingerprint sensor hardware itself, creating a highly secure environment. Alternatively, the fingerprint sensor can be a peripheral device that simply captures an image of the fingerprint but uses software on the main CPU to perform all capture, storage, and comparison operations, creating a less secure environment. Authentication device classes can also be defined using various other attributes associated with the specific implementation of "matching" (e.g., whether matching is performed within (or not within) a secure element, trusted execution environment (TEE), or other form of secure execution environment).

Of course, these are merely examples used to illustrate the concept of verification device categories. Various additional verification device categories may be specified while still adhering to the underlying principles. Furthermore, it should be noted that, depending on how the verification device categories are defined, a single verification device may be classified into multiple device categories.

In one embodiment, policy database 2325 may be periodically updated to include new authentication devices 2329 as they become available, as well as data for new authentication device categories 2328, which may include new categories into which new authentication devices 2329 may be categorized. These updates may be performed by relying parties and/or third parties responsible for providing updates to relying parties (e.g., third parties that sell secure transaction server platforms used by relying parties).

In one embodiment, interaction categories 2327 are defined based on the specific transactions provided by relying party 2325. For example, if relying party is a financial institution, interactions may be categorized based on the monetary value of the transaction. A "high-value interaction" may be defined as a category involving (e.g., transfers, withdrawals, etc.) amounts of $5,000 or more; a "medium-value interaction" may be defined as a category involving amounts between $500 and $4,999; and a "low-value transaction" may be defined as a category involving amounts of $499 or less.

In addition to the monetary value involved, interaction categories can also be defined based on the sensitivity of the data involved. For example, a transaction that discloses a user's confidential or other private data could be categorized as a "disclosed confidential interaction," while a transaction that does not disclose such data could be defined as a "non-disclosed confidential interaction." Various other types of interactions can be defined using different variables and a variety of minimum, maximum, and intermediate levels.

Finally, a set of authentication rules 2326 may be defined that relate to authentication devices 2329, authentication device classes 2327, and/or interaction classes 2327. By way of example, and not limitation, a particular authentication rule may specify that for "high-value transactions" (as specified by interaction class 2327), only fingerprint sensors (as specified by authentication device class 2328) that store sensitive data in EAL 3-certified cryptographic security hardware and use a biometric matching process with a false acceptance rate of less than one in a thousand may be used. If a fingerprint device is not available, the authentication rule may define other acceptable authentication parameters. For example, the user may be required to enter a PIN or password and also answer a series of personal questions (e.g., personal questions previously provided by the user to the relying party). Rules may be defined using any of the aforementioned individual attributes specified for the authentication device and/or authentication device class, such as the authentication factor type (e.g., fingerprint, PIN, face), the hardware's security assurance level, the storage location of confidential information, and the location where the authenticator performs cryptographic operations.

Alternatively or in addition, it may be specified in the rules that certain attributes can take any value as long as other values are sufficient. For example, a relying party may specify that a fingerprint device must be used and that the fingerprint device stores the seed and performs the calculation in hardware, but is not concerned with the assurance level of the hardware (as defined by the verification device class 2328 containing a list of verification devices that meet these parameters).

Additionally, in one embodiment, a rule may specify that only certain types of interactions may be authenticated using certain authentication devices 2329. For example, an organization may specify that only "validity model 123 fingerprint sensors" are acceptable.

Additionally, a rule or set of rules can be used to create a neatly ordered combination of authentication policies for an interaction. For example, these rules can specify a combination of policies for each authentication policy, allowing for the creation of rich policies that accurately reflect the authentication preferences of the relying party. This would allow, for example, a relying party to specify that a fingerprint sensor is preferred, but if no fingerprint sensor is available, then Trusted Platform Module (TPM)-based authentication or facial recognition would also be preferred as the next best alternative (e.g., in order of priority).

In one embodiment, when determining whether to permit a transaction with client 1700, adaptive authentication policy engine 2345 implements authentication rules 2326 based on interaction categories 2327, authentication device categories 2328, and/or authentication device data 2329. For example, in response to a user of client device 1700 attempting to enter into a transaction with a relying party website or other online service 2346, adaptive authentication policy engine 2345 may identify a set of one or more applicable interaction categories 2327 and associated authentication rules 2326. It may then apply these rules via communication with adaptive authentication policy module 2350 on client device 1700 (illustrated in FIG. 23 as a component within the client's authentication engine 2310). Adaptive authentication policy module 2350 may then identify a set of one or more authentication techniques 2312 that complies with the specified authentication policy. For example, if the relying party's adaptive authentication policy engine 2345 specifies a prioritized set of authentication techniques, adaptive authentication policy module 2350 may select the highest priority authentication technique available on client 1700.

The results of the verification technique 2312 are provided to the assurance calculation module 2340, which generates an assurance level that the current user is a legitimate user. In one embodiment, if the assurance level is high enough, the client will transmit the result of the successful verification to the relying party's verification engine 2311, which will then approve the transaction.

In one embodiment, data from the client device sensors 1741-1743 may also be used by the assurance calculation module 2340 to generate an assurance level. For example, a location sensor (e.g., a GPS device) may indicate the current location of the client device 1700. If the client device is in an expected location (e.g., at home or at work), the assurance calculation module 2340 may use this information to increase the assurance level. Conversely, if the client device 1700 is in an unexpected location (e.g., a foreign country that the user has never visited before), the assurance calculation module 2340 may use this information to decrease the assurance level (thereby requiring stricter explicit user authentication to achieve an acceptable assurance level). As discussed above, various additional sensor data (such as temperature, humidity, accelerometer data, etc.) may be integrated into the assurance level calculation.

The system shown in FIG23 can operate differently based on the specificity of transmitting the client's authentication capabilities and other information to the relying party. For example, in one embodiment, the specific model of each explicit user authentication device 1720 and 1721, as well as the specific details of the security hardware/software and sensors 1741 to 1743 on the client device 1700, can be transmitted to the relying party 1750. Thus, in this embodiment, the adaptive authentication policy engine 2345 can explicitly identify the required authentication mode based on the authentication rules implemented for the current transaction and the risk associated with the client. For example, the adaptive authentication policy module 2345 can perform authentication for a given transaction request via the "validity model 123" fingerprint sensor installed on the client.

In another embodiment, to protect the user's privacy, only a general description of the authentication capabilities of the client device 1700 may be provided. For example, the client device may communicate that it has a fingerprint sensor that stores sensitive data in cryptographically secure hardware that has passed EAL 3 certification and/or uses a biometric matching process with a false acceptance rate of less than 1 in N. The client device may specify similar general information regarding the capabilities and specifications of other authentication devices without disclosing the specific models of those devices. The adaptive authentication policy engine 2345 can then use this general information to classify the authentication device into an applicable authentication device category 2338 within the database 2325. In response to a request to perform a transaction, if the category of a particular authentication device is sufficient to complete the transaction, the adaptive authentication policy engine 2345 can then instruct the client device 1700 to use that particular authentication device.

In yet another embodiment, the client device 1700 does not transmit any data related to its verification capabilities to the relying party. Instead, in this embodiment, the adaptive verification policy module 2345 communicates the required verification level, and the adaptive verification policy module 2350 on the client selects one or more verification technologies that meet that verification level. For example, the adaptive verification policy module 2345 may convey that the current transaction is classified as a "high value transaction" (specified by the interaction category 2327), for which only certain categories of verification devices can be used. As mentioned, the adaptive verification policy module 2345 can also convey the verification categories in a prioritized manner. Based on this information, the adaptive verification policy module 2350 on the client can then select one or more verification technologies 2312 required for the current transaction.

As indicated in FIG. 23 , client device 1700 may include its own policy database 2390 for storing/caching policy data for each relying party. Policy database 2390 may include a subset of the data stored within a relying party's policy database 2325. In one embodiment, a different set of policy data is stored in database 2390 for each relying party (reflecting each relying party's different authentication policies). In these embodiments, a mere indication of a particular transaction category (e.g., "high-value transaction," "low-value transaction," etc.) may be sufficient information for adaptive authentication policy module 2350 on client device 1700 to select the necessary authentication technology 2312 (i.e., because rules associated with various transaction types can be found within local policy database 2390). Thus, adaptive authentication policy module 2345 may simply indicate the interaction category of the current transaction, which adaptive authentication policy module 2350 uses to identify authentication technology 2312 based on the rules associated with that interaction category.

A method for performing adaptive authentication based on client device capabilities is shown in Figure 24. This method can be implemented on the system shown in Figure 23, but is not limited to any particular system architecture.

At 2401, a client attempts to perform a transaction with a relying party. By way of example and not limitation, the client may enter payment information to make an online purchase or attempt to transfer funds between bank accounts. At 2402, the transaction is categorized. For example, as discussed above, the transaction may be associated with a particular interaction category based on variables such as the amount involved or the sensitivity of the information involved.

At 2403, one or more rules associated with the transaction category are identified. Returning to the previous example, if the transaction is categorized as a "high value transaction," the rules associated with this transaction type may be selected. At 2404, the rules associated with the transaction type are executed, and as discussed above, information indicating the authentication requirements for completing the transaction is sent to the client. As discussed above, this process may involve identifying a specific authentication device, identifying a class of authentication device, or simply indicating specific rules that need to be implemented (e.g., if the client maintains a local copy of these rules).

In any case, a set of authentication techniques, consisting of one or more authentication techniques, is selected based on the requirements specified via the rules and the authentication capabilities of the client at 2405. If authentication is determined to be successful at 2406, the transaction is permitted at 2407. If not, the transaction is blocked at 2408 (or additional authentication is requested from the user).

Numerous benefits can be achieved through the embodiments of the present invention described herein. For example, these embodiments reduce the effort required to integrate authentication capabilities at a relying party. For example, instead of writing code to codify authentication policies, rules can be configured through a simple graphical user interface. To complete the integration, the relying party simply defines a policy for an interaction category (e.g., "Large Amount Transfer") and has the integration code use the corresponding policy identifier when interacting with the policy engine to determine the correct authentication mechanism to utilize.

Furthermore, these embodiments simplify authentication policy management. This approach expresses authentication policy outside of code, making it easy for organizations to update their authentication policies without requiring code changes. Changes to reflect new interpretations of regulatory requirements or in response to attacks on existing authentication mechanisms become simple changes to policy and can be quickly implemented.

Finally, these embodiments allow for future improvements to authentication technologies. As new authentication devices become available, organizations can assess their suitability for addressing new or emerging risks. Integrating newly available authentication devices simply requires adding the authentication device to the policy; there's no need to write new code to immediately deploy new capabilities.

G. Systems and Methods for Eye Tracking During Verification

Generally speaking, authentication technologies are robust against spoofing if (a) they use secret information for authentication or (b) it's difficult to generate false input. Today, most systems rely on password-based authentication. Passwords are easy to copy and therefore need to be kept secret. Consequently, password attacks often focus on obtaining user passwords. Recent attacks have demonstrated that servers storing authentication passwords are vulnerable.

Compared to password-based authentication, when using biometrics for authentication, the biometric information is typically public. For example, a user's fingerprint can be obtained from (almost) any object they touch. Similarly, a user's face is typically not hidden and can be seen and captured by anyone, often even published on social networks.

In the real world, we can rely on our own recognition abilities when looking at a person because it's difficult to "create" another person with the same biometric characteristics. For example, it's equally difficult to "create" another person with the same face and mannerisms. This is why governments place facial images on passports, ID cards, driver's licenses, and other documents. However, in the virtual world, we don't have to "create" another person with the same face to trick the system; we just have to create something the computer will recognize (like a picture of the face). In other words, "the implication is that biometrics only works if the authenticator can verify two things: that the biometric information comes from a person at the time of authentication, and that the biometric information matches the primary biometric information on file" (see Reference 1 in the list of references provided before the claims of this specification).

In the past, research in automatic facial recognition has focused on reliably identifying faces using static images and videos. See, for example, Reference 2 below. Several relatively robust facial recognition technologies exist, and a variety of systems are currently commercially available (see Reference 3). However, little attention has been paid to "liveness" detection, i.e., "confirming that the biometric information is consistent with the primary biometric information on file." In several use cases, spoofing protection is either not required or is still performed by humans (e.g., in law enforcement applications).

The widespread availability of cameras in computing devices like laptops and smartphones, coupled with the shortcomings of passwords as the most popular authentication method, have driven the popularity of biometric authentication methods, particularly facial recognition. The first large-scale experiment with facial recognition as an authentication method appeared in Google Android 4 (also known as "Ice Cream Sandwich") and was based on static image recognition. However, these technologies can be easily spoofed using photos (see Reference 4). Although Android 4.1 (also known as "Jelly Bean") implemented an improved method with a liveness check, it can still be easily spoofed by presenting two photos sequentially to the camera on a computer monitor—one with open eyes and one electronically altered with closed eyes—once displayed (see Reference 5).

While some might argue that this shortcoming is due to resource limitations on mobile devices, it also demonstrates that commercially available software for PCs, and even research on anti-spoofing detection, is still relatively immature. The assignee of this application conducted tests using PC-based facial recognition software, and the test results showed that:

Even with security settings set to "High," Cogent BioTrust 3.00.4063 running on a Windows-based Samsung Series laptop performed no liveness check at all. A simple facial image displayed on a regular computer monitor was enough to successfully fool the system.

KeyLemon 2.6.5 running on a Macbook performs a simple eye-blink test as a liveness check. The system can be successfully fooled by simply showing a series of three images: (1) a real image of a face (e.g., created by a webcam); (2) a modified version of the real image in which the eyes have been recolored to appear closed; and (3) another real image.

When comparing different algorithms, anti-spoofing detection is not part of standard tests (such as the NIST biometric vendor tests). See, for example, References 6 to 8. One of the first known public competitions organized by several researchers in 2011 (see Reference 9) showed early success with some algorithms, but these algorithms were based on videos with a resolution of 320×240 pixels. Typical computing devices provide front-facing cameras with a resolution of at least 640×480 pixels.

FIG25 illustrates an exemplary client 2520 with a biometric device 2500 configured to perform facial recognition. During normal operation, a biometric sensor 2502 (e.g., a camera) reads raw biometric data from a user (e.g., by taking a photo of the user), and a feature extraction module 2503 extracts specified features from the raw biometric data (e.g., focusing on certain facial features, etc.). A matcher module 2504 compares the extracted features to biometric template data 2510 stored in secure storage on the client 2520 and generates a score and/or a yes/no response based on the similarity between the extracted features and the biometric template data 2510. The biometric template data 2510 is typically the result of an enrollment process in which a user enrolls a facial image or other biometric data with the device 2500. Application 2505 can then use the score or yes/no response to determine whether authentication was successful.

Facial recognition systems can be deceived from multiple potential attack points (see references 10, 11), which are identified as (1) to (8) in Figure 25. There are well-known protection mechanisms that ensure the integrity of the biometric template (6) (e.g., by using an electronic signature) and protect the integrity of the feature extraction (3), feature vectors (4), matcher (5) and its final result (8) (e.g., by applying a combination of (a) white box cryptography methods, (b) code obfuscation and (c) device binding).

The Trusted Computing Group's approach, and potential extensions to ARM TrustZone (at least in theory), include protection mechanisms to prevent replaying old captured data to the feature extraction unit (2). Essentially, the approach involves adding cryptographic protection mechanisms (e.g., HMAC or electronic signatures) to the sensor and packaging it in a tamper-proof manner, similar to the protection mechanisms currently used in smart card chips. The feature extraction engine can then verify the integrity of the incoming data.

While the embodiments of the present invention described below utilize eye tracking technology to confirm a user's "liveliness," in one embodiment, these technologies are used in combination with one or more existing techniques for detecting fake biometrics (see Reference 1). This area is currently under research. Existing research has identified four different categories of defenses against fake biometrics (see Reference 12):

1. Data-driven characterization

a. Still images

i. Detecting resolution loss by rescanning the image and analyzing the 2D Fourier spectrum (Ref. 13)

ii. Utilize the different reflective characteristics of real faces and image prints. The theory is based on the Lambertian reflectance characteristic (Reference 14)

iii. Exploiting the different microtextures of real faces and image prints caused by printing defects (Reference 15).

iv. Utilize degradation and noise addition on printed images and combine with other methods (Reference 16).

b. Video

v. Each camera sensor has its own characteristics, and recapturing the video displayed on the monitor will cause artifacts. This can be exploited to detect spoofing (Reference 12).

vi. If images are used for spoofing, there will be dependencies between the face and the background (Reference 17).

vii. In the case of a spoofing attack, facial movements are usually stiff (Reference 18).

c. Combination of static images and videos (Reference 12).

2. User behavior modeling (Reference 12).

3. User interaction requirements (Reference 12).

4. Additional devices (reference 12).

The most effective non-intrusive mechanism based solely on existing sensor technology appears to be based on a combination of motion detection, texture detection, and liveness detection (see Ref. 9).

Texture Differences

The effects of printing and rescanning an image can be detected. It's intuitively clear that the image quality doesn't improve after printing and rescanning it. Research in Reference 15 suggests that differences can be algorithmically detected by analyzing microtexture: "A close examination of the differences between a real face and a print of a face reveals that faces and prints reflect light differently because faces are complex, non-rigid 3D objects, while photographs can be viewed as flat, rigid objects."

The algorithm was tested against images included in the NUAA Image Spoofing Database, and reported an average performance of 16.5ms for processing images on a 2.4GHz Intel Core 2 Duo CPU with 3GB of RAM using unoptimized C++ code.

Infrared, not visible light

It is difficult to display images or videos in the infrared spectrum. Therefore, liveness detection based on capturing thermal images of the face, as proposed in Reference 19, would be more robust than capturing images in visible light. Unfortunately, infrared sensors are expensive and therefore not included in typical laptops, tablets, or smartphones.

Optical flow based methods

Real faces are three-dimensional objects. Faces typically move during normal conversation. The 2D motion of the central part of the face, that is, the part closer to the camera, is expected to be higher than the 2D motion of facial regions farther from the camera (References 20, 21, 22). For this type of detection, a sequence of at least three consecutive images is required.

The research in reference 21 is part of the SART-2 project (Biometric Security System for Mobile Workstations).

Moving pictures, not static images

Reference 23 describes a liveness detection method based on blinking. This method appears to be quite robust against simple photo-based spoofing attacks. In addition to recognizing faces, the method also locates eyes and checks whether closed eyes can be seen in the observed image sequence. As seen in large-scale experiments on Android 4.1, this method is clearly not very robust against "Photoshop" attacks. See Reference 5.

Typically, to trick such motion-image-based systems, an attacker must generate a sequence of small images and present that sequence to the sensor. This is quite easy to do in a world of powerful image editors, free video editors, and tablet PCs.

Such methods are characterized by “known interactions”, i.e., the attacker knows the required interactions in advance and is able to prepare matching image sequences.

In Reference 23, scenes and eye blinks are included in the analysis. The performance is measured to be approximately 50 milliseconds per video frame (20 fps) on an Intel Core 2 Duo 2.8 GHz with 2 GB of RAM.

Challenge Response Method

In the context of biometrics, a challenge response is defined as:

A method of confirming a person's presence by eliciting a direct response from the individual. Responses can be voluntary or involuntary. In a voluntary response, the end user consciously reacts to what the system presents. In an involuntary response, the end user's body automatically responds to the stimulus. Challenge response can be used to protect systems from attacks.

(National Science & Technology Council’s Subcommittee on Biometrics)

Multimodal systems

Multimodal systems have been proposed to improve the robustness of biometric methods against spoofing attacks, noisy data, etc. See Ref. 25.

Reference 26 analyzes the impact of simulated spoofing attacks on such multimodal systems. The main result is that not all fusion schemes improve robustness against spoofing attacks, meaning that in some fusion schemes, fooling just a single biometric method is sufficient to fool the entire multimodal system. Similar results were obtained from an analysis of existing schemes using real spoofing attacks (see Reference 27).

Generally speaking, there are three different categories of multimodal systems:

1) A system where successfully fooling a single feature is sufficient to fool the entire system. Optimizing a multimodal system for small FRR often leads to this type of result.

2) Systems with the following conditions:

a) more than one characteristic must be deceived to successfully deceive the entire system; and

b) Deceiving any one feature in this multimodal system is no more complex than deceiving the same feature in a unimodal system.

3) Systems with the following conditions

a) more than one characteristic must be deceived to successfully deceive the entire system; and

b) It is more complex to spoof any one feature in this multimodal system than to spoof the same feature in a unimodal system. The embodiments of the present invention described below belong to this category.

One embodiment of the present invention performs eye tracking as part of the authentication process to measure responses to different areas of interest that are randomly arranged and displayed on the screen. For example, a user may be presented with a series of random screen layouts that mix text, white space, images, and video clips, thereby eliciting eye movements from the user in a non-invasive manner. Simultaneously, eye tracking technology is used to confirm that the eyes are reacting to the screen layout in the expected manner. This information can then be combined with facial recognition technology to verify that the expected face is still present. Furthermore, as discussed above, eye tracking technology and facial recognition technology can be combined with other technologies (e.g., location-based authentication, non-invasive user presence detection, fingerprint scanning, etc.) to achieve a sufficient level of assurance that the legitimate user is in possession of the device.

Reading a web page or other type of content does not involve a smooth movement of the eyeballs along the content, but rather a series of brief pauses (called "gazes") and rapid "scans." The resulting series of gazes and scans is called a "scan path." Scan paths can be used to analyze cognitive intent, interests, and characteristics (see the current Wikipedia article on "Eye Tracking" at en.wikipedia.org/wiki/Eye_tracking). A "heat map" is a collective representation showing where a group of people gaze while viewing a web page or email (see Hartzell, "Crazy Egg Heatmap Shows Where People Click on Your Website" (Nov 30, 2012) (Hartzell. Crazy Egg Heatmap Shows Where People Click on Your Website. www.michaelhartzell.com/Blog/bid/92970/Crazy-Egg-Heatmap-shows-where-people-click-on-your-website, 2012-11-30).

As shown in Figure 26, one embodiment of the present invention includes an authentication engine 2610 on a client device 2600, which includes a facial recognition module 2604 for performing facial recognition and an eye tracking module 2605 for performing eye tracking operations described herein. In one embodiment, the facial recognition module 2604 and the eye tracking module 2605 analyze a video image sequence 2603 captured by a camera 2602 on the client device to perform corresponding operations.

To perform facial recognition operations, facial recognition module 2604 relies on facial recognition templates stored within secure facial recognition database 2646. Specifically, as discussed above, matching logic within facial recognition module 2604 compares facial features extracted from video image 2603 to facial template data stored in facial recognition database 2646 and generates a "score" based on the similarity between the extracted features and the facial template data. As previously discussed, the facial template data stored in database 2646 may be generated by an enrollment process in which a user registers a facial image or other biometric data with client device 2600. The score generated by facial recognition module 2604 can then be combined with scores from other verification modules (e.g., such as eye tracking module 2605, discussed below) to form an assurance level 2606, which represents the degree of confidence that a legitimate user is initiating the current transaction. In one embodiment, each score must meet a specific threshold to generate a sufficient assurance level 2606 for a particular transaction. In one embodiment (assuming the threshold has been reached), the scores may be summed or combined using another mathematical formula (eg, the scores may be weighted, averaged, summed, or combined in any other manner).

To perform eye tracking analysis, the eye tracking module 2605 relies on eye tracking templates stored in the secure eye tracking database 2645. Although shown as separate databases, the eye tracking database and the facial recognition database may actually be the same secure database. In one embodiment, the eye tracking template specifies the text, graphics, pictures, videos, and/or blank areas to be displayed to the user on the client device's display 2601 (some examples are shown in Figures 28A and 28B below), and may also specify the order in which these contents are displayed. In addition, the eye tracking template includes data specifying the expected movement characteristics of the user's eyes in response to the content displayed to the user (e.g., in the form of a heat map, see below). Matching logic within the eye tracking module 2605 compares the expected movement of the user's eyes with the actual movement (captured from the video imagery), deriving a "score" based on the similarity between the expected and actual movements. As mentioned, this score can then be combined with scores from other verification modules (e.g., such as the facial recognition module 2604) to form an assurance level 2606. The eye tracking template data stored in database 2646 can be compiled using records of eye movements made by other users and/or the actual user of the device in response to each displayed web page or other displayed image. For example, like facial recognition templates, eye tracking templates can be generated as part of an enrollment process in which a user registers his/her eye movements with device 2600.

In one embodiment, the eye tracking module 2605 determines the correlation between the image being displayed (which may include text, graphics, videos, pictures, and/or blank areas) and the user's eye movements. For example, if a sports video is displayed in the lower right corner of the display, most users will turn their attention to this area. Therefore, if the eye tracking module 2605 detects that the user's eyes have moved to this area within a specified time period (e.g., 2 seconds), the eye tracking module 2605 will detect a high correlation between the user's eyes and the template, resulting in a relatively high score. Conversely, if the user's eyes have not moved to this area (or have not moved at all), the eye tracking module 2605 will detect a low correlation, resulting in a correspondingly low score.

As shown in FIG26 , various other explicit user authentication devices 2620-2621 and sensors 2643 may be configured on the client device 2600. These authentication devices and sensors may provide additional authentication data (where necessary) to be used by the authentication engine 2610 when generating the assurance level 2606 (i.e., in addition to the eye tracking and facial recognition described herein). For example, the sensors may include a location sensor (e.g., GPS) to determine the location of the client device 2600. If the client device is in an expected location, the authentication engine may use this data to increase the assurance level 2606. Conversely, if the client device is in an unusual location (e.g., in another country), this may negatively impact the assurance level 2606. In this way, authentication data may be generated in a non-invasive manner (i.e., using sensor data collected without explicit input from the end user).

Additionally, another non-intrusive technique involves the verification engine 2610 monitoring the time that has passed since the last explicit user verification. For example, if the user has recently (e.g., within 10 minutes) verified using a fingerprint or other biometric device 2620-2621 or entered a password, the verification technology will use this information to increase the assurance level 2606. Conversely, if the user has not explicitly verified for several days, the verification technology may require the facial recognition module 2605 and the eye tracking module 2605 to perform a stricter verification (e.g., a higher than usual correlation with the template data may be required to raise the assurance level to an acceptable value for the current transaction).

In one embodiment, secure storage 2625 is a secure storage provided for storing authentication keys associated with each authenticator and used by secure communications module 2613 to establish secure communications with a relying party (e.g., cloud service 2650 or other type of network service).

An example "heat map" generated for a web page is shown in FIG27 . The color coding indicates the areas of the web page where users gazed while viewing. Red indicates the highest amount of gaze (meaning that users tend to look at these areas more frequently), followed by yellow (indicating less gaze), blue (indicating even less gaze), and then no color (indicating no gaze or gaze below a threshold amount).

When designing web pages, perform eye tracking and heatmap analysis as part of a usability analysis. Studies (e.g., see References 29 and 30) have found that web users spend 80% of their time looking at information above the fold. While users do scroll, they only devote 20% of their attention to information below the fold. Web users spend 69% of their time looking at the left half of the page and 30% looking at the right half. Therefore, conventional layouts are more likely to make websites profitable.

Spoofing attacks such as presenting a static facial image or video displayed on a monitor can be detected by the eye tracking module 2605 because the scan path will most likely not be correlated with the screen layout. Different types of eye tracking methods can be used: dedicated equipment with high accuracy and software-based methods using standard webcams (see Reference 33).

Figure 28A shows an exemplary grouping of text 2805 and images and/or videos 2801 displayed on a client device display 2601. In one embodiment, the grouping is integrated into a web page. However, the underlying principles of the present invention are not limited to Web-based organizations. The grouping can also be part of a screen saver or other application. In one embodiment, text 2805 and images/videos 2801 are displayed simultaneously. In another embodiment, the text is displayed first, followed by images/videos 2801. In either case, it is expected that the user's eyes will be directed to the lower right corner of the display 2601 (where the images/videos 2801 are displayed).

28B shows another example including a text area 2805 and three image/video elements 2800 to 2802. In one embodiment, image/video element 2800 is displayed first, followed by image/video element 2801, and then image/video element 2802. In this case, the user's eyes should move from the upper right corner of the display to the lower right corner, and then to the lower left corner.

In one embodiment, the specific image/video elements 2800 to 2802 and other content types are randomly selected by the eye tracking module 2605, making it more difficult to predict and deceive. In addition, the specific locations where the different image/video elements 2800 to 2802 are located are randomly selected. In such cases, the eye movement template may specify a specific operating mode for displaying content, but will not specify the actual content or actual location. Instead, the content and location are selected by the eye tracking module 2605, which will then assume that the user's eyes should be drawn to the content being displayed and generate a correlation and score based on the degree of detected movement.

Additionally, rather than generating its own content, the eye tracking module 2605 can use existing content, such as an existing web page of the relying party 2650 or an image stored locally on the device. For example, if the relying party is a financial institution and the user is attempting to enter into a financial transaction, a web page typically displayed during a transaction can be displayed. In such a case, the eye tracking module 2605 can retrieve a heat map of the web page from the eye tracking database 2645 (such as that shown in FIG. 27 ) and determine whether there is a correlation between the heat map and the location the end user is looking at.

In summary, the embodiments described herein can present a series of randomized screen layouts that mix text, white space, images, and video clips, and continuously track the user's eyes, thereby generating a captured scan path. A correlation is then established between the captured scan path and the expected scan path. Furthermore, one embodiment of the present invention can then re-verify that the face is still recognized.

Not all people are equally attracted to the same images or sequences of images. For example, some people are more attracted to technology than to animals, text, known or unknown human faces or bodies, cryptic symbols, or even mathematical formulas. Accordingly, one embodiment of the eye tracking module 2605 learns the person-specific characteristics of eye movements triggered by different types of images. The similarity of the measured characteristics from the video image 2603 to reference data (stored in the eye tracking database 2645) is then used to generate an assurance level 2606 (i.e., the certainty that the legitimate user's eyes are following the "challenge" image, video, or other content displayed on the display 2601).

A method according to one embodiment of the present invention is shown in Figure 29. The method may be implemented within a system architecture such as that shown in Figure 26, but is not limited to any particular system architecture.

At 2901, a specific eye tracking template is selected for a given user and/or transaction, and at 2902, a sequence of images of the user's face is captured while content is displayed according to the template. For example, the template may specify the type of content, the location of the content, and the timing of displaying the content. Alternatively, the template may only generally specify the type of eye tracking, and the eye tracking module 2605 may determine how, where, and when to display the content.

Regardless of how the content is selected and displayed, facial recognition is performed at 2903, and eye tracking analysis is performed using the captured image sequence at 2904. A face assurance level is generated based on a correlation between the captured image and the facial template at 2905. Similarly, an eye tracking assurance level is generated based on a correlation between the user's eye movements and the expected movement of the user's eyes at 2906.

Although shown in FIG. 29 as parallel operations 2903/2905 and 2904/2906, the facial recognition operation 2903/2905 may be performed first, and then the eye tracking operation 2904/2906 may be performed only if the facial recognition operation yields a high correlation/assurance level (or vice versa).

At 2907, a determination is made as to whether the combined results of facial verification and eye tracking are sufficient to allow the current transaction to proceed. If so, the transaction is permitted at 2909. If not, the transaction is either not permitted at 2908 or additional verification techniques are required to increase the level of assurance. For example, at this stage, the user may be required to swipe their finger on a fingerprint sensor or enter a PIN associated with their account. If, at 2910, it is determined that the additional verification techniques are sufficient, the transaction is permitted at 2909.

H. Systems and Methods for Collecting and Utilizing Client Data for Risk Assessment During Authentication

Some types of authenticators are highly trustworthy, while others are not. Therefore, a relying party can have a certain range of assurance for an authenticator and can use certain types of client data to perform a risk assessment (e.g., adjust that assurance up or down). For example, if the remote authenticator has a secure element or trusted execution environment (TEE), the attestation can be securely signed using an attestation key. The attestation key remains inside the secure element and is inaccessible to any external entity. The actual authentication operation is also performed inside the secure element. By signing with the attestation key, the relying party can know with certainty that a remote authenticator was responsible for the authentication attempt.

If the remote authenticator does not contain a secure element, attestation signing must be performed in software, which opens the door to attack. One way to mitigate this problem is to store the attestation key in a software-protected "white box." The attestation key cannot leave the white box and signs the authentication attempt. However, because the code performing the authentication is separate from the white box performing the attestation signing (and the white box is software-based), this approach is less trustworthy than using a secure element or trusted execution environment (TEE).

Finally, if none of the above are available, the entire authentication operation can be performed entirely in software. This is the least secure approach, as both the authentication code and the verification key itself can be compromised.

In any of the above examples, it would be beneficial if the relying party could collect client data to determine the specific manner in which authentication is being performed so that client risk can be assessed when authentication is performed (e.g., when generating assurance levels, as discussed below).

By improving risk assessment through additional data, one embodiment of the present invention avoids fraudulent transactions by collecting client data and assessing the risk associated with each client. The risk level associated with the client can then be used to specify the authentication technology that must be used to authenticate the user for a particular transaction. To assess risk, one embodiment of the present invention determines (1) the type of data that can be used to calculate risk, (2) how to obtain additional data that a web browser cannot securely provide, and (3) how to perform the assessment in a manner that does not compromise the user's privacy.

One of the biggest reasons why viruses, worms, and malware infect computers is that the operating system has not been recently updated to close potential vulnerabilities. Once these vulnerabilities in the operating system become known to the public, they can be easily exploited by criminals. The longer a system runs without updates, the more potential vulnerabilities that can be exploited, and the higher the risk that passwords may be compromised by malicious code. Web browsers do not allow websites to access the update history of a user's computer. If a website did access it, the website could identify potential victims based on known vulnerabilities on its system. Therefore, one embodiment of the present invention operates as a security agent that is executed as a native application (rather than a browser plug-in) to collect client data to determine the current operating system version and/or how recently the operating system has been updated.

After a user's computer is infected with malicious code, one way to defend against it is to use antivirus software (e.g., ). Even if the malicious code has already infiltrated the system, the antivirus software will at least warn the user that something bad has happened, thereby limiting the damage that is ultimately caused. The user can change their account passwords and review recent transactions. However, if the antivirus software is not installed, or if the antivirus software is installed but has not been run recently, the user is likely unaware of the presence of malicious code on their computer. Transactions occurring on that computer have a higher risk of fraud. The web browser will not reveal whether antivirus software is installed on the computer. Therefore, in one embodiment, the local agent application locates and collects client configuration data to determine whether antivirus software is installed, and if so, also determines the status of updates and/or operation of the antivirus software.

Another defense method, especially against worms, is a firewall. If a software firewall is installed and enabled on the user's machine, this greatly reduces the number of entry points for attacks. Open ports that would normally serve any request coming in over the wire from a random Internet host are weakened. Therefore, even if the service listening on the port has an unpatched security vulnerability, the risk is eliminated because no communication is allowed to access the service. On the other hand, a computer running without a software firewall is much more likely to be infected by a worm, especially if it has not been updated recently. Web browsers can indirectly detect firewalls with limited success through port scanning. Therefore, in one embodiment, the local agent application locates and collects firewall configuration data to determine whether a firewall is installed, and if so, how recently the firewall has been updated.

If a user's computer is physically stolen, criminals can gather a wealth of information and use it to commit fraud. If the user's machine is password-protected, and preferably the entire hard drive is encrypted to that password, the risk of information being compromised due to theft is reduced. If it is not password-protected, it may be assessed as having a higher risk level. Therefore, in one embodiment, the local agent application determines whether the hard drive contents are encrypted and uses this information as part of its risk assessment of the client.

Additionally, as discussed above, if the client uses a secure element or trusted execution environment (TEE) to perform the verification, the relying party can have a high degree of certainty that the verification provided by the client is legitimate. If the remote authenticator does not contain a secure element, a software-protected "white box" can be utilized to protect the verification data (e.g., the verification key). However, as mentioned, since the code performing the verification is separate from the white box that performs the verification signing (and the white box is software-based), this approach is less trustworthy than using a secure element or trusted execution environment (TEE). Finally, if all of the above are not available, the entire verification operation can also be performed entirely in software (as mentioned, this is the least secure way of operating). One embodiment of the present invention allows the relying party to collect the above-mentioned client data to determine the specific way in which the verification is being performed, so that the client risk can be assessed when performing the verification.

As shown in FIG30 , in one embodiment of the present invention, a client device 3000 includes a client-side risk assessment agent 3004 that collects various types of client configuration data 3050 and, in response, calculates a risk level for the client 3000. In one embodiment, the client-side risk assessment agent 3004 is a native code agent application designed to run directly within the native operating system (OS) 3010 of the client 3000. Therefore, the client-side risk assessment agent 3004 is not subject to the restrictions associated with browser plug-ins and other types of program code, which, for security reasons, have limited access to client data. In other words, the client-side risk assessment agent 3004 is permitted to collect data that HTML and JavaScript code running in a browser environment is not permitted to access. Therefore, even though it may be implemented within a browser environment, the verification engine 3010 will still be able to access the additional risk analysis provided by the client-side risk assessment agent 3004 (although it should be noted that the verification engine 3010 need not be implemented within a browser context while still conforming to the underlying principles of the present invention).

In one embodiment, the verification engine 3010 includes an assurance level calculation module 3006 for calculating an assurance level corresponding to the likelihood that a legitimate user possesses the client device 3000. This assurance level can then be used to determine whether to complete a pending transaction (e.g., such as a financial transaction, an online purchase, accessing confidential information in a user's account, etc.) with a remote relying party 3051 over the network. In one embodiment, the relying party 3051 can specify the assurance level required for a given transaction. For example, for a financial transaction involving a large transfer of funds, the relying party 3051 may require a relatively higher assurance level than, for example, a transaction involving access to a user's email account. Although shown as a single entity, a "relying party" may include a website or other online service equipped with a separate secure transaction server for performing the basic verification techniques described herein.

In one embodiment, the assurance level calculation module 3006 transmits the assurance level (e.g., specified as a value, percentage, code, etc.) to the relying party 3051 without disclosing any confidential user information collected by the client risk assessment agent 3004, thereby protecting the user's privacy. In another embodiment, the assurance level calculation module 3006 knows the assurance level required for the current transaction, determines whether the assurance level is sufficiently high, and transmits an indication to the relying party 3051 as to whether the transaction is approved or denied, again without disclosing the user's private information to the relying party 3051.

In one embodiment, communications between the client device 3000 and the relying party 3051 are secured via a secure communication module 3013, which can encrypt outgoing communications using a first key and decrypt incoming communications using a second key. In symmetric key encryption schemes, the first and second keys are the same. In asymmetric key encryption schemes, the keys are different. However, the underlying principles of the present invention are not limited to any particular type of encryption.

In one embodiment, in addition to the risk data provided by the client risk assessment agent 3004, the assurance level calculation module 3006 determines the assurance level based on the current user authentication results 3005. Specifically, the user authentication results 3005 may include the results of the current or most recent explicit user authentication via one or more explicit user authentication devices 3020-3021. This may include, for example, fingerprint authentication via a fingerprint device, facial recognition authentication via a camera and facial recognition hardware/software, voice recognition via a microphone and voice recognition hardware/software, retinal scanning using a camera and associated hardware/software, password/PIN entry by the end user via a keypad, and/or various other types of explicit user authentication devices and/or technologies.

In one embodiment, secure storage 3025 cryptographically protects the biometric reference data record for each user authentication device 3020-3021 (e.g., wrapping the data with a symmetric key to secure the storage 3025). Although secure storage 3025 is shown as being outside the secure perimeter of the authentication devices 3020-3021, in one embodiment, each authentication device 3020-3021 may have its own integrated secure storage to cryptographically protect the biometric reference data record.

In addition to explicit user authentication, one embodiment of the verification engine 3010 collects data from sensors 3043 for use by the assurance calculation module 3006 in generating assurance levels. For example, the sensors 3043 may include a location sensor (such as a GPS sensor) to indicate the user's current location. If the client device 3000 is in an expected location, such as the user's workplace or residence, this increases the likelihood that the user is a legitimate user. Conversely, if the user is in an unexpected location, such as a foreign country that the user has never visited before, this increases the likelihood that the user is not a legitimate user. Therefore, in one embodiment, the assurance calculation module 3006 will tend to increase the assurance level if the user is in an expected location and decrease the assurance level if the user is in an unexpected location.

Various other sensors 3043, such as temperature sensors, humidity sensors, and accelerometers, can be used to collect data relevant to user authentication. For example, a temperature/humidity sensor can provide the current temperature/humidity, which can be compared to the known temperature/humidity at the location specified by the location sensor. If these values differ significantly, this can indicate that the client device 3000 is being spoofed. The comparison of the claimed location with the temperature/humidity can be performed at a remote server, such as the secure transaction server 4632 described below with respect to Figures 46A and 46B. In another embodiment, an accelerometer on the device can be used to measure the user's gait and compare these measurements to the user's known gait. If the gait matches (within a specified threshold), this increases the likelihood that the legitimate user is in possession of the client device 3000.

As shown in Figure 31, various types of client configuration data relevant to determining risk can be collected and used, including (for example) hardware data 3101, operating system data 3102 and application data 3103. By way of example and not limitation, hardware data 3101 may include client device model, processor name/type, boot ROM version and management controller version. Operating system data 3102 may include current operating system version, OS update date and current boot mode (for example, booting from a hard drive). Application data 3103 may include instructions on whether a firewall is activated, firewall type and version, instructions on whether anti-virus software and current version and updates to virus definition files are installed, instructions on whether anti-virus software is activated (for example, actively monitoring client devices during operation), instructions on the last comprehensive and/or partial virus scan and the results of the most recent virus scan. In addition, application data 3103 or OS data 3102 may include instructions on whether data is stored on a user's persistent storage device (for example, a hard drive, flash memory, etc.) in an encrypted or other secure manner.

As mentioned, in one embodiment, the assurance level calculation module 3006 considers both the risk assessment data provided by the client risk assessment agent 3004 and the user verification results 3005 to derive an assurance level that a legitimate user is attempting the current transaction. By way of example and not limitation, if the client configuration data 3050 indicates that the current client does not have an active firewall or virus detection software, it may report to the assurance level calculation module 3006 that the client presents a higher risk than clients that have these features enabled. Similarly, if the virus detection software has not been updated or executed recently (e.g., within a threshold time period), the client risk assessment agent 3004 may report an increased risk to the assurance level calculation module 3006. Risk levels can be assigned in a variety of ways while still complying with the underlying principles of the present invention. For example, risk levels can be based on a percentage (e.g., 0% = minimum risk, 100% = maximum risk, and all numbers in between represent varying levels of intermediate risk) or a numerical value on a scale (e.g., 1 = minimum risk, 10 = maximum risk, and all numbers in between represent varying levels of intermediate risk).

Regardless of how the risk data is provided, in one embodiment, the assurance level calculation module 3006 determines the required level of authentication based on the risk data provided by the client risk assessment agent 3004. For example, if the client risk assessment indicates a relatively high risk value (e.g., 9 or 10 out of 10), the assurance level calculation module 3006 may require a more reliable and/or explicit user authentication (such as PIN/password entry and/or fingerprint scanning) to authenticate the user for the current transaction. Conversely, if the client risk assessment indicates a relatively low risk (e.g., 1 or 2 out of 10), the assurance level calculation module 3006 may require non-intrusive user authentication for the current transaction, such as location-based authentication and/or reliance on the most recent explicit user authentication for the current transaction.

It should be noted that for simplicity, the data in FIG31 is arranged in a table format. The actual client configuration data 150 can be stored in a variety of different formats, including binary files, hierarchical file system arrangements, linked lists, and OS registry formats. The underlying principles of the present invention are not limited to any particular configuration data format.

As indicated in FIG30 , in one embodiment, the client risk assessment agent 3004 is able to access the client configuration data 3050 through the OS (e.g., by making appropriate calls to an application programming interface (API) exposed by the OS). In another embodiment, the client risk assessment agent 3004 accesses the client configuration data 3050 directly from the underlying file system where the data is stored. In one embodiment, the client risk assessment agent 3004 is able to securely access the underlying configuration data. Various security features may be implemented to ensure the security of the configuration data 3050, such as chain of trust techniques and secure zones.

One consideration in allowing additional risk information to be provided to websites is not to ignore the rationale behind why browsers don't provide this information in the first place. Of course, malicious websites could exploit this information and web browser developers have good reasons to keep it hidden from malicious websites. Therefore, as mentioned, in one embodiment, the base client configuration data 3050 is not provided directly to the relying party 3051. Instead, in one embodiment, the client risk data is evaluated directly on the client device by the client risk assessment agent 3004, and the risk value is provided to the assurance level calculation. The relying party 3051 only needs to know whether the verification was successful (if an assurance level was specified in advance) and/or the current assurance level. This protects the client's configuration data 3050 from being publicly disclosed.

One embodiment of a method for assessing client risk during authentication is shown in Figure 32. The method may be implemented on the architecture shown in Figures 30 to 31, but is not limited to any particular system architecture.

At 3201, client configuration data related to client risk is retrieved. This may include, for example, the presence and current status of a firewall or virus detection software and/or the current version of the operating system (e.g., how recently the OS has been updated). At 3202, the client configuration data is evaluated to determine a risk value for the client (e.g., a percentage, numeric value, or other data capable of specifying a risk level). At 3203, the client risk assessment is used to determine an assurance level. In one embodiment, higher risk values require a higher assurance level (e.g., a risk value of 10 may require an assurance level higher than 90%). In another embodiment, the assurance level itself is calculated based on the assessed risk. For example, as described above, the risk value may be included as one of many variables (including previous or current user authentication) used to determine the current assurance level.

At 3204, an authentication technique is selected that, if successfully completed, will raise the assurance level to an acceptable level for the current transaction. For example, if the risk is high, explicit user authentication may be required. If the risk is low, a previous recent authentication or non-intrusive authentication may be sufficient.

At 3205, a determination is made as to whether the verification is successful. If so, the transaction is permitted at 3208. If not, at 3206, one or more additional verification techniques may be required or the transaction may not be permitted. For example, if the current assurance level is insufficient, the user may be required to enter confidential information previously provided to the relying party 3051, or the user may provide other/additional verification. If, at 3207, it is determined that the additional verification techniques are sufficient, the transaction is permitted at 3208. If not, the transaction is not permitted at 3206.

I. Systems and Methods for Performing Authentication for Local Transactions

Embodiments of the present invention described herein include techniques for authenticating a user for local transactions initiated through a local secure transaction device. For example, a local transaction may be a withdrawal, transfer, or other user-initiated operation, and the secure transaction device may be an ATM or other local device capable of performing financial transactions. Similarly, a local transaction may involve completing a payment for goods or services at a retail store or other retail location equipped with a local secure transaction device.

As shown in FIG33 , in one embodiment, a client device 3300 having a biometric authentication device and associated software authenticates to a relying party 3351 having a secure transaction service over a network to execute a transaction on a local secure transaction device 3350. Specifically, when a user of client device 3300 wishes to execute a transaction locally with secure transaction device 3350, they initiate a series of authentication transactions with relying party 3351 (examples of which are described below). For example, the user may be required to swipe a finger on a fingerprint reader on client device 3300 and/or enter a PIN or other password via the client keypad. The results of the authentication can then be transmitted from client device 3300 to relying party 3351 without transmitting the user's private data (e.g., fingerprint data, PIN, or any other private user data), thereby protecting the user's privacy.

In response to successful authentication, relying party 3351 may transmit a signal to local secure transaction device 3350 to perform an action. For example, if the local secure transaction device is an ATM, the signal may instruct the ATM to dispense a specified amount of cash. If local secure transaction device 3350 is a retail checkout device, an indication of successful payment may be transmitted and the user's account may be debited.

33 , a local secure communication channel can be established between the client device 3300 and the local secure transaction device 3350 to supplement the user verification process. The local secure channel can be established using various wireless communication technologies, such as near field communication (NFC), Bluetooth, or WiFi (e.g., 802.11x channels), using wireless communication interfaces on the client device 3300 and the local secure transaction device 3350. For example, when in proximity to the local secure transaction device 3350, the client device 3300 can perform a near field communication (NFC) handshake with the wireless interface of the local secure transaction device 3350 via its wireless interface and establish a local secure channel to exchange data during verification.

The unique existence of the local secure channel constitutes authentication data because it establishes the current location of the client device 3300. Therefore, relying party 3351 can use this information during the authentication process as evidence of the current location of the client device 3300. In one embodiment, relying party 3351 can compare the location provided by the local secure transaction device 3350 with the current GPS location reported by the client device 3300 to confirm whether the two location values match.

Additionally, relying party 3351 may transmit a password or other authentication data to client device 3300, which may then forward the password or other authentication data to local secure transaction device 3350 via a local secure channel for authentication of the client device. For example, in one embodiment, relying party 3351 transmits a barcode to client device 3300, and the corresponding code is transmitted to the local secure transaction device. Local secure transaction device 3350 may then use a barcode scanner or camera to read the barcode (e.g., from the display of client device 3300) to perform authentication (i.e., compare the code received from the relying party with the code read from the barcode). Alternatively, local secure transaction device 3350 may transmit the code read from the barcode to the relying party, which may then confirm whether the codes match. Conversely, relying party 3351 may transmit a password or other authentication data to local secure transaction device 3350, which may then forward this data to client device 3300 for authentication. Thus, a local secure channel can be used to exchange data for a variety of authentication techniques.

As mentioned, in one specific embodiment, the local secure transaction device 3350 is an ATM device. ATM machines are vulnerable devices because their input/output controls (e.g., card reader, keyboard, screen, camera, etc.) are exposed to the "outside world" and are easily tampered with. For example, debit card records and PINs can be easily stolen using low-tech devices (such as hidden magnetic stripe readers, mirrors, and cameras). In one embodiment, remote verification technology involving communication between the client 3300 and the relying party 3351 is used to provide significantly improved verification for ATM machines. When integrated with this remote verification, the ATM itself does not need to have traditional input/output controls such as a card reader, touch screen, or keyboard. All it needs is a network connection and a slot for dispensing cash. The verification itself can be performed on the customer's client device 3300 equipped with a biometric verification device.

In one embodiment, for a cash withdrawal, the user will approach the ATM machine and initiate a remote verification application to authenticate with the relying party 3351. The user will then enter the withdrawal amount and swipe their finger on the fingerprint sensor of the mobile device (or the user performs any other type of verification as discussed below). When the user's presence and authenticity are confirmed to the relying party 3351, the specified amount of currency is dispensed from the ATM's slot.

This embodiment not only provides stronger authentication, but also transforms complex and expensive ATMs into simple and reliable cash dispensers that are significantly cheaper to build and maintain. These new ATMs can be used for a long time. They do not require frequent updates because all updates to biometric-related authentication functions are introduced directly on the client device 3300 and/or the relying party's secure transaction server 3351.

Additional architectural details of one embodiment of the present invention are shown in Figure 34. As shown, the client device 3300 of this embodiment includes a local authentication application 3304 that communicates with both a local secure transaction device 3350 and a relying party 3351 to coordinate the various local authentication techniques described herein. In one embodiment, the local authentication application 3304 establishes a local secure channel with the local secure transaction device 3350, and the authentication engine 3310 performs remote authentication with the relying party to verify that the legitimate user possesses the client device 3300.

In one embodiment, the verification engine 3310 performs verification by entering into a series of transactions with a relying party's secure transaction server, as described in the co-pending patent application mentioned above. For example, these transactions may include a registration process in which a user registers with a client's biometric device to generate biometric template data (e.g., by swiping a finger, taking a photo, recording a voice, etc.). Registration may be performed under the guidance of the relying party's secure transaction server or may be performed autonomously by the user. The user may then register the biometric device with the secure transaction server over the network and subsequently authenticate to those servers using the data exchanged during the registration process (e.g., an encryption key pre-installed in the biometric device).

In one embodiment, verification engine 3310 includes an assurance level calculation module 3306 for calculating an assurance level corresponding to the likelihood that a legitimate user possesses client device 3300. This assurance level can then be used to determine whether relying party 3351 should authorize a local transaction (e.g., such as a financial transaction, a retail purchase, access to confidential information in a user's account, etc.) at local secure transaction device 3350. In one embodiment, relying party 3351 can specify the assurance level required for a given transaction. For example, for a financial transaction involving a large transfer, relying party 3351 may require a relatively higher assurance level than, for example, a transaction involving access to a user's account.

In one embodiment, assurance level calculation module 3306 transmits the assurance level (e.g., specified as a value, percentage, code, etc.) to relying party 3351 without disclosing any confidential user information, thereby protecting the user's privacy. In another embodiment, assurance level calculation module 3306 knows the assurance level required for the current transaction, determines whether the assurance level is high enough, and transmits an indication to relying party 3351 as to whether the transaction is approved or denied, again without disclosing the user's private information to relying party 3351.

In one embodiment, communications between client device 3300 and relying party 3351 are secured via secure communication module 3313, which can encrypt outgoing communications using a first key and decrypt incoming communications using a second key. In symmetric key encryption schemes, the first and second keys are the same. In asymmetric key encryption schemes, the keys are different. However, the underlying principles of the present invention are not limited to any particular type of encryption.

In one embodiment, the assurance level calculation module 3306 determines the assurance level based at least in part on current user authentication results 3305, which may include results of a current or most recent explicit user authentication via one or more explicit user authentication devices 3320 - 3321. This may include, for example, fingerprint authentication via a fingerprint device, facial recognition authentication via a camera and facial recognition hardware/software, voice recognition via a microphone and voice recognition hardware/software, retinal scanning using a camera and associated hardware/software, password/PIN entry by an end user via a keypad, and/or various other types of explicit user authentication devices and/or techniques.

In one embodiment, secure storage 3325 cryptographically protects the biometric reference data record for each user authentication device 3320-3321 (e.g., wrapping the data with a symmetric key to secure the storage 3325). Although secure storage 3325 is shown as being outside the secure perimeter of the authentication devices 3320-3321, in one embodiment, each authentication device 3320-3321 may have its own integrated secure storage to cryptographically protect the biometric reference data record.

In addition to explicit user authentication, one embodiment of the verification engine 3310 collects data from sensors 3343 for use by the assurance calculation module 3306 in generating assurance levels. For example, the sensors 3343 may include a location sensor (such as a GPS sensor) to indicate the user's current location. If the client device 3300 is in an expected location, such as a known vicinity of the local secure transaction device 3350, this increases the likelihood that the user is a legitimate user. Conversely, if the GPS reading indicates that the user is not in the vicinity of the local secure transaction device 3350, this indicates that the user initiating the transaction is not a legitimate user. Therefore, in one embodiment, the assurance calculation module 3306 will tend to increase the assurance level if the user is in an expected location and decrease the assurance level if the user is in an unexpected location.

Various other sensors 3343, such as temperature sensors, humidity sensors, and accelerometers, can be used to collect data relevant to user authentication. For example, a temperature/humidity sensor can provide the current temperature/humidity, which can be compared to the known temperature/humidity at the location specified by the location sensor. If these values are significantly different, this may indicate that the client device 3300 is being spoofed. The comparison of the claimed location and temperature/humidity can be performed on a remote server, such as a secure transaction server used by relying party 3351. In another embodiment, an accelerometer on the device can be used to measure the user's gait and compare these measurements to the user's known gait. If the gait matches (within a specified threshold), this increases the likelihood that the legitimate user is in possession of the client device 3300.

The local verification application 3304 can be implemented in a variety of ways while still complying with the basic principles of the present invention. For example, in one embodiment, the local verification application 3304 is designed specifically for the relying party 3351. For example, if the relying party is a banking institution (e.g., Wells Fargo), the local verification application 3304 can be an application designed specifically by/for this bank. In another embodiment, the same local verification application 3304 can be shared among multiple relying parties, such as as a general-purpose local verification application. In addition, although shown as a separate logical component in Figure 34, the verification engine 3310 shown in Figure 34 can be integrated within the local verification application 3304. In another embodiment, the local verification application 3304 can be a web browser or an application executed within a web browser environment (e.g., when a user comes into proximity with the local secure transaction device 3350 or connects to a relying party web page to initiate a transaction).

The local verification application 3304 can perform a variety of local functions, depending on the specific implementation required by the relying party. For example, in one embodiment, the local verification application 3304 receives a password (or other verification data) provided by the relying party 3351 and securely transmits the password to the local secure transaction device 3350 for verification (e.g., via a barcode or using other communication technologies as discussed above). Alternatively, in one embodiment, the user can manually enter the password into the local secure transaction device 3350. Similarly, the verification data (such as the password) received by the local secure transaction device 3350 can be forwarded to the local verification application 3304, which then forwards the verification data to the verification engine 3310 and/or the relying party 3351 (e.g., as evidence of the location of the client device 3300).

One embodiment of a method for performing authentication of a client device is shown in Figure 35. The method may be implemented on the architecture shown in Figures 33-34, but is not limited to any particular system architecture.

At 3501, the client enters the vicinity of a local secure transaction device (e.g., an ATM), and at 3502, establishes a secure connection with the local secure transaction device via a local channel. As mentioned, the local channel can be implemented using near-field communication, Bluetooth, Wi-Fi, or any other type of protocol supported by both the client device and the local secure transaction device. In some embodiments, operation 3502 may not be required. For example, if the client device can authenticate to the relying party with a high level of assurance that the client device is in the possession of the legitimate user, and if the client device can authenticate its current location to the relying party, then the local channel may not be necessary.

At 3503, the client device authenticates to the relying party via the network. Any available technique for generating a level of assurance that a legitimate user possesses the device may be used for this operation. For example, the user may perform explicit authentication by swiping a finger on a biometric fingerprint device, capturing a facial image for facial recognition, and/or entering a password. Alternatively, non-intrusive authentication techniques may be performed, such as determining whether the user has recently (e.g., within a specified time period) explicitly authenticated to the client device and/or using sensor data, such as location data, temperature/pressure data, and/or accelerometer data.

Regardless of how the assurance level is generated, the results of the verification can be provided to a relying party via a network in a manner that protects user privacy (e.g., without providing data that specifically identifies the client device). For example, as previously mentioned, the assurance level itself and/or an indication of the success or failure of the verification can be provided to the relying party without disclosing any confidential user information.

If verification is determined to be successful at 3504, the local transaction is permitted at 3507. In one embodiment, this involves the relying party transmitting a signal instructing the local secure transaction device to perform one or more operations. For example, if the local secure transaction device is an ATM, the operations may include dispensing a user-specified amount of cash. If the local secure transaction device is a debit device (e.g., at a retail store or other location where the user is making a purchase), the signal transmitted by the relying party may confirm payment for the transaction (and debit the user's account accordingly). It should be noted that these are merely illustrative examples. Various alternative applications may be employed while still complying with the underlying principles of the present invention.

If the authentication at 3504 is unsuccessful (e.g., because an acceptable assurance level is not reached), the transaction is denied and/or one or more additional authentication techniques may be required at 3505. For example, the user may be required to provide additional authentication using one or more additional techniques (e.g., enter a password if the initial authentication was a fingerprint, etc.). If it is determined at 3506 that the additional techniques are sufficient, the transaction is permitted at 3507. If not, the transaction is denied again and/or the additional authentication techniques are attempted.

J. User Confirmation for Online Transactions

In many scenarios, completing a transaction with a relying party may require approval from one or more other users. By way of example and not limitation, a parent may want to approve a financial transaction initiated by a child, a commander may want to approve a transaction initiated by a soldier, an administrator may want to approve a business transaction initiated by an employee, and a cryptographic key management system may require multiple users to approve a particular transaction before it can proceed.

One embodiment of the present invention uses the techniques described herein to provide strong user authentication over a network, thereby enabling multi-user confirmation applications. An example of this is shown in FIG36 , which illustrates a client device 3600 with remote authentication capabilities, controlled by a user attempting to initiate a transaction with a relying party 3650 (hereinafter referred to as a "relying party") having a secure transaction service. In one embodiment, the user of client device 3600 authenticates to relying party 3650 using one or more remote authentication techniques described herein (e.g., providing biometric input, such as swiping a finger on a fingerprint sensor, entering a PIN or password, etc.).

In the illustrated embodiment, the other client devices 3601-3602 have users registered with the relying party as “approver” of the user of client device 3600. Thus, for certain types of transactions (e.g., financial transactions involving amounts exceeding a specified threshold), the relying party may require approval from the users of client devices 3601-3602. As discussed below, the remote verification techniques described herein are used as part of the approval process.

In one embodiment, in response to successful authentication of the user of client device 3600, notification generation logic at relying party 3650 sends a notification to other client devices 3601-3602 that have users registered as "approver," indicating that the user of client device 3600 is attempting to complete a transaction. Notifications can be sent in a variety of ways based on the underlying principles of the present invention. For example, if client devices 3601-3602 are mobile devices, push notifications can be sent to client devices 3601-3602. Alternatively, or in addition, notifications can be sent via email, text message (e.g., SMS), instant message, or any other technology capable of delivering messages to client devices 3601-3602.

In one embodiment, the notification includes details of the transaction being attempted by the user of client device 3600. For example, if the transaction is a financial transaction, the notification may include the specific amount being processed and the type of financial transaction being performed (e.g., a withdrawal, an account transfer, etc.). Alternatively, the notification may include a link (such as a hyperlink or other type of pointer) that directs the user of client device 3601-3602 to an approval service on the relying party. Upon selecting the link, the details of the transaction may be provided to the user of client device 3601-3602 (e.g., in a web page or other useful format for providing information).

In one embodiment, after responding to the notification and reviewing the details of the transaction, the user of client device 3601-3602 may confirm the request by performing remote authentication with the relying party (e.g., using the multi-factor authentication techniques described herein) and indicating approval of the transaction.

FIG37 illustrates additional architectural details of client devices 3600-3602 employed in one embodiment of the present invention. Specifically, client devices 3600-3602 of this embodiment include a secure transaction application 3704, which is used to communicate with relying party 3650 and coordinate the transaction approval techniques described herein. Secure transaction application 3704 can be a standalone application that interfaces with verification engine 3710 via a secure application programming interface (API). Alternatively, secure transaction application 3704 can be implemented as a mobile device application or a web browser plug-in.

In addition to coordinating the user confirmation process described herein, in one embodiment, secure transaction application 3704 also ensures that the text displayed to each user is the actual text related to the transaction. For example, application 3704 may display the text within a secure window and request verification from the user to confirm the transaction. The application may start a timer and periodically verify the contents of the current window being displayed to the user (e.g., by generating a signature on the content). The verification period may be randomly selected. Thus, the application continuously ensures that each user sees valid transaction details within the window (thereby ensuring that the transaction text has not been modified by a "man-in-the-middle" attack). If the application detects that the content has been tampered with, it prevents the generation of a confirmation for the transaction.

In one embodiment, after the user provides valid authentication (e.g., swiping a finger on a fingerprint sensor), the client device identifies the user and generates a token (cryptographic signature) with the transaction details (e.g., displayed text) and a random challenge provided by the relying party (e.g., the token can be a signature of the transaction details and a random number). This allows the relying party 3650 to ensure that the transaction details have not been modified between the server and the client. In one embodiment, the application 3704 sends the generated token and username to the relying party, which then uses the username to identify the user and verify the token. If the authentication is successful, a confirmation message is sent to the client and the transaction is processed.

The above techniques may be implemented for transaction requests/confirmations originating from client device 3600 as well as for approval transactions originating from users of client devices 3601 - 3602 .

Returning to FIG37 , in one embodiment, authentication may be performed via an authentication engine 3710 on client devices 3600-3602, which is designed to execute a series of transactions with relying parties 3650 to remotely authenticate each user. For example, as described in the co-pending applications, an authentication framework and associated authentication techniques may be employed, wherein a user registers with a client's biometric device 3720-3721 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 relying parties 3650 (e.g., a website equipped with a secure transaction service or other relying party) via a network; and subsequently authenticates to those relying parties 3650 using data exchanged during the registration process (e.g., an encryption key pre-set to the biometric device). In one embodiment, "registering" with a relying party includes exchanging symmetric or asymmetric keys with the relying party for each user authentication device 3720-3721 and storing the keys in a secure storage device 3725 associated with each authentication device 3720-3721. 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.

During the authentication phase, keys are used, for example, to generate signatures, verify signatures, and/or encrypt communications between clients 3600-3602 and relying party 3650. Once authenticated, the user is permitted to perform one or more online transactions. In addition, in one embodiment, sensitive information (such as fingerprint data and other data that can uniquely identify the user) can be stored locally on the user's client device (e.g., smartphone, laptop, etc.) to protect the user's privacy.

In one embodiment, verification engine 110 includes an assurance level calculation module 3706 for calculating an assurance level corresponding to the likelihood that a legitimate user possesses client device 100. It can then use this assurance level to determine whether relying party 3650 should authorize the current transaction. In one embodiment, relying party 3650 can specify the assurance level required for a given transaction. For example, for financial transactions involving large transfers, relying party 3650 may require a relatively higher assurance level than, for example, transactions that do not involve currency exchange or merely access to user information.

In one embodiment, the assurance level calculation module 106 transmits the assurance level (e.g., specified as a value, percentage, code, etc.) to the relying party 3650 without disclosing any confidential user information, thereby protecting the user's privacy. In another embodiment, the assurance level calculation module 3706 knows the assurance level required for the current transaction, determines whether the assurance level is high enough, and transmits an indication to the relying party 3650 as to whether the transaction is approved or denied (without disclosing the user's private information to the relying party 3650).

In one embodiment, communications between client devices 3600-3602 and relying party 3650 are secured via secure communication module 3713, which can encrypt outgoing communications using a first key and decrypt incoming communications using a second key. In symmetric key encryption schemes, the first and second keys are the same. In asymmetric key encryption schemes, the keys are different. However, the underlying principles of the present invention are not limited to any particular type of encryption.

In one embodiment, the assurance level calculation module 3706 determines the assurance level based at least in part on current user authentication results 3705, which may include results of a current or most recent explicit user authentication via one or more explicit user authentication devices 3720-3721. This may include, for example, fingerprint authentication via a fingerprint device, facial recognition authentication via a camera and facial recognition hardware/software, voice recognition via a microphone and voice recognition hardware/software, retinal scanning using a camera and associated hardware/software, password/PIN entry by an end user via a keypad, and/or various other types of explicit user authentication devices and/or techniques.

In one embodiment, secure storage 3725 cryptographically protects the biometric reference data record for each user authentication device 3720-3721 (e.g., wrapping the data with a symmetric key to secure the storage 3725). Although secure storage 3725 is shown as being outside the secure perimeter of the authentication devices 3720-3721, in one embodiment, each authentication device 3720-3721 may have its own integrated secure storage to cryptographically protect the biometric reference data record.

In addition to explicit user authentication, one embodiment of the authentication engine 3710 performs non-intrusive authentication by collecting data from sensors 3743 for use by the assurance calculation module 3706 in generating assurance levels. For example, the sensors 3743 may include a location sensor (such as a GPS sensor) to indicate the user's current location. If the client device 3600 to 3602 is in an expected location, such as a known vicinity (e.g., a "home" or "office" location), this increases the likelihood that the user is a legitimate user. Conversely, if the GPS reading indicates that the user is not in the expected location, this indicates that the user initiating the transaction is not a legitimate user. Therefore, in one embodiment, the assurance calculation module 3706 will increase the assurance level if the user is in the expected location and decrease the assurance level if the user is in an unexpected location.

Various other sensors 3743, such as temperature sensors, humidity sensors, and accelerometers, can be used to collect data relevant to user authentication. For example, a temperature/humidity sensor can provide the current temperature/humidity, which can be compared to the known temperature/humidity at the location specified by the location sensor. If these values are significantly different, this can indicate that the client device 3600 to 3602 is being spoofed. The comparison of the claimed location and temperature/humidity can be performed on a remote server, such as a secure transaction server used by relying party 3650. In another embodiment, an accelerometer on the device can be used to measure the user's gait and compare these measurements to the user's known gait. If the gait matches (within a specified threshold), this increases the likelihood that the legitimate user is in possession of the client device 3600 to 3602.

Another non-intrusive authentication technique involves measuring the amount of time that has passed since the last successful user authentication. For example, if the user has recently performed an explicit user authentication (e.g., swiping a finger across a fingerprint reader just a few minutes ago), this will often indicate that the legitimate user still possesses the client device (thereby resulting in a high baseline assurance level). Conversely, if the last explicit authentication was several hours or days ago, a new explicit user authentication may be required to achieve an acceptable assurance level.

FIG38 illustrates a method according to one embodiment of the present invention. At 3801, a user of a client triggers a transaction that requires confirmation by N other users. For example, the user's account at a relying party may indicate that certain types of transactions (or all transactions) initiated by the user require confirmation by one or more other users. For example, the user's account may identify the user as a minor, thereby requiring authorization from one or more parents or guardians. At 3801, the user is also authenticated by implementing one or more authentication techniques described herein.

At 3802, the server selects N other users who must confirm the transaction triggered by the user. For example, upon detecting that a user has initiated a transaction, the relying party may query its user database to determine that the transaction requires confirmation and the identities of the users who can confirm the transaction. In one embodiment, a subset of all users who can confirm the transaction may actually confirm the transaction. For example, in one embodiment, if the user is a minor with two parents, notifications may be sent to both parents, but confirmation by either parent will allow the transaction to proceed. Similarly, there may be 10 users authorized to confirm a business transaction, but only confirmation from two of them is required to allow the transaction to proceed.

In one embodiment, a push notification can be sent to the client devices of those users who are able to confirm the transaction (e.g., if the user has a client device capable of receiving push notifications). Alternatively, or in addition, the notification can be sent via email, text message (e.g., SMS), instant message, or any other technology capable of delivering a message to a client device. In one embodiment, a user can be registered with the server to receive confirmation messages via two or more communication channels. For example, a user can receive both a push notification and an email containing a confirmation request.

Regardless of how the confirmation request is sent, at 3803, all or a subset of the N users authenticate to the server in the confirmation process. Any remote authentication technique can be used to authenticate the user and confirm the transaction. For example, the user can confirm the transaction by providing biometric data (e.g., swiping a finger on a fingerprint scanner) to a biometric device on a client that has previously registered with the relying party. As described above, details associated with the transaction can be provided to the user via a secure transaction application that can securely display text and other information (i.e., ensuring that when the user confirms the transaction, he/she has viewed the actual, unaltered text describing the transaction).

Once it is determined at 3804 that a minimum specified number of users have confirmed the request, the transaction is permitted at 3807. One embodiment of the method starts a confirmation timer to measure the amount of time that has elapsed since the confirmation request was sent. Once it is determined at 3805 that the confirmation timer has reached a threshold (e.g., a number of hours, a day, etc.), the transaction is not permitted at 3806. The method waits at 3804 for a minimum specified number of users to confirm the request until the timer threshold is reached.

K. Systems and Methods for Delegating Trust

Existing authentication systems don't allow for the use of registered authenticators on trusted clients to enable new authenticators. For example, if a user has a fingerprint sensor on their phone that they've already registered with multiple websites, and then they install a voice authenticator on their phone, they can't automatically register their voice authenticator with all the websites where they registered their fingerprint sensor. Instead, in this case, the user must step through the same registration and enrollment process to register their voice authenticator with the relying party. Similarly, if the user purchases a new device with a new set of authenticators, they must re-register and re-enroll all the new authenticators with the server.

The embodiments of the present invention described below allow a user to easily use a trusted client device that has already been enabled and registered with one or more relying parties to enable and register an authenticator on a new client device. Specifically, these embodiments can be used to enable a new authenticator, enable a new client device, and keep registrations synchronized across multiple client devices.

Figure 39 provides a high-level overview of trust delegation according to one embodiment of the present invention. A trusted device 3902 (i.e., a device having a validator registered with one or more relying parties 3950) establishes a secure connection with a user's new client device 3900. The specific manner in which the secure connection is established is not relevant to the underlying principles of the present invention. Various technologies may be used, such as near field communication (NFC), Bluetooth, Wifi Direct, using Quick Response (QR) codes, and establishing an HTTPS connection. In one embodiment, the devices may exchange a large random token (LRT) required for the secure connection and may establish a connection by providing the captured LRT to an online service and bootstrapping secure communications via the service.

In one embodiment, once a secure connection is established between the trusted client device 3902 and the new client device 3900, a secure protocol (described in detail below) is implemented to transfer and integrate the registration data from the trusted device to the new device. Once the registration content has been transferred, another secure protocol (e.g., HTTPS in one embodiment) is implemented between the new client device 3900 and the relying party 3950 to verify the registration content.

Although the embodiments described herein focus on transmitting authentication data for authentication transactions with relying parties 3950, a relying party may not be required in order to be consistent with the underlying principles of the present invention. For example, trusted device 3902 may establish a secure connection to provide authentication data to new client device 3900 without involving any relying parties in the system (e.g., to provide authentication data for local authentication to new client device 3900).

As shown in Figure 40, trust delegation modules 4000 to 4001 can be executed on the new device 3900 and the trusted device 3902 respectively to establish a secure connection, exchange registration content, and verify the registration content to the secure transaction service 4004 on each relying party 3950. As used herein, a "trusted authenticator" is an authenticator that a user has registered with one or more relying parties. A "new authenticator" is an authenticator that the user wishes to enable using all relying party registration content currently used for the trusted authenticator. Therefore, if the verification engine 3711 has previously registered one or more user verification devices 3720 to 3721 with the relying party, then the verification engine is considered a trusted authenticator. The goal of one embodiment is to convert the verification engine 3710 of the new device 3900 from a new authenticator to a trusted authenticator. A "trusted device" is a device with a trusted authenticator, and a "new device" is a device with a new authenticator.

Trust delegation is the process of enabling a new authenticator using a trusted authenticator. Therefore, the prerequisites for trust delegation are: the user has a trusted device; the user has a new device; and the user wants to delegate trust from the trusted device to the new device.

Returning to Figure 40, in one embodiment, the user initiates a trust delegation application 4000 on the new client device 3900 and a trust delegation application 4001 on the trusted client device to establish an initial secure connection. In one embodiment, the trust delegation application may be a mobile device application that is specifically designed to perform the trust delegation operations described herein. In another embodiment, the trust delegation application may be a browser plug-in that is executed in response to the user indicating that he/she wishes to perform trust delegation (e.g., via a web page with embedded Javascript or other applet or executable program code). In addition, the trust delegation applications 4000 to 4001 may be software modules within a larger application (such as a verification application designed to manage verification to a relying party). However, it should be noted that the underlying principles of the present invention are not limited to any particular implementation of the trust delegation applications 4000 to 4001.

In one embodiment, to approve the trust delegation operation on the trusted device 3902, the user locally authenticates to the authentication engine 3711 on the trusted device (e.g., by providing biometric input to the user authentication devices 3722-3723). Similarly, in one embodiment, the user may locally authenticate to the authentication engine 3710 on the new client device 3900. These two authentication steps may provide authorization for the trust delegation applications 4000-4001 to perform the delegation process.

As mentioned, the trust delegation applications 4000-4001 may utilize any communication interface available on their respective client devices 3900, 3902 to establish a secure connection (eg, a Bluetooth interface for a Bluetooth connection, an NFC interface for an NFC connection, etc.).

Once the secure connection is established, in one embodiment, the trust delegation application 4001 of the trusted client 3902 provides data indicating the number of keys (N) on the trusted client that are registered with the relying party. In response, in one embodiment, the trust delegation application 4000 generates N new device key pairs (ND_Uauth), each comprising a private key (ND_Uauth.priv) and a public key (ND_Uauth.pub), and sends the N new device public keys to the trust delegation application 4001 on the trusted device 3902.

In one embodiment, the trust delegation application 4001 then signs each of the N new device public keys with the corresponding trusted device private key (TD_Uauth.priv) to generate a signature (TD_Uauth.sig) associated with each of the N new device public keys. In one embodiment, the "corresponding" private key is the private key associated with a specific registration with the corresponding relying party. The trust delegation application 4001 may also insert a timestamp into the generated signature, which can then be used by the relying party to verify the exact time when the trust delegation occurred. In one embodiment, the trust delegation application 4001 of the trusted client 3902 then transmits each generated signature and other registration data associated with each relying party to the trust delegation application 4000 on the new client 3900. The data for each relying party may include: one or more relying party ID codes (e.g., an application ID code identifying a service at the relying party), a username registered for the user at the relying party, a key ID code used by the relying party to locate the appropriate key during authentication, and any other data relevant to the authentication process.

In one embodiment, once the trust delegation application 4000 receives the signature and other registration data, it integrates this data into the local secure storage 3725 so that it can be used later when the new client device 3900 connects to the relying party 3950.

In one embodiment, after the registration data has been stored in the local secure storage device 3725, the trust delegation application 4000 can perform a series of bootstrapping operations to utilize the delegated registration on the new client device 3900 with the relying party (e.g., website, service, etc.) that has previously registered with the trusted client device 3902. Alternatively, the described bootstrapping operations can be performed by the verification engine 3710 itself (via direct communication with the secure transaction service 4004, as shown in Figure 40). Regardless of which specific software component on the new client device 3900 performs these operations, the basic principles of the invention remain unchanged.

Specifically, in one embodiment, secure transaction service 4004 of relying party 3950 detects the presence of registered content on new client device 3900 that uses a remote authentication protocol supported by secure transaction service 4002 and trust delegation application 4000. In one embodiment, secure transaction service 4004 may initially require the user to perform biometric authentication or other form of authentication (e.g., entering a security code) from new client device 3900. Additionally, at this stage, secure transaction service 4004 may verify the timestamp inserted into the signature and ensure that the timestamp is no older than a threshold amount of time.

Assuming the user successfully provides biometric or other authentication data with an acceptable level of assurance, the trust delegation application 4000 and/or the new authenticator 3710 prepares a response that includes the following three assertions:

1. Verification of the new device public key (ND_Uauth.pub) associated with the relying party. In one embodiment, the verification includes a signature generated on the public key (eg, using the relying party's public key).

2. An assertion using the new device private key (ND_Uauth.priv) associated with the relying party. In one embodiment, to generate this assertion, the private key is used to generate a signature on content known to the relying party (e.g., such as a random challenge sent from the relying party). Because the relying party was provided with the public key (in step 1), the relying party can decrypt the content, thereby verifying that the private key was used to encrypt the content.

3. A signature (TD_Uauth.sig) previously generated by the trusted client device and associated with the new device public key for that particular relying party, and a key ID (TD_Uauth.keyid) used by the relying party to locate the public key (e.g., so that it can use that key ID to query its secure transaction database 4025 to retrieve the public key).

In one embodiment, all of the above data is then transmitted to the relying party's secure transaction service 4004 in a remote verification response.

In one embodiment, after receiving the above assertion, the secure transaction service 4004 may perform the following verification:

1. Use the key ID to locate the public key of the trusted device (TD_Uauth.pub);

2. Use the public key of the trusted device (TD_Uauth.pub) to verify the signature generated by the trusted device (TD_Uauth.sig);

3. Use the device's public key (ND_Uauth.pub) to verify the signature (ND_Uauth.sig) generated by the new device's private key; and

4. Verify the confirmation of the new device public key (ND_Uauth.pub) associated with the relying party. In one embodiment, this verification is performed using the relying party's private key.

One embodiment of a method for securely transferring registration data from a trusted device to a new device is shown in Figure 41, and one embodiment of a method for verifying registration data to a relying party is shown in Figure 42. Although these methods may be implemented within the context of the system architecture shown in Figures 39-40, the underlying principles of the invention are not limited to any particular system architecture.

41 , at 4101, the new device establishes a secure communication channel with the trusted device and determines the number of key pairs to generate (N). As mentioned, this may be the number of key pairs that the trusted device has registered with the relying party.

At 4102, the new device generates N new public/private key pairs. In an alternative implementation utilizing symmetric keys, the new device can generate a single (symmetric) key to be shared with the relying party. At 4103, the N public keys are sent to the trusted device, and at 4104, the trusted device signs each public key with the corresponding private key to generate a signature. At 4105, the signature is sent to the new device along with other registration data for the relying party (e.g., key ID, application ID, etc.). Finally, at 4106, all registration data and signatures are integrated into a local secure database used by the verification engine.

Now turning to Figure 42, at 4201, the new client (having performed the delegation operation of Figure 41) establishes a secure connection with the relying party. At 4202, the relying party detects that there is an existing registration content that has been delegated to the new device. In response, at 4203, the relying party issues a verification request to the new device. The user can then use one or more biometrics or other verification techniques for verification. As discussed above, at 4204, the new device prepares a response, which includes a confirmation of the new device's public key, a signature generated with the new device's private key (e.g., on a challenge), and a signature generated with the private key of the trusted device and the associated key ID. At 4205, all data in the response is transmitted to the relying party, and at 4206, the relying party verifies the data contained in the response (see above for details of one embodiment). If the verification is successful, then at 4207, the transaction the user is attempting is approved.

The techniques described herein can be used to delegate trust between two authenticators on different devices (as described above). Additionally, in one embodiment, these techniques can be used to delegate trust between two authenticators on the same device. In this case, a secure connection between the two devices does not need to be established, but all other operations can be performed between the two authenticators within the device.

Furthermore, it should be noted that some of the operations described can be implemented in various ways. For example, the security protocol for delegated trust can be initiated by the trusted device rather than the new device. In either case, the new device (or, more specifically, the authenticator on the new device) can generate multiple new key pairs (ND_Uauth), and the authenticator on the trusted device can sign the public keys of these key pairs.

L. Systems and methods for privacy-enhanced data synchronization

Current systems exist for synchronizing data between multiple client devices using cloud services. When a user creates a new document on a device (e.g., takes a photo, creates a word processing document, etc.) or modifies an existing document, the cloud service to which the user subscribes will typically store a copy of the new/modified document "in the cloud." When the user accesses the cloud service from a second device (e.g., a computer at work or another device used by a different family member), the cloud service can be configured to synchronize that device.

One problem is that data is often stored in an unencrypted format within cloud services, making it vulnerable to various types of cyberattacks and inquiries by federal agencies.

The embodiments of the present invention described below provide a set of protocols and technologies that allow data to be synchronized between devices in a privacy-enhancing manner. By using these protocols and technologies, cloud services no longer have access to data in plain text (e.g., unencrypted format), thereby protecting the user's privacy.

First, it should be noted that the techniques described below for synchronizing data between devices do not rely on the advanced authentication techniques described herein. For example, these synchronization techniques can be employed outside the context of remote user authentication systems as described with respect to other embodiments of the present invention. However, these synchronization techniques can be used to perform synchronization for these remote user authentication embodiments. For example, in one embodiment, these synchronization techniques can be used to synchronize registration data for each website or other online service visited by a user across multiple devices.

As used herein, "circle" means a network of devices trusted by a user, and "circle id" means an identifier that identifies a circle (e.g., an identifier that cannot be easily guessed). "Circle cloud" means an online service that stores information about circles and trust chains (defined below) and acts as a communication hub for client devices. In one embodiment, the circle cloud does not store any confidential data (at least not in unencrypted format). The term "d.pub" refers to the public key of a device, "d.priv" refers to the private key of a device, and d.pub/d.priv refers to the asymmetric public/private key pair of device d. In one embodiment, d.priv never leaves device d. "Trust chain" means persistent data stored on the circle cloud that contains information about the devices trusted by the user and their relationships. "Circle channel" means a secure communication channel provided by the circle cloud that is used by two (or more) devices to exchange and synchronize data between them.

One embodiment of the present invention includes protocols and associated technologies for allowing new user devices to (a) join a circle and (b) subsequently synchronize with the circle. These embodiments will be described in conjunction with FIG43, which shows three client devices 4301 through 4303, each having a privacy synchronization application 4311 through 4313 for implementing the protocols and technologies described herein, and secure data storage devices 4321 through 4332 for storing data used for joining and synchronization. Device 4301 is sometimes referred to herein as device d1, device 4302 is sometimes referred to herein as device d2, and device 4303 is sometimes referred to herein as device d3.

In one embodiment, joining and synchronization are performed via a circle cloud 4350 comprising multiple storage servers. A trust chain 4360 within the circle cloud 4350 maintains data defining trust relationships between devices 4301 to 4303, as described below. A circle channel 4370 comprises a secure communication channel provided by the circle cloud that is used by two or more devices to exchange and synchronize data.

a. Join the circle

Device 4302 (d2) joins an existing network (i.e., a "circle" of trusted devices) consisting of devices 4301 (d1) and 4303 (d3) belonging to the user. Device 4302 can only join that circle if another device 4301 that is already part of the existing circle authorizes it.

One embodiment of a method for authorizing a new device 4302 using a trusted device 4301 is shown in Figure 44. At 4401, a user authorizes a new device 4302 on an existing trusted device 4301. For example, in one embodiment, the user may initiate a privacy sync application 4311 on the trusted device 4301 and a privacy sync application 4312 on the new client device 4302.

At 4402, in one embodiment, the privacy sync applications 4311-4312 cause the devices 4301-4302 to establish a secure connection. The secure connection may be established using various technologies, such as near field communication (NFC), Bluetooth, Wifi Direct, using a Quick Response (QR) code, and establishing an HTTPS connection.

At 4403, device 4301 sends secure data, referred to herein as "join1_data," to new device 4302. In one embodiment, join1_data includes the following fields: {d1.pub, sk.sym, circle-id}, where d1.pub is the public key of device 4301, sk.sym is a randomly generated session key generated by device 4301, and circle-id is a unique identification code that identifies the circle that device 4302 is joining.

At 4404, the device 4302 reads the join1_data and prepares a response, which may include the following:

HMAC(sk.sym, d2.pub|T)|d2.pub|T, where T is the timestamp

·trust-block1=S(d2.priv, d1.pub)|d1.pub|d2.pub

Note that HMAC stands for Hash-based Message Authentication Code. In the above embodiment, the HMAC is generated by concatenating the public key of device 4302 with a timestamp using an HMAC or similar algorithm and protecting the integrity of the result with sk.sym. In addition, trust-block 1 includes a signature generated over the public key of device 4301 using the private key of device 4302. In one embodiment, the trust-block 1 entry also includes a timestamp (T).

44 , at 4405 , device 4302 securely connects to circle cloud 4350 and transmits a response including HMAC and trust-block 1. Circle cloud 4350 stores the data received by device 4301 and waits for device 4301 to connect.

At 4406, device 4301 connects to the circle cloud using the circle id, verifies the integrity of the data contained in the response of device 4302 in operation 4405, and generates trust-block2. Specifically, in one embodiment, device 4301 uses sk.sym to read and verify the integrity of d2.pub and T (for example, decrypts d2.pub and T using sk.sym). Device 4301 then signs d2.pub using its own private key d1.priv and generates trust-block2 = S(d1.priv, d2.pub) | d2.pub | d1.pub, which includes the signature generated on d2.pub using d1priv. In one embodiment, trust-block2 also includes a timestamp (T). Device 4301 then sends the above data including trust-block2 to circle cloud 4350.

At 4407, circle cloud 4350 adds these two trust blocks to trust chain 4360. In one embodiment, after the above operations, device 4302 joins the circle associated with the circle ID. All devices 4301 and 4303 in this circle trust device 4302, and device 4302 trusts all of these devices. Note that any trusted device can authorize a new device using the techniques described herein.

b. Synchronize with circles

During this process, devices 4301-4303 belonging to the same circle synchronize data between themselves. Various application-specific sub-protocols may be implemented following this process. For example, an online cloud storage application may want to keep a user's data synchronized across all devices and retain an encrypted copy on the circle's cloud. Another application may broadcast a message to devices in the circle. For example, in one embodiment, registration data used by one device to authenticate with a remote relying party may be synchronized across all devices in the circle. Various other applications and sub-protocols may be implemented while still adhering to the basic principles of the present invention. All such sub-protocols may utilize the basic process blocks described below.

Chain of Trust

As shown in the "Join a Circle" process (Figure 44), what enters trust chain 4360 is evidence asserting that device 2 is trusted by device 1. Therefore, trust chain 4360 is a series of authorization blocks, each of which asserts a trust relationship between two devices. In one embodiment, the trust chain is commutative, meaning that if device 4301 trusts device 4302, then device 4302 trusts device 4301. If there is a block asserting that device 4301 trusts device 4302 but no block asserting that device 4302 trusts device 4301, then trust chain 4360 is considered broken. In one embodiment, trust chain 4360 is also transitive, meaning that if device 4301 trusts device 4302 and device 4302 trusts device 4303, then device 4301 trusts device 4303. In one embodiment, the trust chain is circle ID-specific and does not contain any confidential information about the devices.

In one embodiment, the trust chain 4360 includes multiple trust blocks and each block includes the following data: {di.pub, dj.pub, S(di.priv, dj.pub), S(dj.priv, di.pub)} - that is, the public key of each device, and the signature generated on the public key of each other device using the private key of each device.

The above assertion means that device di trusts device dj and vice versa. In one embodiment, devices 4301 to 4302 use trust chain 4360 to determine and verify which devices are in the circle. After the devices verify that they are in the same circle, they can use circle channel 4370 to synchronize encrypted data between them.

In one embodiment, to determine whether device di is in the same circle as device dj, the following operations are performed: (a) a directed graph is constructed in which each node is a device in the trust chain and each arrow corresponds to a block in the trust chain, and (b) a determination is made as to whether there is a direct path connecting di and dj.

Circle Channel

In one embodiment, the process shown in FIG45 is implemented to synchronize data between other devices in the same circle. In the illustrated example, device 4301 (d1) is a device that has new data and wants to send it to other devices. At 4501, device 4301 downloads the trust chain 4360 associated with the circle ID, identifies other devices in the same circle (e.g., devices 4302 to 4303) from the trust chain, and uses the trust chain to obtain the public keys of the other devices in the same circle.

At 4502, device 4301 generates a random encryption key (REK) (e.g., using known random number generation techniques). At 4503, device 4301 derives a two-way session key (SK) for each other device in the circle. In one embodiment, device 4301 derives the SK with respect to each other device using the Diffie-Hellman key exchange algorithm. Diffie-Hellman is a well-known algorithm that allows two parties that are not previously aware of each other to jointly establish a shared secret key. In this case, for example, if a first device has a key pair and provides its public key to a second device, the second device can independently use its private key and the public key of the first device to automatically derive a new key (SK in this application) (and vice versa). In one embodiment, device 4301 uses these techniques to generate a different SK for each other device 4302, 4303.

At 4504, device 4301 encrypts REK with each derived SK for each device and binds the appropriate public key to it. For example, for device d1, which generates SKi and SKj for devices di and dj respectively, it uses the session key to encrypt REK as follows:

{d1.pub, di.pub, E(SKi, REK)} (for device di)

{d1.pub, dj.pub, E(SKj, REK)} (for device dj)

At the end of this process, each of devices di and dj is able to decrypt REK using its respective session key (which has been independently derived by each device using Diffie-Hellman, as discussed above).

At 4505, the device 4301 encrypts the data to be synchronized with the REK, i.e., E(REK, data-to-be-synced). As mentioned, any data can be synchronized in this manner, such as multimedia files, productivity documents, and/or client configuration data (e.g., relying party registration data, as discussed above), etc.

At 4507, the device 4301 provides the circle channel with the REK encrypted with each SK and the data to be synchronized encrypted with the REK:

[{d1.pub, di.pub, E(SKi, REK)}, {d1.pub, dj.pub, E(SKj, REK)},...]

E(REK, data-to-be-synced)

After the data has been provided to the circle channel, at 4506, each device in the same circle downloads the record corresponding to its public key (e.g., {d1.pub, di.pub, E(SKi, REK)} for device di), derives the same SK (e.g., SKi), decrypts REK, and uses REK to decrypt the data to be synchronized.

In one embodiment, the "join circle" operation described above may require user authentication of both device 1 and device 2. When implementing the protocol using the remote authentication techniques described herein, the user may be required to authenticate both devices by, for example, "swiping" a finger to initiate and complete the "join circle" process. In contrast, in one embodiment, synchronizing data between devices as described may not require user authentication.

The protocols and associated technologies described herein allow for the construction of a network of mutually trusting devices. Notably, all data transmitted to, from, and stored in the cloud is encrypted. This allows for data to be synchronized between multiple devices without storing any confidential data in the cloud, improving user privacy.

The embodiments of the present invention described above implement a private synchronization protocol to achieve device synchronization, wherein participating cloud storage devices cannot view any user data in plain text (i.e., the data is encrypted in the cloud). These embodiments include various novel and beneficial features, including but not limited to:

• A system and method for implementing a device synchronization protocol in which devices have public and private keys for authorizing other devices.

• A system and method for implementing a chain of trust to indicate trust relationships between devices within the same circle.

• A system and method in which devices use a Diffie-Hellman or similar key exchange algorithm to generate two-way session keys and encrypt data with those keys.

• A system and method where a hash of the circle id is stored in the circle cloud rather than on the device itself.

• A system and method in which the circle cloud uses a challenge-response protocol to authenticate a device before allowing it to put any data into the circle's circle channel.

• A system and method in which a persistent circle group key is used to encrypt synchronized data.

• An application that uses the described proprietary synchronization protocol to share a user's data (documents, files, photos, etc.) between multiple devices and store encrypted backups of the data on the cloud.

• A system and method where a device's private key (d.priv) and all operations using this key are implemented inside an authenticator to remotely authenticate a user over a network.

• An application that uses the described proprietary synchronization protocol in conjunction with embodiments of the present invention to perform user-controlled trust delegation to a new device, thereby sharing authenticator registration content between the user's devices.

An application that uses the described proprietary synchronization protocol in conjunction with embodiments of the present invention to perform user-controlled trusted delegation to new devices, thereby sharing new registration content between the user's devices, where the user does not need to authenticate to the authenticator each time a new registration content is delegated to another device.

A group of validators belonging to the same user and forming a circle, where these validators synchronize their validation key pairs using the private synchronization protocol described above in order to share a single validator's registration with other validators belonging to the same circle.

M. Exemplary System Architecture

It should be noted that the term "relying party" as used herein refers 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 the secure transaction server implemented on behalf of that entity (which can perform the basic verification techniques described herein). The secure transaction server 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. These distinctions are illustrated in Figures 46A to 46B discussed below, which show that a "relying party" can include a website 4631 and other network services 4651, as well as secure transaction servers 4632 to 4633 for performing verification techniques on behalf of the website and network services.

Specifically, Figure 46 A to 46B illustrate two embodiments of the system architecture comprising the client-side component and server-side component for verifying the user. The embodiment shown in Figure 46 A uses the architecture based on browser plug-in to communicate with the website, and the embodiment shown in Figure 46 B does not need a browser. Various advanced authentication technologies and associated applications as described herein can be implemented on any one of these system architectures. For example, the authentication engine (e.g., 230) in the client device described above can be implemented as a part for the secure transaction services 4601 comprising interface 4602. However, it should be noted that the embodiments described above can be implemented using the logical arrangement of hardware and software except those shown in Figure 46 A to 46B.

Turning to Figure 46A, the illustrated embodiment includes a client 4600 equipped with one or more authentication devices 4610 to 4612 for enrolling and authenticating an end user. As described above, authentication devices 4610 to 4612 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 4601 may store as biometric template data in secure storage 4620 (via interface 4602).

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

Authentication devices 4610-4612 are communicatively coupled to the client via an interface 4602 (e.g., an application programming interface or API) exposed by a secure transaction service 4601. The secure transaction service 4601 is a secure application for communicating with one or more secure transaction servers 4632-4633 via a network and for interfacing with a secure transaction plug-in 4605 executed within a web browser 4604. As shown, the interface 4602 may also provide secure access to a secure storage device 4620 on the client 4600, which stores information related to each authentication device 4610-4612, such as a device identification code, a user identification code, user registration 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 used when communicating with the server 4630 via a network (such as the Internet).

In addition to device registration, the secure transaction service 4601 may then register the biometric device with secure transaction servers 4632-4633 via the network, and subsequently authenticate with those servers using the data exchanged during the registration process (e.g., an encryption key pre-set to the biometric device). The authentication process may include any of the authentication techniques described herein (e.g., generating an assurance level on the client 4600 based on explicit or non-intrusive authentication techniques and transmitting the result to the secure transaction servers 4632-4633).

As discussed below, secure transaction plugin 4605 supports certain types of network transactions, such as HTTP or HTTPS transactions with a website 4631 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 4631 (sometimes referred to hereinafter as "server 4630") within a secure enterprise or web destination 4630. In response to detecting such a tag, secure transaction plugin 4605 may forward the transaction to secure transaction service 4601 for processing. In addition, for certain types of transactions (e.g., such as secure key exchange), secure transaction service 4601 may open a direct communication channel with a local transaction server 4632 (i.e., co-located with the website) or an off-site transaction server 4633.

Secure transaction servers 4632-4633 are coupled to a secure transaction database 4640 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 4630 shown in FIG46A. For example, website 4631 and secure transaction servers 4632-4633 may be implemented within a single physical server or separate physical servers. Furthermore, website 4631 and transaction servers 4632-4633 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 Figure 46A. Figure 46B illustrates an alternative implementation in which a standalone application 4654 utilizes functionality provided by secure transaction service 4601 to authenticate users via the network. In one embodiment, application 4654 is designed to establish a communication session with one or more network services 4651, which rely on secure transaction servers 4632-4633 to perform the user/client authentication techniques described in detail below.

46A-46B , secure transaction servers 4632-4633 may generate keys that are then securely transmitted to secure transaction service 4601 and stored in a verification device within secure storage 4620. Additionally, secure transaction servers 4632-4633 manage a secure transaction database 4640 on the server side.

A series of exemplary transactions for performing authentication device discovery, registration, enrollment, and authentication are shown in Figures 47 to 51. Some aspects of these transactions have been adopted in the OSTP protocol described above (see the OSTP Framework (March 23, 2011) for additional details, which is incorporated herein by reference). An understanding of the basic operation of these transactions will provide an environment in which embodiments of the present invention can be implemented.

The operations described below include detecting the verification device (Figure 47); registering the user with the verification device (Figure 48); registering the verification device (Figure 49); authenticating the user with the registered verification device (Figure 50); and implementing a secure transaction after authentication (Figure 51).

Figure 47 shows a series of transactions for detecting authentication devices on a client machine. After successful device detection, server 4730 has comprehensive information about the authentication devices attached to the client and will be able to evaluate which (which) devices are most suitable for use with the enhanced security infrastructure. Only server 4730 screens the list of authentication devices. This list will be provided to the user, and the user can select one (or a group of) authentication devices for further verification and implementation of secure transactions.

In operation, a user authenticates and logs into a website using a username and password in a browser. Only then is the user required to provide their username and password. Server 4730 determines that the user is not currently using enhanced security (e.g., by querying secure transaction database 4720) and recommends that the user change to enhanced security.

In one embodiment, server 4730 includes a "Query Device" tag in the HTML page that is detected by secure transaction plugin 4705. In response to detecting this tag, secure transaction plugin 4705 reroutes the request to secure transaction service 4701, which then prepares detailed information about all authentication devices attached to the system, including the device's security features. In one embodiment, this information is packaged in XML format using a pre-specified data schema before transmission.

The secure transaction plugin 4705 receives this information from the secure transaction service 4701 and, in one embodiment, passes it to the web page's JavaScript via a registered callback. It then chooses how to display the information in the browser 4704. The user can be presented with a list filtered by the website and can select one or a group of authentication devices.

Figure 48 illustrates a series of transactions for registering a user with an authentication device. In one embodiment, registration is a prerequisite for using the enhanced security provided by embodiments of the present invention described herein. Registration involves taking a biometric reading (e.g., fingerprint, voice sample, etc.) of the user so that the same authentication device can be used to authenticate the user during subsequent transactions. Registration operations can be performed independently on the client without interacting with server 4730. The user interface provided for registration can be displayed in a browser extension or in a separate application or mobile device application.

Once a device is detected, a registration operation can be initiated. The user can choose to use one or a group of discovered devices to achieve enhanced security. In operation, the user can select a device from a displayed list of devices in a browser, application, or mobile device application. For the browser-based implementation shown in Figure 48, the secure transaction plugin 4705 displays a device-specific registration graphical user interface (GUI). The secure transaction plugin 4705 transmits the device identifier and registration request to the secure transaction service 4701 and waits for completion. If the user is already registered with the authentication device on the client, the user may only need to verify their identity (i.e., the user will not need to register again). If the user is not currently registered, the secure transaction service 101 begins the registration process by activating the physical authentication device (e.g., via device interface 4702). The user then interacts with the secure transaction plugin 4705 GUI and follows the designated registration steps (e.g., swiping a finger, speaking into a microphone, taking a photo, etc.). Once completed, the user is registered with the authentication device. Notably, once a user is registered with a device, they can use this registration to register or authenticate with any website or network service, as described herein.

Figure 49 illustrates a series of transactions for registering an authentication device. During registration, a key is shared between the authentication device and one of the secure transaction servers 4732-4733. The key is stored in secure storage 4720 on the client 4700 and in a secure transaction database 4720 used by the secure transaction servers 4732-4733. In one embodiment, the key is a symmetric key generated by one of the secure transaction servers 4732-4733. 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 servers 4732-4733, and a second, related private key may be stored in secure storage 4720 on the client. Furthermore, in one embodiment (also discussed below), the key may be generated on the client 4700 (e.g., by the authentication device or authentication device interface rather than by the secure transaction servers 4732-4733).

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 FIG49 , once user registration or user verification is complete, server 4730 generates a randomly generated challenge (e.g., a cryptographic random number), which 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 4701. In response, secure transaction service initiates an out-of-band session (e.g., an out-of-band transaction) with server 4730 and communicates with server 4730 using a key provisioning protocol. Server 4730 locates the user using the username, verifies the random challenge, verifies the device's verification code if it has already been sent, and creates a new entry for the user in secure transaction database 4720. It also generates a key, writes the key to database 4720, and sends the key back to secure transaction service 4701 using a key provisioning protocol. Once completed, the authenticating device and server 4730 share the same key if symmetric keys are used, or different keys if asymmetric keys are used.

Figure 50 shows a series of transactions for authenticating a user to a registered authentication device.Once device registration is complete, server 4730 will accept the token generated by the local authentication device as a valid authentication token.

50 , which illustrates a browser-based implementation, a user enters the uniform resource locator (URL) of a server 4730 into a browser 4704. In an implementation using a stand-alone application or mobile device application (rather than a browser), the user may enter the network address of the web service, or the application or mobile device application may automatically attempt to connect to the web service at the network address.

For a browser-based implementation, the website embeds a query for registered devices in an HTML page. This can be done in many ways besides embedding the query in the HTML page, such as through JavaScript or using HTTP headers. Secure transaction plugin 4705 receives the URL and sends it to secure transaction service 4701. Secure transaction service 4701 searches secure storage 4720 (which, as discussed, includes a database of authenticated devices and user information) and determines whether a user is registered at the URL. If so, secure transaction service 4701 sends a list of pre-configured devices associated with the URL to secure transaction plugin 4705. The secure transaction plugin then calls a registered JavaScript API and passes this information to server 4730 (e.g., a website). Server 4730 selects the appropriate device from the sent device list, generates a random challenge, and sends the device information and parameters back to the client. The website displays the corresponding user interface and requests user authentication. The user then provides the required authentication measure (e.g., swiping a finger on a fingerprint reader, speaking for voice recognition, etc.). Secure transaction service 4701 identifies the user (this step can be skipped for devices that do not support storing user names), obtains the username from the database, generates a verification token using the key, and sends this information to the website via the secure transaction plugin. Server 4730 identifies the user from secure transaction database 4720 and verifies the token by generating the same token on server 4730 (e.g., using a copy of its key). Once verified, the verification process is complete.

FIG51 illustrates a secure transaction after verification for a browser-based implementation. This secure transaction 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 proceeding. Using the illustrated technique, the user confirms what transaction they wish to conduct and proceeds with the transaction exactly as they see it displayed in the GUI. In other words, this embodiment ensures that a "middleman" cannot modify the transaction text to conduct a transaction without the user's confirmation.

In one embodiment, the secure transaction plug-in 4705 displays a window 5101 in the browser environment to show the transaction details. The secure transaction server 4701 periodically (e.g., at random time intervals) verifies that the text shown in the window is not being tampered with by anyone.

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 4732-4733 that implement one or more embodiments of the present invention described herein. The merchant website authenticates the user and completes the transaction.

Secure transaction servers 4732-4733 receive the transaction details (TD) and place a "secure transaction" request in an HTML page and send it to client 4700. The secure transaction request includes the transaction details and a random challenge (e.g., a random number). Secure transaction plug-in 4705 detects the request for a transaction confirmation message and forwards all data to secure transaction service 4701. 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 4700.

For browser-based implementations, secure transaction plug-in 4705 displays window 5101 with transaction details to the user (in the browser environment) and asks the user to provide verification to confirm the transaction. In embodiments that do not use a browser or plug-in, secure transaction service 4701 or application 4754 may display window 5101. Secure transaction service 4701 starts a timer and verifies the contents of window 5101 being displayed to the user. The verification period may be randomly selected. Secure transaction service 4701 ensures that the user sees valid transaction details in window 5101. If it detects that the content has been tampered with, it prevents the generation of a confirmation token.

After the user provides valid authentication (e.g., swiping a finger across a fingerprint sensor), the device identifies the user and generates a token (cryptographic signature) using the transaction details and a random challenge (i.e., the token is calculated based on the transaction details and the random number). This allows secure transaction servers 4732-4733 to ensure that the transaction details have not been modified between the server and the client. Secure transaction service 4701 sends the generated token and username to secure transaction plugin 4705, which forwards the token to secure transaction servers 4732-4733. Secure transaction servers 4732-4733 use the username to identify the user and verify the token. If verification is successful, a confirmation message is sent to the client and the transaction is processed.

System and method for determining a secure query policy for client authentication functionality

As mentioned, 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 authentication capabilities, such as a fingerprint sensor, voice recognition, facial recognition, eye/optical recognition, a Trusted Platform Module (TPM), and a smart card, among others. 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.

Figure 52 illustrates one embodiment of a client-server architecture for implementing these techniques. As shown, secure transaction service 4701 implemented on client 4700 includes a policy filter 5201, which analyzes the policy provided by server 4730 and identifies a subset of authentication functions to be used for registration and/or authentication. In one embodiment, policy filter 5201 is implemented as a software module that executes within the context of secure transaction service 4701. However, it should be noted that policy filter 5201 can be implemented in any manner while still consistent with the underlying principles of the present invention and may include software, hardware, firmware, or any combination thereof.

The particular implementation shown in FIG52 includes a secure transaction plug-in 4705 for establishing communication with a secure enterprise or web destination 4730 (sometimes referred to simply as "server 4730") using the techniques previously discussed. For example, the secure transaction plug-in can identify specific HTML tags inserted into the HTML code by the web server 4731. Thus, in this embodiment, the server policy is provided to the secure transaction plug-in 4705, which forwards it to the secure transaction service 4701, which implements the policy filter 5201.

The policy filter 5201 can determine the client authentication capabilities by reading the capabilities from the client's secure storage area 5220. As previously discussed, the secure storage 5220 can include a repository of all client authentication capabilities (e.g., identification codes for all authentication devices). If the user has registered the user with their authentication device, the user's registration data is stored in the secure storage 5220. If the client has registered authentication devices with the server 4730, the secure storage can also store the cryptographic secret keys associated with each authentication device.

Using the authentication data extracted from secure storage 5220 and the policy provided by the server, policy filter 5201 can then identify a subset of authentication functions to use. Depending on the configuration, policy filter 5201 can identify the full list of authentication functions supported by both the client and the server, or it can identify a subset of the full list. For example, if the server supports authentication functions A, B, C, D, and E, and the client has authentication functions A, B, C, F, and G, policy filter 5201 can identify the entire subset of common authentication functions: A, B, and C, to the server. Alternatively, if a higher level of privacy is desired, as indicated by user preferences 5230 in FIG. 52 , a more limited subset of authentication functions can be identified to the server. For example, the user can indicate that only a single common authentication function (e.g., one of A, B, or C) should be identified to the server. In one embodiment, the user can establish a prioritization scheme for all authentication functions of client 4700, and the policy filter can select the highest priority authentication function (or prioritized group of N authentication functions) shared by both the server and the client.

Depending on which operation (registration or authentication) was initiated by the server 4730, the secure transaction service 4730 performs the operation on the selected authentication device subset (4710 to 4712) and sends the operation response back to the server 4730 via the secure transaction plug-in 4705, as shown in Figure 52. Alternatively, in an embodiment that does not rely on the plug-in 4705 component of the web browser, this information can be passed directly from the secure transaction service 4701 to the server 4730.

FIG53 shows a transaction diagram illustrating additional details of an exemplary series of registrations using a query strategy transaction. In the illustrated embodiment, the user has not previously registered the device with server 4730. Therefore, at 5301, the user may enter a username and password as an initial, one-time verification step, which are forwarded to server 4730 via client browser 4704 at 5302. However, it should be noted that a username and password are not necessarily required in order to comply with the underlying principles of the present invention.

Because it is determined at 5303 that the user has not previously registered with enhanced security, server 4730 transmits its server policy to the client at 5304. As mentioned, the server policy may include an indication of the authentication functionality supported by server 4730. In the illustrated example, the server policy is communicated to secure transaction service 4701 via transaction 5306.

At transaction 5307, secure transaction service 4701 compares the server policy with the client's capabilities (and possibly other information, such as a device priority scheme and/or user preferences, as described above) to derive a filtered list of authentication capabilities. The filtered list of devices (4702) then generates keys (5308 and 5309) and then provides the public portion of these keys to secure transaction service 4701, which in turn sends these back to server 4730 as a registration response. The server authenticates the authentication device and stores the public key in the secure transaction database. Token authentication, as employed here, is the process of confirming the identity of the authentication device during registration. It allows the server to cryptographically ensure that the device reported by the client is actually the device it claims to be.

Alternatively or additionally, at 5307, the user may be provided with an opportunity to review the list and/or select a particular authentication function to be used with this particular server 4730. For example, the filter list may indicate options for using authentication using fingerprint scanning, facial recognition, and/or voice recognition. The user may then select one or more of these options to use when authenticating to the server 4730.

The techniques described above for filtering server policies at the client can be implemented at various stages in the series of transactions described above (e.g., during device discovery, device registration, device provisioning, user authentication, etc.). That is, the underlying principles of the invention are not limited to the specific set of transactions and specific transaction order set forth in FIG.

Furthermore, as previously mentioned, a browser plug-in architecture is not necessarily required to comply with the underlying principles of the present invention. For architectures that do not involve a browser or browser plug-in (e.g., such as a standalone application or a mobile device application), the transaction diagram shown in FIG53 (and the rest of the transaction diagrams disclosed herein) can be simplified such that the browser 4704 is removed and the secure transaction service 4701 communicates directly with the server 4730.

System and method for efficient registration, enrollment, and authentication with multiple authentication devices

One embodiment of the present invention enables simultaneous registration, enrollment, and verification of multiple devices, improving efficiency and user experience. For example, rather than requesting registration and verification for a single device at a time, a list of devices can be sent to the client. Symmetric or asymmetric keys can then be registered with multiple devices in a single operation or a series of sequential operations performed locally on the client. For verification purposes, several tokens/devices can be selected simultaneously for a given transaction.

Figure 54 illustrates one embodiment of a client-server architecture for implementing these techniques. As shown, the secure transaction service 4701 implemented on the client 4700 includes multi-device processing logic 5401, which is used to perform specified operations, such as registering and registering multiple devices at once without the need for continuous back-and-forth communication with the server 4730 when registering/registering each device. Similarly, the server 4730 includes multi-device processing logic for issuing commands directed to multiple authentication devices. In one embodiment, the multi-device processing logic 5401 is implemented as a software module executed within the environment of the secure transaction service 4701. However, it should be noted that the multi-device processing logic 5401 can be implemented in any manner while still complying with the basic principles of the present invention and can include software, hardware or firmware components, or any combination thereof.

As in the embodiments described above, the particular implementation shown in Figure 54 includes a secure transaction plug-in 4705 for establishing communication with a server 4730 (which, as discussed, may include a website server 4731 and secure transaction servers 4732-4733). Thus, the server 4730 communicates with the secure transaction service 4701 via the secure transaction plug-in 4705. However, as mentioned, a browser-based plug-in architecture is not necessarily required in order to conform to the underlying principles of the present invention.

The multi-device processing logic 5402 on the server 4730 may transmit commands to be executed by the multi-device processing logic 5401 on the client 4700, which performs operations on multiple authentication devices 4710-4712. For example, the multi-device processing logic 5402 may generate N keys to be registered with each of the N authentication devices and then securely transmit them to the multi-device processing logic 5401 along with commands to register the N devices. The multi-device processing logic 5401 may then perform registration for all N devices (e.g., for the authentication devices 4710-4712) simultaneously or in a series of sequential operations without further interaction with the server. A single response may then be sent to the server 4730 to indicate that registration for all N devices is complete.

A series of exemplary multi-device transactions are shown in Figures 55A through 55C. Figure 55A illustrates a multi-device registration process that can be performed without any interaction with server 4730 (e.g., registering a user with an authentication device can be performed under the control of secure transaction service 4701 on the client). In an alternative embodiment, server 4730 can transmit a request to a client (not shown) to register a user with N devices. Figures 55B through 55C illustrate two different embodiments for registering multiple devices with server 4730.

Turning to the registration process in Figure 55A, at 5501, the user indicates a desire to register with N authentication devices on the client (representing all or a subset of the available authentication devices). In response, at 5502, the secure transaction plugin is invoked, and at 5503, a device-specific graphical user interface (GUI) is generated to guide the user through the process or register with authentication device #1. During the registration process, the user interacts with the secure transaction plugin as instructed (e.g., by placing a finger over the fingerprint sensor, speaking into the microphone, taking a photo with the camera, etc.). In one embodiment, registration is performed for each of the N devices until registration for the Nth device is complete at 5504. The user may be presented with a different device-specific script and/or user interface to register the user with each individual authentication device. As previously discussed, as the user registers with each device, the user registration data may be stored in secure storage 720 on client 4700 and accessible only through secure transaction service 4701. Once registration for all N devices is complete, a notification may be sent to server 4730 via transactions 5504-5505.

Regardless of how registration is performed, once completed, the transaction diagram shown in FIG55B can be used to register N devices with server 4730. At 5510, server 4730 generates a user-specific random challenge. As previously described, this random challenge may be valid only within a limited time window and may include a randomly generated code, such as a cryptographic nonce. At 5511, the random challenge is transmitted along with a command to register N authentication devices with server 4730. At 5512, secure transaction service 4701 establishes a secure connection with server 4730 and transmits identification data for the N devices along with the random challenge. In one embodiment, the secure connection is an HTTPS connection. However, the underlying principles of the present invention are not limited to any particular secure connection type.

At 5513, server 4730 authenticates the N devices, generates a key for each of the N devices, and sends these N keys back to the secure transaction service via the secure connection. In one embodiment, the Dynamic Symmetric Key Provisioning Protocol (DSKPP) is used to exchange keys with the client over the secure connection. However, the underlying principles of the present invention are not limited to any particular key provisioning technique. Alternatively, in an embodiment that does not rely on the DSKPP protocol, a key can be generated in each authentication device and then transmitted to server 4730.

At 5514-5515, the multi-device processing logic of the secure transaction service registers each of the N keys with each of the N devices. As previously described, each key can be stored in the secure storage device 720 on the client and associated with the corresponding device in the secure storage device. Once the registration is completed for each verification device, a notification is sent to the server via a secure connection at 5516.

In one embodiment, the keys registered with each authentication device are symmetric keys. Therefore, identical copies of each key are stored in the secure storage device 720 on the client and the secure transaction database 4720 on the server 4730. In an alternative implementation, an asymmetric key pair may be generated, with one key maintained as a public key in the secure transaction database 4720 on the server, and a private key stored in the secure storage device 720 on the client. However, it should be noted that the underlying principles of the present invention are not limited to any particular type of cryptographic key.

FIG55C illustrates an alternative implementation in which keys are generated on the client rather than on the server 4730. In this implementation, after receiving a request to register a device along with a random challenge at 5511, the multi-device processing logic of the secure transaction service 4701 generates N keys for each of the N devices at 1120. Once generated, the keys are registered with each of the N devices at 5513-5514 and the registrations are stored in the secure storage 720, as previously described. Once all keys have been registered, the secure transaction service 4701 provides a notification to the server at 5515 along with a random challenge (for verifying the client's identity). The server 4730 may then store the registrations in the secure transaction database 4720, as described above.

System and method for processing random challenges within an authentication framework

One embodiment of the present invention improves the way random challenges are generated and processed by the server. In one embodiment, the random challenge includes a randomly generated code, such as a cryptographic nonce. In current systems, after the server transmits the random challenge to the client, if the client does not respond within a specified timeout period, the random challenge is no longer valid and the client will receive an error in response to subsequent authentication attempts (e.g., the user will swipe their finger on a fingerprint reader and be rejected).

In one embodiment of the present invention, the client automatically detects whether the challenge has expired and transparently requests a new challenge from the server (i.e., without user intervention). The server then generates a new random challenge and transmits it to the client, which the client can then use to establish secure communication with the server. The end-user experience is improved because the user does not receive an error or rejection of the authentication request.

FIG56A shows one such embodiment used within the context of a registration process, and FIG56B shows an embodiment used within the context of a verification process. However, it should be noted that the underlying principles of the invention can be employed in other contexts than those shown in FIG56A through 56B. For example, the techniques described herein can be used with any process that transmits a time-sensitive code from a server to a client.

First, turning to Figure 56A, at 5601, the server 4730 generates a random challenge and an indication of a timeout period. In one embodiment, the timeout period includes the time period during which the random challenge is considered valid. After the timeout period has passed, the random challenge is no longer considered valid by the server 4730. In one embodiment, the timeout period is simply specified as the point in time when the random challenge will no longer be valid. Once this point in time is reached, the random challenge is invalid. In another embodiment, the timeout period is specified by using the current timestamp (i.e., the time when the server 4730 generates the random challenge) and the duration. The secure transaction service 4701 can then calculate the point in time when the random challenge becomes invalid by adding the duration value to the timestamp, thereby calculating the timeout period. However, it should be noted that the basic principles of the present invention are not limited to any specific technology for calculating the timeout period.

Regardless of how the timeout period is specified or calculated, at 5602, the random challenge and timeout indication are transmitted to the secure transaction service 4701 (in the illustrated example, via the browser 4704 and the secure transaction plug-in 4705). At 5603, the secure transaction service 4701 detects whether the random challenge has timed out and is no longer valid based on the timeout indication sent from the server 4730. For example, the user may have shut down their client machine or closed the lid of their laptop before completing a series of transactions. If the transaction requires user interaction, the user may have simply walked away or ignored the message displayed within the GUI.

At 5604, upon detecting that the random challenge is no longer valid, secure transaction service 4701 transmits a request for a new random challenge to server 4730 (in the illustrated example, via secure transaction plugin 4705 and browser 4704). At 5605, server 4730 generates a new random challenge and a new indication of a timeout period. In one embodiment, the timeout period is the same as in operation 5601 or may be modified. For example, server 4730 may increase the duration of the timeout period to reduce data traffic with the client, or decrease the duration to increase the level of security provided by the random challenge. At 5606, the new random challenge and timeout indication are transmitted to secure transaction service 4701.

The remainder of the transaction occurs as previously described. For example, the secure transaction service opens a secure connection directly to the server at 5607 to perform device registration and key exchange, as discussed above in conjunction with Figures 49, 55B, or 55C. At 5608, server 4730 identifies the user (e.g., using a username or other ID), verifies the authentication device, and generates a key for the device. As mentioned, this key can be a symmetric key or an asymmetric key. At 5609, the key is transmitted to secure transaction service 4701 via the secure connection, and at 5610, secure transaction service 4701 registers the key with the authentication device. At 5611, a notification indicating that registration is complete is transmitted to server 4730.

Thus, in the embodiment shown in Figure 56A, keys for device registration are generated at server 4730, as in the embodiment shown in Figure 55B. However, the underlying principles of the present invention can also be used in embodiments where keys are generated by secure transaction service 4701 on client 4700, such as the embodiment described above in conjunction with Figure 55C.

FIG56B illustrates one embodiment of the present invention implemented within the context of an authentication process. At 5651, a user enters a specific website URL into a browser 4704 and is directed to a web server 4731 within an enterprise/web destination server 4730, which includes secure transaction servers 4732-4733. At 5652, a query is sent back to the secure transaction service (via the browser and plug-in) to determine which device(s) are registered with the website's URL. At 5653, the secure transaction service 4701 queries the secure storage 720 on the client 4700 to identify a list of devices that is sent back to the server 4730. At 5654, the server 5654 selects a device for authentication, generates a random challenge and a timeout indication, and at 5655, sends this information back to the secure transaction service 4701.

At 5656, the secure transaction service 5656 automatically detects that the random challenge is no longer valid when the end of the timeout period is reached. As described above, a variety of different techniques can be used to indicate and detect the end of the timeout period (see Figure 56A and associated text). After detecting that the random challenge has expired, at 5657, the secure transaction service 4701 transparently (i.e., without user intervention) notifies the server 4730 and requests a new random challenge. In response, at 5658, the server 4730 generates a new random challenge and a new indication of the timeout period. As mentioned, the new timeout period can be the same as the timeout period previously sent to the client or can be modified. In either case, at 5659, the new random challenge and timeout indication are sent to the secure transaction service 4701.

The remainder of the transaction diagram shown in FIG56B operates in substantially the same manner as described above (e.g., see FIG50 ). For example, at 5660, an authentication user interface is displayed (e.g., directing the user to swipe a finger across a fingerprint sensor), and at 5661, the user provides authentication (e.g., swiping a finger across a fingerprint scanner). At 5662, the secure transaction service verifies the user's identity (e.g., comparing authentication data collected from the user with data stored in secure storage device 720) and encrypts a random challenge using a key associated with the authentication device. At 5663, the username (or other ID code) and the encrypted random challenge are sent to server 4730. Finally, at 5664, server 4730 uses the username (or other ID code) to identify the user within secure transaction database 4720 and decrypts/verifies the random challenge using a key stored in secure transaction database 4720 to complete the authentication process.

Systems and methods for implementing privacy categories within an authentication framework

In one embodiment, an end user can pre-define, select, and/or modify multiple privacy protection categories. The privacy categories can be defined based on the probability that the client can be identified using the disclosed information. In privacy categories with relatively high privacy levels, relatively little information about the client device is disclosed to perform the authentication techniques described herein. In one embodiment, the user can choose to disclose the least amount of information possible when communicating with different servers (i.e., can select transactions with the lowest privacy impact allowed for each website or network service).

Figure 57 illustrates a high-level architecture for implementing privacy categories. As shown, the secure transaction service 4701 of this embodiment includes privacy management logic 5701, which is used to analyze queries for client information (such as information related to authentication devices) received from the server 4730, implement privacy policies in response to such queries, and generate responses containing client information collected based on the specific privacy categories in use. In one embodiment, the privacy management module 5701 is implemented as a software module that executes within the environment of the secure transaction service 4701. However, it should be noted that the privacy management module 5701 can be implemented in any manner while still consistent with the basic principles of the present invention and can include software, hardware, firmware, or any combination thereof.

The privacy categories utilized by the privacy management logic 5701 can be pre-specified and stored on the client 4700 (e.g., within the secure storage device 5720). In one embodiment, three privacy categories are defined: high privacy impact, medium privacy impact, and low privacy impact. Each privacy category can be defined based on the probability that the disclosed information can be used to uniquely identify the user/client. For example, the information disclosed for a low privacy impact transaction may result in a 10% probability of uniquely identifying the user or machine via the Internet; a medium privacy impact transaction may result in a 50% probability of uniquely identifying the user or machine; and a high privacy impact transaction may result in a 100% probability of uniquely identifying the user or machine. Various other privacy category levels can be defined while still consistent with the underlying principles of the present invention.

In one embodiment, each relying party (e.g., each website 4731 or service 4751) can specify a desired privacy category or other privacy threshold. For example, websites and services requiring a high level of security may only allow communications according to the high privacy impact category, while other websites/services may permit interactions using the medium or low privacy impact categories. In one embodiment, a query for client information sent from server 4730 includes an attribute specifying which privacy category information should be retrieved (i.e., low, medium, or high). Thus, privacy management logic 5701 stores information of the highest approved privacy category for each relying party. In one embodiment, whenever a relying party requests information belonging to a higher privacy category than the one already approved, the user is prompted to permanently approve (or deny) this new privacy category for that relying party. In response to user approval, privacy management logic may store a new association between the relying party (e.g., identified via a URL) and the new privacy category.

Although user preferences 5730 are applied directly to the privacy management logic in FIG57 for simplicity, it should be noted that the user can specify preferences via a browser-based graphical user interface (not shown). In this case, the user would enter the privacy settings via a browser window. The secure transaction plug-in 4705 would then store the new settings in the privacy management logic 5701 or in a configuration data file accessible to the privacy management logic 5701. In short, the underlying principles of the present invention are not limited to any particular mechanism for configuring the privacy management logic.

Various types of client data may be specified at various privacy category levels, including, for example, machine model identifiers, client software information, client capabilities, and various levels of information related to each authentication device configured on the client device (e.g., device ID code, vendor ID code, device category ID, etc.). Different combinations of this information may be collected to determine the percentages specified above that define the different privacy categories.

Figure 58 illustrates a series of transactions for providing information to a requester using defined privacy categories. At 5801, server 4730 generates a notification containing a query for client device information. At 5802, the query is sent to the client and ultimately received by secure transaction service 4701. At 5803, the privacy management logic of the secure transaction service determines the privacy category of the response and collects the necessary information. As described above, N different privacy category levels can be defined, and secure transaction service 4701 can select a privacy category level that meets the requester's requirements while revealing as little information about the client as possible. At 5804, the collected information is sent to server 4730, and at 5805, the server uses the information for one or more subsequent transactions with the client.

System and method for implementing a verification framework using transaction signing

One embodiment of the present invention utilizes transaction signing on a secure transaction server, enabling the maintenance of client sessions without maintaining any transaction state on the server. Specifically, transaction details, such as transaction text, can be sent to the client, 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 this would consume significant storage space for a large number of clients and could lead to the possibility of denial-of-service attacks on the server.

One embodiment of the present invention is illustrated in Figure 59, which shows a website or other network service (5901) initiating a transaction with a client 4700. For example, a user may have selected an item to purchase on the website and may be ready to check out and pay. In the illustrated example, the website or service 5901 hands the transaction over to a secure transaction server 5902, which includes signature processing logic 5903 for generating and verifying signatures (as described herein) and authentication logic 5904 for performing client authentication (e.g., using the authentication techniques previously described).

In one embodiment, the verification request sent from the secure transaction server 5902 to the client 4700 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 5903 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 authentication 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 authentication permitted for a given transaction. In one embodiment, once the user has successfully authenticated on the client 4700, the client transmits the following back to the server: (1) a random challenge and transaction text (both previously provided to the client by the server), (2) authentication data proving that the user successfully authenticated, and (3) a signature.

The verification module 5904 on the secure transaction server 5902 can then confirm that the user has been properly authenticated, and the signature processing logic 5903 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 5901. This saves storage and processing resources because the secure transaction server 5902 does not need to permanently store the transaction text (or other transaction data) in the secure transaction database 4720.

Exemplary data processing apparatus

FIG60 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 while FIG60 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 60, computer system 6000, which is a form of data processing system, includes a bus 6050, which is coupled to a processing system 6020, a power supply 6025, a memory 6030, and a non-volatile memory 6040 (e.g., a hard drive, flash memory, phase change memory (PCM), etc.). The bus 6050 can be connected to each other through various bridges, controllers, and/or adapters as are well known in the art. The processing system 6020 can retrieve instructions from the memory 6030 and/or the non-volatile memory 6040 and execute these instructions to perform the operations described above. The bus 6050 interconnects the above components together and also interconnects those components to an optional base 6060, a display controller and display device 6070, an input/output device 6080 (e.g., a NIC (network interface card), a cursor control (e.g., a mouse, a touch screen, a touchpad, etc.), a keyboard, etc.), and an optional wireless transceiver 6090 (e.g., Bluetooth, WiFi, infrared, etc.).

Figure 61 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 6100 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 6100 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 6100 can be used for the mobile device described above. The data processing system 6100 includes a processing system 6120, which may include one or more microprocessors and/or systems on integrated circuits. The processing system 6120 is coupled to a memory 6110, a power supply 6125 (which includes one or more batteries), an audio input/output 6140, a display controller and a display device 6160, an optional input/output 6150, an input device 6170, and a wireless transceiver 6130. It should be understood that in certain embodiments of the present invention, other components not shown in Figure 61 may also be part of the data processing system 6100, and in certain embodiments of the present invention, fewer components than shown in Figure 61 may be used. In addition, it should be understood that one or more buses not shown in Figure 61 can be used to interconnect various components as known in the art.

The memory 6110 can store data and/or programs for execution by the data processing system 6100. The audio input/output 6140 may include a microphone and/or a speaker to (for example) play music, and/or provide telephone functionality through the speaker and microphone. The display controller and display device 6160 may include a graphical user interface (GUI). A wireless (e.g., RF) transceiver 6130 (e.g., a WiFi transceiver, an infrared transceiver, a Bluetooth transceiver, a wireless cellular phone transceiver, etc.) can be used to communicate with other data processing systems. The one or more input devices 6170 allow a user to provide input to the system. These input devices may be a keypad, a keyboard, a touch panel, a multi-touch panel, etc. Optional other input/output 6150 may 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 (8)

1. A location-aware method for user authentication, the method comprising: receiving, at a client, a request from a user of the client to perform a transaction with a relying party, the transaction requiring user authentication, the relying party comprising a website or online service implemented by one or more computer servers; receiving, by a verification engine, environmental sensor data from one or more sensors of the client; using, by the verification engine, a geographic location of the client reported by one of the one or more sensors of the client to collect supplemental data known to the geographic location, the supplemental data being collected from a source other than the one or more sensors of the client; Collecting client configuration data by a client risk assessment agent, wherein the client configuration data includes at least one of hardware data, operating system data, and application data of the client; calculating, by an assurance level calculation module, a relevance score based on a comparison of the client configuration data and the environmental sensor data with the supplemental data; Determining, by the assurance level calculation module, the assurance level required to allow the client to complete the transaction; determining, by the assurance level calculation module, an assurance level gain required to achieve the assurance level based on the relevance score; and One or more authentication techniques are selected, by the authentication engine, to authenticate the user based at least in part on the indication of the assurance level gain. 2. The method of claim 1, wherein the hardware data comprises at least one of: a client device model, a client processor name, a client processor type, a client boot read-only memory (ROM) version, and a management controller version. 3 . The method of claim 1 , wherein the operating system data comprises at least one of: a current operating system (OS) version, a last OS update date, and a current boot mode. 4. The method of claim 1 , wherein the application data comprises at least one of: firewall status, firewall type, firewall version, antivirus software status, antivirus software version, antivirus software virus definition file, latest antivirus scan date, and latest antivirus scan results. 5. A system for user authentication, the system comprising: a client for receiving a request from a user to perform a transaction with a relying party, the transaction requiring user authentication, the relying party comprising a website or online service implemented by one or more computer servers; A validation engine that: receiving environmental sensor data from one or more sensors of the client; collecting supplemental data known for a geographic location reported by one of the one or more sensors of the client, the supplemental data being collected from a source other than the one or more sensors of the client; a client risk assessment agent configured to collect client configuration data, wherein the client configuration data includes at least one of hardware data, operating system data, and application data of the client; and The assurance level calculation module is used to: calculating a relevance score based on a comparison of the client configuration data and the environmental sensor data with the supplemental data; determining a required level of assurance to allow the client to complete the transaction; determining an assurance level gain required to achieve the assurance level based on the relevance score; Wherein the authentication engine selects one or more authentication techniques to authenticate the user based at least in part on the indication of the assurance level gain. 6. The system of claim 5, wherein the hardware data comprises at least one of: a client device model, a client processor name, a client processor type, a client boot read-only memory (ROM) version, and a management controller version. 7 . The system of claim 5 , wherein the operating system data comprises at least one of: a current operating system (OS) version, a last OS update date, and a current boot mode. 8. The system of claim 5, wherein the application data comprises at least one of: firewall status, firewall type, firewall version, antivirus software status, antivirus software version, antivirus software virus definition file, latest antivirus scan date, and latest antivirus scan results.