System and method for binding verifiable claims

Abstract

The present invention describes systems, apparatus, methods, and machine-readable media for binding verifiable claims. For example, one embodiment of the system includes: a client device; a verifier of the client device, the verifier being configured to securely store verification data, the verification data comprising one or more verifiable claims received from one or more claim providers, each verifiable claim having attributes associated with the verifiable claim; and claim / attribute processing logic, the claim / attribute processing logic being configured to generate a first verifiable claim binding for a first verifiable claim issued by a claim provider; wherein the verifier is configured to transmit a first signed assertion to a first relying party for verification to the first relying party, the first signed assertion comprising an attribute extension, the attribute extension containing data associated with the first verifiable claim binding.

Description

Background Art

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Patent Application No. 16 / 244,705, filed January 10, 2019, which claims the benefit of co-pending U.S. Provisional Patent Application No. 62 / 616,997, filed January 12, 2018, all of which are hereby incorporated by reference herein. Technical Field

[0003] The present invention generally relates to the field of data processing systems with authentication. More particularly, the present invention relates to systems and methods for binding verifiable claims.

[0004] Description of related fields

[0005] Figure 1 An exemplary client 120 with a biometric device 100 is shown. 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).

[0006] 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.).

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

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

[0009] 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).

[0010] 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.

[0011] 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); and Koichiro Niinuma, Anil K. Jain, "Continuous User Authentication Using Temporal Information (Continuous User Authentication Using Temporal Information)" (currently located at http: / / www.cse.msu.edu / biometrics / Publications / Face / NiinumaJain_ContinuousA uth_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).

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

[0013] 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.

[0014] 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).

[0015] 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.

[0016] 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.

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

[0018] For some categories of transactions, the risk associated with the transaction may be inseparable from the location where the transaction is being performed. In other cases, it may be desirable to allow transactions only if stronger authentication mechanisms are used; for example, a transaction conducted from within a company's physical premises may require less authentication than a transaction from a Starbucks located in a remote area where the company has no business.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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

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

[0029] Figure 1 An exemplary client equipped with a biometric device is shown;

[0030] Figure 2 An embodiment of a non-intrusive privacy preserving authenticator (NIPPA) is shown;

[0031] Figure 3 Graphically illustrating the operation of one embodiment of the present invention during and after a "valid user state";

[0032] Figure 4 An embodiment of a method for non-intrusive privacy-preserving authentication is shown;

[0033] Figure 5 shows a distance function for location-based authentication in one embodiment;

[0034] Figure 6 Graphically illustrating the operation of one embodiment of the present invention using an extended valid user status window;

[0035] Figure 7 An adaptive verification module according to one embodiment of the present invention is shown;

[0036] Figure 8 An embodiment of an adaptive verification method is shown;

[0037] Figure 9 graphically illustrating adaptive verification according to one embodiment;

[0038] Figure 10 One embodiment of a composite validator having multiple components is shown.

[0039] Figure 11 An embodiment in which two validators share components is shown.

[0040] Figure 12 One embodiment of an authenticator is shown that includes component authentication logic that manages component authentication key (CAK) pairs used to authenticate components.

[0041] Figure 13 A transaction diagram is shown illustrating one embodiment of authentication between two components.

[0042] Figure 14 A static verifier according to one embodiment of the present invention is shown.

[0043] Figure 15 A dynamic validator according to one embodiment of the present invention is shown.

[0044] Figure 16 An exemplary system architecture is shown upon which embodiments of the present invention may be implemented.

[0045] Figure 17 One embodiment of a system for executing a location-aware application with an authentication policy is shown;

[0046] Figure 18 An exemplary set of authentication policy rules is shown;

[0047] Figure 19 A method according to one embodiment of the present invention is shown;

[0048] Figure 20 An embodiment of the present invention is shown wherein location is determined or confirmed by proximity of other peer devices or network devices;

[0049] Figure 21 One embodiment of a system for authentication using environmental sensors is shown;

[0050] Figure 22 One embodiment of a method for authentication using an environmental sensor is shown;

[0051] Figure 23 One embodiment of a system for adaptively applying authentication policies is shown;

[0052] Figure 24 One embodiment of a method for adaptively applying an authentication strategy is illustrated; and

[0053] Figure 25 An exemplary client equipped with a biometric device is shown;

[0054] Figure 26A One embodiment of a verification engine including an eye tracking module and a facial recognition module is shown;

[0055] Figure 26B An embodiment of a verification engine is shown, which includes a speech recognition module and a lip movement analysis module as well as an eye tracking module and a facial recognition module;

[0056] Figure 27A and Figure 27B An exemplary heat map showing a web page employed in one embodiment of the present invention;

[0057] FIG. 28A to FIG. 28B illustrates exemplary text, graphics, photos, videos, white space, and other content that may be displayed to an end user;

[0058] Figures 29A to 29B An embodiment of a method for performing verification based on eye tracking and facial recognition, as well as verification based on speech recognition and lip movement analysis is shown;

[0059] Figure 30 Shown are different architectural arrangements in which embodiments of the invention may be implemented.

[0060] Figure 31 One embodiment of a client-side architecture including a client-side risk assessment agent is shown;

[0061] Figure 32 illustrates exemplary types of client configuration data used by the client risk assessment agent;

[0062] Figure 33 One embodiment of a method for performing client risk assessment during authentication is shown;

[0063] Figure 34 One embodiment of a client performing a secure transaction with a local device is shown;

[0064] Figure 35 One embodiment of a client architecture for performing secure transactions with a local device is illustrated;

[0065] Figure 36 One embodiment of a method for performing a secure transaction with a local device is shown;

[0066] Figure 37 One embodiment of a system for user confirmation of online transactions is shown;

[0067] Figure 38 shows details of one embodiment of a client for use in a system for user confirmation of online transactions;

[0068] Figure 39 An embodiment of a method for user confirmation of online transactions is shown;

[0069] Figure 40 One embodiment of a system for delegating trust from a trusted client device to a new client device is shown;

[0070] Figure 41 shows additional details of one embodiment of a system for delegating trust from a trusted client device to a new client device;

[0071] Figure 42 One embodiment of a method for delegating trust from a trusted client device to a new client device is illustrated;

[0072] Figure 43 One embodiment of a system for synchronizing private data between devices is shown;

[0073] Figure 44 One embodiment of a method for adding a device to a circle of trust is shown;

[0074] Figure 45 One embodiment of a method for synchronizing data between devices is shown;

[0075] Figures 46A to 46B Shown are different exemplary architectural arrangements in which embodiments of the invention may be implemented.

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

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

[0078] Figure 49 is a transaction diagram showing how a key may be registered into a verification device.

[0079] Figure 50 is a transaction diagram illustrating how user authentication may be implemented within an authentication framework.

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

[0081] Figure 52 A query policy filter implemented according to one embodiment of the present invention is shown.

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

[0083] Figure 54 One embodiment of an architecture for implementing multi-authentication device processing is shown.

[0084] Figures 55A to 55C Three embodiments of the present invention are shown for multi-authentication device processing.

[0085] Figures 56A to 56B A transaction diagram illustrating detecting and responding to a random challenge timeout.

[0086] Figure 57 An architecture for implementing privacy classes according to one embodiment of the present invention is shown.

[0087] Figure 58 is a transaction graph for implementing privacy classes according to one embodiment of the present invention.

[0088] Figure 59 One embodiment of an architecture for authentication and transactions using signatures is shown.

[0089] Figures 60 to 61 An exemplary embodiment of a computer system for implementing embodiments of the present invention is shown.

[0090] Figure 62 An embodiment is shown in which a relying party uses metadata to authenticate a client;

[0091] Figure 63 An exemplary architecture including a Keymaster and a validator is shown;

[0092] Figure 64 Another embodiment of an architecture for processing formatted messages is shown;

[0093] Figure 65 One embodiment of storing and processing virtual AppIDs and / or relying party IDs is shown;

[0094] Figure 66 One embodiment of an architecture for encrypting and generating attestation data for blocks of a blockchain is shown;

[0095] Figure 67 An embodiment of the present invention for binding verifiable claims to public key credentials is shown;

[0096] Figure 68 shows additional details of one embodiment of the present invention for binding verifiable claims to public key credentials;

[0097] Figure 69 shows a system according to one embodiment of the present invention; and

[0098] Figure 70 A system on a chip (SoC) is shown according to one embodiment. DETAILED DESCRIPTION

[0099] 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.

[0100] 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.

[0101] In specific implementations of mobile biometrics, the biometric device may be remote from the relying party. As used herein, the term "remote" means that the biometric sensor is not part of the security perimeter of the computer to which it is communicatively coupled (e.g., the biometric sensor is not embedded in the same physical housing as the relying party's computer). For example, the biometric device may be coupled to the relying party via a network (e.g., the Internet, a wireless network link, etc.) or via a peripheral input (such as a USB port). Under these conditions, the relying party may not be able to know whether the device is an authorized device by the relying party (e.g., a device that provides an acceptable level of authentication and integrity protection) and / or whether a hacker has compromised the biometric device. The confidence level of the biometric device depends on the specific implementation of the device.

[0102] 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.

[0103] 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.

[0104] 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, 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 facilitating the provision of, a network "service" 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.

[0105] A. Non-Intrusive Privacy-Preserving Verification

[0106] 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 device's authentication status to the relying party when authentication is required, rather than sensitive information such as a machine ID.

[0107] Some embodiments of the present invention described below can work completely frictionlessly (i.e., without requiring any explicit user authentication). Behavioral or other techniques can 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 can 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 can be considered to be in a "legitimate user state" and the assurance level is set to a maximum value (e.g., 100 on a standardized scale of -100 to 100).

[0108] 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.

[0109] 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 above are merely examples; the underlying principles of the present invention are not limited to any set of non-intrusive variables.

[0110] 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."

[0111] 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.

[0112] Figure 2 , an embodiment of an architecture for providing non-intrusive privacy-preserving authentication is shown, the architecture including a non-intrusive privacy-preserving authenticator (NIPPA) 210, and the non-intrusive privacy-preserving authenticator (NIPPA) 210 including 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 an ID code, etc.). In one embodiment, the explicit user authentication devices 220 to 221 include Figure 1 Same or similar architecture as shown.

[0113] exist Figure 2In the illustrated embodiment, non-intrusive authentication 230 includes a location authentication module 231 for performing location-based authentication using one or more location sensors 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.

[0114] 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.

[0115] 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.

[0116] Although Figure 2 2 and 3. The location verification module 231, the user behavior module 232 and any other verification modules 233 are shown as separate modules in FIG, but 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 present invention may be implemented using various different logical arrangements of modules.

[0117] 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 "valid user state" and adjust the assurance measurement value accordingly.

[0118] 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).

[0119] 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.

[0120] 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.

[0121] 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 the 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:

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

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

[0124] Figure 3 The operation of one embodiment of the present invention according to the above formula is shown in FIG. 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.

[0125] At time t2 (not in the legitimate 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 legitimate user. After this calculation, the assurance level decreases over time (for example, the legitimate user may expose the device to non-legitimate 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.

[0126] 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).

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

[0128] 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.

[0129] 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.

[0130] Go to Figure 5 If, at 501, it is determined 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).

[0131] 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.

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

[0133] 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).

[0134] Next, the distance (d) is determined using "Distance = (distance from current location (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.

[0135] In some of the above embodiments, it is assumed that the legitimate user still has 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 behavioral reference data within a specific time window after explicit authentication.

[0136] like Figure 7 As shown, one embodiment of the present invention uses an extended time window in addition to the standard time window of legitimate user state to update the behavioral reference data (i.e., train the system). Therefore, the full time window (including the standard time window and the extended time window) can be defined as follows: (1) if it is within the legitimate user state 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 will make it easy for an attacker to "turn" the behavioral reference to his advantage.

[0137] B. Adaptive Verification Technology

[0138] Figure 8 One embodiment of the present invention for implementing adaptive authentication techniques is shown. 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 communications with a relying party 250 (e.g., using a secure encryption key, as discussed above).

[0139] 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 invention remain the same.

[0140] also, Figure 8 The "relying party" 250 shown may 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. Thus, although embodiments of the present invention are described in terms of a "relying party," the underlying principles of the present invention may be implemented using servers outside the perimeter of a network operated by the relying party.

[0141] 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, IP packet round trip delay time, etc.). Additionally, the assurance level gain analysis component 811 can determine the amount by which the current assurance level must be increased to obtain an acceptable assurance level. Figure 8 These elements are shown as components of the relying party's adaptive authentication module 810 in FIG, but these elements may also be implemented within the client's adaptive authentication module 800 while still conforming to the underlying principles of the invention.

[0142] 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.

[0143] 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.

[0144] By way of example and not limitation, the adaptive authentication module 800 may combine authentication modalities 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 wired or wireless connections to other gadgets, such as Nymi, a smartwatch (pebble), or peripherals such as headphones); behavioral data (e.g., how the user removes the device from a pocket, typing behavior, gait); time since the device was in a "trusted" state; and possibly the results of new explicit authentication using one or more forms of authentication (biometric or otherwise) required to achieve the desired (remaining) gain in assurance level.

[0145] 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.

[0146] 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.

[0147] Figure 9 A method according to one embodiment of the present invention is shown in 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.

[0148] 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).

[0149] The assurance level gain can be determined based on the assurance level required to complete the transaction. For example, this can be accomplished using the following formula: 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.

[0150] 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).

[0151] Figure 10 The following diagram illustrates how the embodiments 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.

[0152] 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.

[0153] 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.

[0154] To address these issues, one embodiment of the present invention uses geolocation 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 also be protected by transmitting only a level of assurance based (at least in part) on the geolocation data.

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

[0156] 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 sent to the relying party. These operations can be performed by the location verification module 231 described above.

[0157] 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 the secure communication module 213 and other enrollment techniques described herein).

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

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

[0160] 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 (eg, from 0 to 100). The assurance calculation module 212 can then incorporate the score into the assurance calculation (as described above).

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

[0162] C. Composite Validator

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

[0164] 1. Store and use cryptographic verification keys

[0165] 2. Generate, store, and use password-verified keys

[0166] 3. Local user authentication or verification of user existence

[0167] 4. Safely display information to end users

[0168] 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:

[0169] 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.

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

[0171] 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.

[0172] 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. Figure 11 In the example, rather than implementing all components responsible for the above functionality in a single module protected by a single shell, the authenticator 1100 is implemented using two separate independent authenticator components: a user verification component (UVC) 1101 and an authenticator kernel (AK) 1103, each with its own protection logic 1110 and 1112. In this example, the AK 1103 securely manages one or more confirmation keys 1104 and verification keys 1105 for the authenticator 1100, and the UVC 1101 manages user verification / presence functionality 1106 and secure display functionality 1107 (specific examples of which are described below and in the co-pending applications).

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

[0174] Figure 12An embodiment of the present invention is shown 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 the 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 the information 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 attest to the model and / or integrity of the validator to the relying party as part of the registration process) and verification keys 1216 (used to establish secure communications with the relying party using a unique verification key for each relying party). The component building blocks for the 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.

[0175] Authenticators built from multiple components in this way are called "composite authenticators" because they consist 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 more efficient to build new secure authenticators. For example, Figure 12 As shown, the same authenticator kernel component 1214 is shared between the 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, a facial recognition based authenticator (whose biometric segmentation and matching algorithms may be too large to be implemented within a secure element (SE) or a trusted execution environment (TEE)) can still utilize the SE / TEE to protect its confirmation key and user verification key. In this example, the user verification component (e.g., including the segmentation and matching algorithms) can run outside the SE / TEE, while the verification kernel component can be implemented within the SE / TEE. Similarly, a fingerprint based authenticator implemented in a TEE can still utilize the SE verification kernel to protect its confirmation key and user verification key and thereby resist hardware-based attacks (e.g., such as differential power analysis (DPA)).

[0176] 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 refer to Figure 13 Describe, Figure 13 Shown with Figure 12 Additional details associated with the various components 1210, 1212, 1214 used to implement the validator 1201.

[0177] 1. Safety Measures (SM) 1 : In one embodiment, each component (e.g., Figures 12 to 13 User authentication component 1210, display component 1212, or authentication kernel 1214 shown)

[0178] Each component has its own "Component Authentication Key" pair (CAK) (e.g., CAK pairs 1304, 1305, and 1306, respectively) which it uses to register with other components (possibly mutually) and to authenticate messages sent to other components. Figure 13 As noted, each component 1210, 1212, 1214 includes component authentication logic 1301, 1302, 1303, respectively, for entering into inter-component authentication transactions using CAK pairs 1304, 1305, 1306, respectively. In one embodiment, CAK pairs 1304, 1305, 1306 are public / private key pairs, but the underlying principles of the invention are not limited to such implementations. In this implementation, each component is provided with the public keys of those components to 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; and

[0179] 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 with which it must communicate by sharing the public keys. The component can then authenticate to those components using the techniques described below.

[0180] 2. Safety Measures (SM) 2 : Each component can authenticate other components from which it receives messages by verifying their public CAKs. For example, in Figure 13 Middle, AK

[0181] 1214 can verify the public CAK of all UVC 1210 and DC 1212 it supports

[0182] (ie, the public key in CAK pair 1304 and 1305 .) If mutual authentication is implemented, UVC and DC may also verify the public CAK of AK 1214 (ie, in CAK pair 1306 ).

[0183] Figure 14 14 is a transaction diagram illustrating how authentication between two components (AK 1214 and DC 1212) may be implemented. At transaction 1400, the component authentication logic 1303 of the AK generates a challenge and sends it to the component authentication logic 1302 of the DC 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 component authentication logic 1302 of the DC generates a signature for the challenge using the private key from its CAK pair 1305 and may 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 a signature may involve applying a hash function to the challenge using the private key. At transaction 1403, the component authentication logic 1302 of the DC sends the signature back to the component authentication logic 1303 of the AK for verification. The component authentication logic 1303 of the AK now knows the challenge (e.g., the random number it previously generated), the signature generated using the private key of the DC's CAK pair, and the public key of the DC's CAK pair. 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 AK 1214.

[0184] 3. Safety Measures (SM) 3 : Depending on the specific implementation, additional security mechanisms may be used to protect the communication between components. These additional security mechanisms are Figure 13 13. The hardware / software protection mechanisms 1310 are shown 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 (SE), trust chain technology, trusted user interface technology, OS-level access control mechanisms, white-box encryption, code obfuscation, and runtime integrity protection, among others. By using (for example) TrustZone TM Or similar techniques, 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). For 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.

[0185] 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, a 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).

[0186] 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.

[0187] 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).

[0188] 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 enters into 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 that the AK signs 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 a private key). 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.

[0189] 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.

[0190] 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.

[0191] Static Composite Validator

[0192] See also Figure 15 In one embodiment, a composite verifier 1501 having the following characteristics is referred to herein as a "static" composite verifier:

[0193] 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

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

[0195] Therefore, if Figure 15 As shown, 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.

[0196] 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).

[0197] 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 certificate of the UVC or DC 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.

[0198] 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's | 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).

[0199] Figure 15The illustrated architecture of the user device 1500 also includes a browser / application 1510 for establishing communications with a relying party 1320, and secure transaction logic 1520 for enabling communications with the authenticator. For example, as shown, in one embodiment, the secure transaction logic 1520 enables messaging between the components 1510, 1514 of each authenticator 1501 by exposing an application programming interface (API) to the various components. Thus, in this embodiment, all communications between the components (such as the exchange of registration data and messages) occur via the secure transaction logic 1520. For example, the secure transaction logic 1520 may be implemented as a "secure transaction service" as described in the co-pending application (parts of which are set forth below). The browser / application 1510 may be used to establish communications with the relying party 1320 via a network (such as the Internet).

[0200] Dynamic Composite Validator

[0201] See also Figure 16 A composite validator 1601 having the following characteristics is a "dynamic composite validator" if:

[0202] 1. A "Component Authentication Key" (CAK) 1604, 1604 is treated as an attestation key, such that the relying party 1320 has and needs the associated public key to verify attestation messages (e.g., referred to as "Key Registration Data" in the OSTP specification); and

[0203] 2. The relying party 1320 receives multiple AAIDs 1602, 1603 (depending on the number of components in the authenticator 1601). In one embodiment, the relying party 1320 sends all components 1610, 1603 of the authenticator 1601 to the browser / application 1610 via the secure transaction logic 1620.

[0204] 1614's AAID 1602, 1603 is received as part of the registration message sent from AK 1614. Figure 16 Only UVC 1610 and AK 1614 are shown, but alternative embodiments such as Figure 31604 and the DC's AAIDs (not shown). AK 1614 then sends 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 AK's confirmation key 1605, and one signature for each of the other components (e.g., UCC's confirmation key 1604 and DC's confirmation key (not shown)). As mentioned, in one embodiment, AK 1614 includes one or more confirmation messages of other components in its confirmation message to RP 1320 if and only if it trusts communication with the other component.

[0205] 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 user 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.

[0206] UVC / DC Assertion Verification

[0207] 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 authentication 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.

[0208] For registration, in an embodiment with a static authenticator, UVC 210 and DC 212 may send a key registration message containing a component ID (instead of an AAID) to AK 214, where the 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.

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

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

[0211] 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.

[0212] 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).

[0213] 3. Verify additional platform-specific protection mechanisms, such as packet ID for incoming data, or use similar platform-provided protection mechanisms.

[0214] 4. Check the revocation status of the certificate containing the public CAK of UVC or DC. Since AK is only interested in the revocation information of a very small number of certificates / keys (i.e., the certificate / key of the current UVC or DC), the Online Certificate Status Protocol (OCSP) (mentioned above) can be used.

[0215] Revocation Verification. It is assumed that the AK has no network connectivity, so the OCSP response is expected as part of the incoming data from the UVC and / or DC.

[0216] Optimized verification method

[0217] 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 the 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 rather is 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.

[0218] D. Location-aware verification technology

[0219] 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.

[0220] like Figure 17 As shown, one embodiment of the present invention includes a client device 1700 having an authentication policy engine 1710 for implementing the location-aware authentication policy described herein. Specifically, this embodiment includes a location category determination module 1740 for identifying a current location "category" using the current location of the client device 1700 provided by a location sensor 1741 (e.g., a GPS device). As discussed in detail below, different location "categories" may be defined, including known geographic points and / or areas. The location category data may 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 may then compare the current location provided by one or more sensors 1741 with the defined "categories" to determine the current location category of the client device 1700.

[0221] In one embodiment, the relying party 1750 specifies a verification policy to be implemented by the verification policy engine 1710 for each transaction (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, transactions requiring the transfer of large amounts of money may require a relatively high verification assurance threshold, while non-monetary transactions 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.

[0222] In one embodiment, the location category determination module 1740 provides the determined category to the authentication strategy module 1711, which implements a set of rules to identify the authentication technique 1712 to be used for the determined category. By way of example and not limitation, Figure 18 A set of exemplary rules 1 to 5 are shown that specify one or more authentication techniques 1 to 5 that may be used for each defined location category 1 to 5. Figure 18 , but the underlying principles of the present invention are not limited to any particular type of data structure for implementing a rule set.

[0223] 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.

[0224] 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.

[0225] 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.

[0226] 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:

[0227] 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.

[0228] 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.

[0229] 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.

[0230] 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.

[0231] A variety of mechanisms can be used to determine the client's current physical location (in Figure 17 1741), including but not limited to the following:

[0232] 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.

[0233] 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 by 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.

[0234] Cell Tower Triangulation: Integration between the client, server, and wireless carrier infrastructure allows the client and server to use cellular signal strength triangulation to perform high-resolution determination of physical location.

[0235] 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.

[0236] Position displacement inference: The exact location of the device may not be known, but a 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 location 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.

[0237] Figure 19 One embodiment of a method for implementing a location-aware authentication strategy is shown. Figures 17 to 18 The present invention is implemented within the context of the illustrated system architecture, but is not limited to any particular system architecture.

[0238] 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.

[0239] 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.

[0240] 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.

[0241] The embodiments of the present invention described herein provide many benefits to the verification system. 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.

[0242] 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.

[0243] 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.

[0244] Figure 20 An embodiment is shown 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-2006 (e.g., client computers, mobile phones, tablet computers, etc.); two different wireless access points 2010-2011; and two different cell phone towers 2020-2021. As used herein, client device 1700 can "see" without formally establishing a connection with each other device. For example, a client can see multiple peer devices connected to a work LAN and / or can see the wireless signals generated by those devices, regardless of whether the client is connected to those devices. Similarly, client device 1700 can see the Basic Service Set Identifiers (BSSIDs) of multiple different Wi-Fi access points (e.g., Wi-Fi from a nearby hotel, coffee shop, or work Wi-Fi access point). Client device 1700 can also see multiple different cell phone towers 2020 and 2021, perhaps 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.

[0245] 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 he / she is at work, at home, or at 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).

[0246] 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).

[0247] 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, peer-to-peer communication via a standard such as 802.11n can be utilized to collect authentication tokens from peer devices, which can be used to prove that those peer devices have been authenticated.

[0248] 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.

[0249] In one embodiment, historical device proximity data 2004 is collected and shared among multiple devices, and the historical device proximity data 2004 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.

[0250] E. Implementations for Confirming Location Using Supplemental Sensors and / or Location Data

[0251] 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.

[0252] like Figure 21 As shown, additional sensors 1743 that provide supplemental assurance regarding the location of the device 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, and the supplemental data correlation module 2140 of the verification strategy engine 1710 uses these readings to correlate with supplemental data 2110 known to be associated with the location provided by one or more location sensors 1741 (or derived using various other techniques described herein). The verification strategy module 1711 then uses the correlation results to select one or more verification techniques 1712 for a given transaction. Figure 21 As indicated, supplemental location data 2110 may include data collected from external sources (eg, the Internet or other mobile devices) and local data sources (eg, historical data collected during periods when the device is known to be in the possession of a legitimate user).

[0253] 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 a location provided by one or more location sensors 1741. The supplemental data correlation module 2140 compares humidity, temperature, or air pressure collected from the additional sensors 1743 with the real-time local weather data 2110 to identify instances where the sensor data is inconsistent with local conditions. For example, if the GPS reading of the client device indicates that the device is outdoors, but the temperature, humidity, or air pressure is inconsistent with 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 that a more stringent verification technique 1712 (e.g., fingerprint, PIN entry, etc.) be performed to approve the transaction.

[0254] 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.

[0255] In one embodiment, the supplemental data correlation module 2140 compares the data collected from the sensor 1743 on the user's device with 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 verified 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 that the local temperature is 20°C. As a result, the verification policy 1711 may require a more stringent verification technique 1712.

[0256] 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.

[0257] The supplemental data correlation module 2140 can perform 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 standardized value indicating the level of correlation (e.g., between 0 and 1). 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 then 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 performing correlation.

[0258] Figure 22 , a method according to one embodiment of the present invention is shown in FIG. 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 can be collected locally or remotely (e.g., over the Internet from other clients and / or servers), and can include data such as the current temperature, pressure, and / or humidity of the reported location. The sensor data can be provided by a temperature sensor, a barometric or altimeter pressure sensor, and / or a humidity sensor.

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

[0260] 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.

[0261] 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.

[0262] The above-described embodiments achieve a number of benefits. For example, these embodiments provide an additional level of assurance for location data collected from other sources: allowing organizations to supplement location data collected from other sources (IP, GPS, etc.) to provide 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 to respond 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).

[0263] F. Adaptive application of authentication strategies based on client authentication capabilities

[0264] like Figure 23 As shown, 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.

[0265] 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).

[0266] 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.

[0267] 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).

[0268] 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.

[0269] 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).

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

[0271] 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.

[0272] 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.

[0273] 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).

[0274] Additionally, in one embodiment, the rules 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.

[0275] 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).

[0276] In one embodiment, when determining whether to permit a transaction with client 1700, adaptive authentication policy engine 2345 implements authentication rules 2326 in dependence upon 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 an applicable set of one or more interaction categories 2327 and associated authentication rules 2326. It may then, via communication with adaptive authentication policy module 2350 on client device 1700 (in Figure 23 1700).

[0277] 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.

[0278] 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 previously visited), 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.

[0279] Figure 23 The system shown in FIG2 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 one or more authentication modes based on the authentication rules implemented for the current transaction and the risks associated with the client. For example, the adaptive authentication policy module 2345 can perform authentication via the "validity model 123" fingerprint sensor installed on the client for a given transaction request.

[0280] 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 about 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 module 2345 can then instruct the client device 1700 to use that particular authentication device.

[0281] 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 can convey a message 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 category 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.

[0282] like Figure 23 As indicated, client device 1700 may include its own one or more policy databases 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.

[0283] Figure 24 A method for performing adaptive authentication based on client device capabilities is shown in FIG. Figure 23 The system is shown but is not limited to any particular system architecture.

[0284] 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.

[0285] 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 one or more 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).

[0286] In any case, a set of authentication techniques, consisting of one or more authentication techniques, is selected based on the requirements specified via the one or more 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).

[0287] Many 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. All a relying party needs to do to integrate is define a policy for a class of interactions (e.g., "large transfers") and have the integration code use that policy identifier to determine the correct authentication mechanism to utilize when interacting with the policy engine.

[0288] Furthermore, these implementations 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.

[0289] Finally, these implementations 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; new capabilities can be deployed immediately without writing new code.

[0290] G. Systems and Methods for Eye Tracking During Verification

[0291] 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.

[0292] 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.

[0293] 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).

[0294] 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).

[0295] 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).

[0296] 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:

[0297] Even if the security setting is set to High, Samsung Series Cogent BioTrust 3.00.4063 running on a laptop also performs no liveness check at all. A simple facial image displayed on a regular computer monitor is enough to successfully fool the system.

[0298] On Macbook KeyLemon 2.6.5 running on a machine learning platform performs a simple eye-blink test as a liveness check. It can be successfully fooled by showing it a sequence of three images: (1) a real image of a face (e.g., created by a webcam); (2) a modification of the real image in which the eyeballs have been recolored to appear closed; and (3) the real image again.

[0299] 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.

[0300] Figure 25 An exemplary client 2520 is shown 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., takes 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.

[0301] There are several potential attack points to deceive facial recognition systems (see references 10, 11). Figure 25 identi?ed as (1) to (8). There are well-known protection mechanisms for ensuring the integrity of the biometric template (6) (e.g., by using an electronic signature) and protecting the integrity of the feature extractor (3), the feature vector (4), the matcher (5), and its final result (8) (e.g., by applying a combination of (a) white-box cryptographic methods, (b) code obfuscation, and (c) device binding).

[0302] 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.

[0303] 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):

[0304] 1. Data-driven characterization

[0305] a. Still images

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

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

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

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

[0310] b. Video

[0311] 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).

[0312] vi. If images are used for spoofing, there will be dependencies between the face and the background

[0313] (Reference 17).

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

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

[0316] 2. User behavior modeling (Reference 12).

[0317] 3. User interaction requirements (Reference 12).

[0318] 4. Additional devices (reference 12).

[0319] 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).

[0320] Texture Differences

[0321] 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 shows that algorithms can detect differences by analyzing microtexture: "A close look at the differences between a real face and a print of a face reveals that faces and prints reflect light differently because a face is a complex, non-rigid 3D object, while a photograph can be considered a flat, rigid object."

[0322] 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.

[0323] Infrared, not visible light

[0324] 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.

[0325] Optical flow based methods

[0326] 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.

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

[0328] Moving pictures, not static images

[0329] 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.

[0330] 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.

[0331] 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.

[0332] 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.

[0333] Challenge Response Method

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

[0335] 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.

[0336] (Biometrics Technology Subcommittee of the National Science and Technology Council)

[0337] Multimodal systems

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

[0339] 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).

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

[0341] 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.

[0342] 2) Systems with the following conditions:

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

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

[0345] 3) Systems with the following conditions:

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

[0347] b) It is easier to fool any feature in this multimodal system than to fool the same feature in a unimodal system Even complex The embodiments of the present invention described below fall into this category.

[0348] 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 can be presented with a series of random screen layouts that mix text, white space, images, and video clips to elicit eye movements from the user in a non-invasive manner. At the same time, 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.

[0349] 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 dispositions, interests, and characteristics (see the current Wikipedia article at en.wikipedia.org / wiki / Eye_tracking for "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 heat map shows which parts of your website people click on. www.michaelhartzell.com / Blog / bid / 92970 / Crazy-Egg-Heatmap-shows-where-people-click-on-your-website, 2012-11-30).

[0350] like Figure 26A As shown, 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.

[0351] 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 enrolls 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 met), 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).

[0352] 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 templates specify text, graphics, pictures, videos, and / or blank areas to be displayed to the user on the display 2601 of the client device (some examples are shown below). Figures 28A to 28B ), and it is also possible to specify the order in which such content is to be displayed. In addition, the eye tracking template includes data (e.g., in the form of a heat map, see below) that specifies the expected movement characteristics of the user's eyes in response to content displayed to the user. 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 image), thereby deriving a "score" based on the similarity between the expected movement and the actual movement. 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 the database 2646 can be compiled using records of eye movements made by other users and / or actual users of the device in response to each displayed web page or other displayed image. For example, like the facial recognition template, the eye tracking template can be generated as part of a registration process in which a user registers his / her eye movements with the device 2600.

[0353] 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.

[0354] like Figure 26A As shown, various other explicit user authentication devices 2620-2621 and sensors 2643 can be configured on the client device 2600. These authentication devices and sensors can 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 can 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 can 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 can negatively impact the assurance level 2606. In this way, authentication data can be generated in a non-invasive manner (i.e., using sensor data collected without explicit input from the end user).

[0355] 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).

[0356] 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).

[0357] Figure 26BAnother embodiment is shown in which the verification engine 2610 includes a speech recognition module 2660 and a lip movement analysis module 2670 in addition to (or in place of) the facial recognition module 2604 and the eye tracking module 2605. In one embodiment, the user's voice is captured via a microphone 2680, and the analog voice signal is converted to a digital signal via an analog-to-digital (A / D) converter 2681. The speech recognition module 2660 compares the digital voice signal with the user's voiceprint stored in a voice database 2665. In one embodiment, the voiceprint is generated during a training / enrollment process in which the user is prompted to say certain words or phrases. Upon receiving the digitized audio signal resulting from the spoken word / phrase, the speech recognition module 2660 generates the voiceprint by capturing specific features of the user's voice (e.g., spectral features, pronunciation-based classification, etc.) and storing the results in the voice database 2665. The speech recognition module 2660 can utilize various speech recognition techniques when generating the voiceprint and comparing the voiceprint with the captured speech signal, including but not limited to techniques based on frequency estimation, hidden Markov models, Gaussian mixture models, pattern matching algorithms, neural networks, matrix representations, vector quantization, and decision trees.

[0358] In one embodiment, the user is prompted to speak a specific sequence of words and / or phrases displayed on the client device's display 2601. These words / phrases may be the same or similar to the words / phrases used during the enrollment process, so that the speech recognition module 2660 can compare similar speech features with the speech features captured in the voiceprint.

[0359] In response to its analysis, the speech recognition module 2660 generates a "score" or other value indicating the degree to which the captured speech is similar or dissimilar to the voiceprint. The verification engine 2610 then uses these results to increase or decrease the assurance level 2606. For example, if there is a 97% probability that the legitimate user has spoken the indicated word / phrase, the assurance level 2606 can be increased. In contrast, if there is a 97% probability that the legitimate user is not the user who spoke the word / phrase, the assurance level 2606 can be decreased.

[0360] In addition, one embodiment also includes a lip movement analysis module 2670 that analyzes the movements of a user's lips as the user speaks a word / phrase. For example, the lip movement analysis module 2670 can compare the user's video image 2603 as the user speaks the word / phrase and determine how closely the audio stream captured via microphone 2680 matches the video stream. If the user's lips are out of sync with the captured audio stream, this can indicate that the current user is deceiving the system (e.g., playing a recording of a legitimate user's voice). To determine whether synchronization exists, the lip movement analysis module 2670 can be trained to associate certain pronunciations and volume levels with certain lip / mouth positions and / or movements over time. For example, it would be expected that periods when the user's mouth is open (i.e., lips apart) would produce a louder volume than periods when the user's mouth is closed (lips together). Similarly, it would be expected that vowels would be heard during times when the user's lips are apart, and consonants would be heard during times when the user's lips are together.

[0361] Additionally, in one embodiment, the lip movement analysis module 2670 can compare the lip movements captured in the video image 2603 with reference lip movements of the user stored in the lip movement database 2675. As with the voiceprint, the reference lip movements can be captured during an enrollment process where an image of the user saying certain words / phrases is recorded, and the relevant data is extracted and stored in the database 2675.

[0362] In one embodiment, a score or other value is generated by the lip movement analysis module 2670 to indicate the correlation between the lip movements of the user captured on the video 2603 and the lip movements that would be expected. For example, if the audio and video appear to be synchronized, the score generated by the lip movement analysis module 2670 can be relatively higher than if the audio and video appear to be out of sync. Similarly, if the lip movements detected in the video image 2603 have a high correlation with the reference lip movements stored in the lip movement database 2675, the lip movement analysis module 2670 can generate a relatively high score.

[0363] In one embodiment, analysis of the speech recognition module 2660, lip movement analysis module 2670, facial recognition module 2604, and / or eye tracking module 2605 can be combined to generate an assurance level 2606, thereby providing a likelihood that a legitimate user is in possession of the client device 2600. Embodiments of the present invention can be implemented by any one of these modules or any combination of these modules to generate an assurance level 2606. This assurance level 2606 can then be used in conjunction with various other verification techniques described herein.

[0364] although Figure 26B Not shown in Figure 26A To avoid obscuring additional features of this embodiment (e.g., sensor 2643, eye tracking database 2645, facial recognition database 2646, explicit user authentication devices 2620-2621, secure storage device 2625, etc.), these components may be considered to be included in Figure 26B implementation plan.

[0365] Figure 27A and Figure 27B An example "heat map" generated for a web page is shown in FIG. 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).

[0366] 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.

[0367] 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).

[0368] Figure 28A An exemplary grouping of text 2805 and images and / or videos 2801 displayed on a client device display 2601 is shown. In one embodiment, the grouping is integrated into a web page. However, the underlying principles of the invention are not limited to web-based organization. The grouping can also be part of a screen saver or other application. In one embodiment, the text 2805 and images / videos 2801 are displayed simultaneously. In another embodiment, the text is displayed first, followed by the 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).

[0369] Figure 28BAnother example is shown 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 such a 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.

[0370] 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 one or more actual locations. 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 detected degree of movement.

[0371] Additionally, the eye tracking module 2605 may use existing content, such as an existing web page of the relying party 2650 or an image stored locally on the device, rather than generating its own content. 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 may be displayed. In such cases, the eye tracking module 2605 may retrieve a heat map of the web page (such as a heat map of the web page) from the eye tracking database 2645. Figure 27A and Figure 27B as shown) and determine if there is a correlation with the heat map and the location the end user is viewing.

[0372] 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, resulting in a captured scan path. A correlation is then performed between the captured scan path and the expected scan path. Additionally, one embodiment of the present invention can then re-verify that a face is still recognized.

[0373] 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).

[0374] exist Figure 29A -B shows a method according to one embodiment of the present invention. This method can be used in a process such as Figure 26A The system architecture is shown but is not limited to any particular system architecture.

[0375] First go to Figure 29A At 2901, a specific eye tracking template is selected for a given user and / or transaction. At 2902, a series of images of the user's face are 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.

[0376] 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. At 2905, a face assurance level is generated based on the correlation between the captured image and the facial template. Similarly, at 2906, an eye tracking assurance level is generated based on the correlation between the user's eye movements and the expected movement of the user's eyes.

[0377] Figure 29B Show that it can be used with Figure 29A A series of speech recognition operations and lip movement related operations are performed in parallel. Alternatively, Figure 29A - The operations in B may be performed sequentially (in any order) until an acceptable level of assurance has been achieved.

[0378] At 2911, audio and video of the current user holding the client device are captured and digitized. At 2912, a specific voiceprint is selected from a voice database (e.g., one previously recorded for the user during the enrollment process), and a voice recognition operation is performed. At 2917, a score / assurance level is generated indicating the correlation between the current user's voice and the voiceprint. At 2913, a correlation is determined between the digitized audio and the lip movements of the video captured for the current user, and at 2915, a score / assurance level is generated based on the synchronization level. At 2914, a correlation is performed between the lip movements captured in the video and reference lip movement data collected during the enrollment process of the legitimate user. At 2916, a score / assurance level is generated indicating the degree to which the captured lip movements match the reference lip movements. After 2917, 2915, and / or 2916, the resulting score is combined with the results from 2905 and 2906 to generate a final assurance level at 2907. As described above, if the combined result is sufficient at 2907, then the transaction is permitted at 2909. If not, then at 2908 additional authentication techniques may be required.

[0379] Although Figure 29A -B is shown as parallel operations 2903 / 2905 and 2904 / 2906, but the facial recognition operation 2903 / 2905 can be performed first, and then the eye tracking operation 2904 / 2906 can be performed only if the facial recognition operation obtains a high correlation / assurance level (or vice versa). Similarly, the speech recognition operation 2912 and the lip movement operations 2912 / 1913, 2915 / 2916 can be performed in parallel or sequentially (e.g., until an acceptable assurance level is achieved).

[0380] 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.

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

[0382] 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.

[0383] 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).

[0384] 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.

[0385] 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).

[0386] 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.

[0387] 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.

[0388] When a user's computer is infected by malicious code, one way to protect it from the malicious code is to use anti-virus software (e.g. Even if malicious code has already infiltrated the system, antivirus software will at least warn the user that something bad has happened, thereby limiting the ultimate damage. The user can change their account passwords and review recent transactions. However, if antivirus software is not installed, or if 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 carry a higher risk of fraud. Web browsers 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, to determine the status of updates and / or operation of the antivirus software.

[0389] Another defense method, especially in terms of defending 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. The open ports that would normally serve any request sent 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.

[0390] 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.

[0391] 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 verification is being performed, so that the client risk can be assessed when performing verification.

[0392] like Figure 30As shown, 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. Thus, 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 ability to access 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. Thus, even though it may be implemented within a browser environment, the validation engine 3010 will still be able to access the additional risk analysis provided by the client-side risk assessment agent 3004 (though it should be noted that the validation engine 3010 need not be implemented within a browser context while still conforming to the underlying principles of the present invention).

[0393] 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 underlying verification techniques described herein.

[0394] 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 high enough, 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.

[0395] 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.

[0396] 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.

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

[0398] 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.

[0399] Various other sensors 3043, such as temperature sensors, humidity sensors, and accelerometers, may be used to collect data relevant to user authentication. For example, a temperature / humidity sensor may provide current temperature / humidity, which may be compared to the known temperature / humidity for the location specified by the location sensor. If these values differ significantly, this may indicate that the client device 3000 is being spoofed. The comparison of the claimed location and temperature / humidity may be performed on a remote server (such as described below with respect to FIG. Figure 46A 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.

[0400] like Figure 31 As shown, various types of client configuration data related to risk determination may 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 the client device model, processor name / type, boot ROM version, and management controller version. Operating system data 3102 may include the current operating system version, OS update date, and current boot mode (for example, booting from a hard drive). Application data 3103 may include an indication of whether a firewall is activated, the type and version of the firewall, an indication of whether antivirus software is installed and the current version and updates to virus definition files, an indication of whether the antivirus software is activated (for example, actively monitoring the client device during operation), an indication of the last full 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 an indication of whether the data is stored on the user's persistent storage device (for example, a hard drive, flash memory, etc.) in an encrypted or other secure manner.

[0401] 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).

[0402] 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 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.

[0403] It should be noted that for simplicity, Figure 31 The data in 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, etc. The basic principles of the present invention are not limited to any particular configuration data format.

[0404] like Figure 30As indicated, 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 application programming interfaces (APIs) 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 can be implemented to ensure the security of the configuration data 3050, such as chain of trust techniques and secure zones.

[0405] 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, base client configuration data 3050 is not provided directly to relying parties 3051. Instead, in one embodiment, client risk data is assessed directly on the client device by client risk assessment agent 3004 and the risk value is provided to the assurance level calculation. Relying parties 3051 only need to know whether 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.

[0406] Figure 32 One embodiment of a method for assessing client risk during authentication is shown in FIG. Figures 30 to 31 The system architecture is shown but is not limited to any particular system architecture.

[0407] 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.

[0408] 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.

[0409] 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.

[0410] I. Systems and Methods for Performing Authentication for Local Transactions

[0411] 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.

[0412] like Figure 33 As shown, 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 perform a transaction on a local secure transaction device 3350. Specifically, when a user of client device 3300 wishes to perform 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 a 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.

[0413] 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.

[0414] In addition, if Figure 33 As shown, 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.

[0415] 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.

[0416] 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 to authenticate the client device. For example, in one embodiment, relying party 3351 transmits a barcode to client device 3300 and transmits the corresponding code 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.

[0417] 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 susceptible to tampering. 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.

[0418] In one embodiment, for a cash withdrawal, the user will come to the vicinity of the ATM machine and initiate a remote verification application to verify 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 slot of the ATM.

[0419] 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.

[0420] 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 to the relying party to verify that the legitimate user possesses the client device 3300.

[0421] 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-set to the biometric device).

[0422] In one embodiment, the verification engine 3310 includes an assurance level calculation module 3306 for calculating an assurance level corresponding to the likelihood that a legitimate user possesses the client device 3300. This assurance level can then be used to determine whether a 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 the local secure transaction device 3350. In one embodiment, the relying party 3351 can specify the assurance level required for a given transaction. For example, for a financial transaction involving a large transfer, the relying party 3351 may require a relatively higher assurance level than, for example, a transaction involving access to a user's account.

[0423] 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.

[0424] 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.

[0425] 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 the end user via a keypad, and / or various other types of explicit user authentication devices and / or techniques.

[0426] 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 security perimeter of one or more 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.

[0427] 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 a 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.

[0428] Various other sensors 3343, such as temperature sensors, humidity sensors, and accelerometers, may be used to collect data relevant to user authentication. For example, a temperature / humidity sensor may provide the current temperature / humidity, which may 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 may be performed on a remote server, such as one or more secure transaction servers used by relying party 3351. In another embodiment, an accelerometer on the device may 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.

[0429] Local verification application 3304 may be implemented in a variety of ways while still complying with the underlying principles of the present invention. For example, in one embodiment, local verification application 3304 is designed specifically for relying party 3351. For example, if relying party is a banking institution (e.g., Wells Fargo Bank), )), then the local verification application 3304 may be an application designed specifically by / for this bank. In another embodiment, the same local verification application 3304 may be shared among multiple relying parties, for example as a universal local verification application. Figure 34 are shown as separate logical components, but Figure 34 The verification engine 3310 shown in FIG3 may be integrated within a local verification application 3304. In another embodiment, the local verification application 3304 may be a web browser or an application that executes within a web browser environment (e.g., when a user comes into proximity with a local secure transaction device 3350 or connects to a relying party web page to initiate a transaction).

[0430] 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 a 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).

[0431] Figure 35 One embodiment of a method for performing authentication of a client device is shown in FIG. Figures 33 to 34 The system architecture is shown but is not limited to any particular system architecture.

[0432] 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, when 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.

[0433] 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.

[0434] 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.

[0435] 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.

[0436] 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.

[0437] J. User Confirmation for Online Transactions

[0438] 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.

[0439] 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. Figure 36 , which shows a client device 3600 with remote authentication functionality that is controlled by a user attempting to initiate a transaction with a relying party 3650 with a secure transaction service (hereinafter referred to as a "relying party"). 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.).

[0440] 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.

[0441] 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 in accordance with the underlying principles of the present invention. For example, if client devices 3601-3602 are mobile devices, a push notification 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 a message to client devices 3601-3602.

[0442] 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).

[0443] 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.

[0444] Figure 37 , further architectural details of client devices 3600-3602 employed in one embodiment of the present invention are shown in FIG. 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.

[0445] In addition to coordinating the user confirmation process described herein, in one embodiment, the secure transaction application 3704 also ensures that the text displayed to each user is the actual text related to the transaction. For example, the application 3704 may display the text in a secure window and require the user to provide verification 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 in 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.

[0446] 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.

[0447] The above techniques may be implemented for transaction requests / confirmations originating from client device 3600 as well as for approved transactions originating from users of client devices 3601-3602. Figure 37In one embodiment, authentication can be performed via an authentication engine 3710 on a client device 3600-3602, which is designed to perform a series of transactions with a relying party 3650 to remotely authenticate each user. For example, as described in the co-pending application, an authentication framework and associated authentication techniques can be employed in which a user enrolls 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 via a network (e.g., a website equipped with a secure transaction service or other relying party); and subsequently authenticates with 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.

[0448] 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. Additionally, 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.

[0449] In one embodiment, the verification engine 110 includes an assurance level calculation module 3706 for calculating an assurance level corresponding to the likelihood that a legitimate user possesses the client device 100. It can then use this assurance level to determine whether the relying party 3650 should authorize the current transaction. In one embodiment, the relying party 3650 can specify the assurance level required for a given transaction. For example, for financial transactions involving large transfers, the 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.

[0450] 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).

[0451] In one embodiment, communications between client devices 3600-3602 and relying party 3650 are protected 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.

[0452] 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 the end user via a keypad, and / or various other types of explicit user authentication devices and / or techniques.

[0453] 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 security perimeter of one or more 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.

[0454] 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.

[0455] Various other sensors 3743 (such as temperature sensors, humidity sensors, and accelerometers) can be used to collect data related to user verification. For example, a temperature / humidity sensor can provide the current temperature / humidity, which can be compared with the known temperature / humidity of the location specified by the location sensor. If these values are significantly different, this may 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 one or more secure transaction servers used by the relying party 3650). In another embodiment, an accelerometer on the device can be used to measure the user's gait and compare these measurements with 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.

[0456] 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.

[0457] Figure 38 A method according to one embodiment of the present invention is shown in FIG. 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 by one or more parents or guardians. At 3801, the user is also authenticated by implementing one or more authentication techniques described herein.

[0458] 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, a notification 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.

[0459] 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.

[0460] 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).

[0461] 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.

[0462] K. Systems and Methods for Delegating Trust

[0463] 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.

[0464] 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 one or more authenticators on a new client device. Specifically, these embodiments can be used to enable new authenticators, enable new client devices, and keep registrations synchronized across multiple client devices.

[0465] Figure 39 A high-level overview of trust delegation in accordance with one embodiment of the present invention is provided. 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 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.

[0466] 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.

[0467] 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).

[0468] like Figure 40As shown, 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 a 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 a relying party, 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.

[0469] 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.

[0470] Return to Figure 40 In one embodiment, a user initiates a trust delegation application 4000 on a new client device 3900 and a trust delegation application 4001 on a trusted client device to establish an initial secure connection. In one embodiment, the trust delegation application may be a mobile device application 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 a 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). Additionally, the trust delegation applications 4000 to 4001 may be software modules within a larger application, such as an authentication application designed to manage authentication 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.

[0471] 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.

[0472] 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.).

[0473] 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 the trust delegation application 4000 sends these N new device public keys to the trust delegation application 4001 on the trusted device 3902.

[0474] 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 the specific registration performed 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 that identifies 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.

[0475] 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.

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

[0477] Specifically, in one embodiment, the secure transaction service 4004 of the relying party 3950 detects the presence of registered content on the new client device 3900 that uses a remote authentication protocol supported by the secure transaction service 4002 and the trust delegation application 4000. In one embodiment, the 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 the new client device 3900. Additionally, at this stage, the secure transaction service 4004 may verify the timestamp inserted into one or more signatures and ensure that the timestamp is no older than a threshold amount of time.

[0478] 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:

[0479] 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 (e.g., using the relying party's public key).

[0480] 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.

[0481] 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).

[0482] 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.

[0483] In one embodiment, upon receiving the above assertion, the secure transaction service 4004 may perform the following verification:

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

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

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

[0487] 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.

[0488] Figure 41 One embodiment of a method for securely transferring registration data from a trusted device to a new device is shown in Figure 42 One embodiment of a method for verifying registration data to a relying party is shown in Figures 39 to 40 The present invention is implemented within the context of the illustrated system architecture, but the underlying principles of the invention are not limited to any particular system architecture.

[0489] First go to Figure 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 can be the number of key pairs that the trusted device has registered with the relying party.

[0490] 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 one or more local secure databases used by the verification engine.

[0491] Now go to Figure 42, at 4201, the new client (having executed Figure 41 At 4202, the relying party detects that there is 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 may then verify using one or more biometrics or other verification techniques. As discussed above, at 4204, the new device prepares a response that 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 trusted device's private key and an 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 that the user is attempting is approved.

[0492] 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.

[0493] 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.

[0494] L. Systems and methods for privacy-enhanced data synchronization

[0495] 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.

[0496] 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.

[0497] 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.

[0498] 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 for 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.

[0499] 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.

[0500] One embodiment of the present invention includes a protocol and associated techniques for allowing new user devices to (a) join a circle and (b) subsequently synchronize with the circle. Figure 43 Describing these embodiments, the figure shows three client devices 4301 through 4303, each having a privacy sync application 4311 through 4313, respectively, for implementing the protocols and techniques described herein, and secure data storage devices 4321 through 4332 for storing data used for joining and syncing. 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.

[0501] In one embodiment, joining and synchronization are performed via a circle cloud 4350 comprising a plurality of 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.

[0502] a. Join the circle

[0503] 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.

[0504] Figure 44 4 shows one embodiment of a method for authorizing a new device 4302 using a trusted device 4301. 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.

[0505] 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, WifiDirect, using a Quick Response (QR) code, and establishing an HTTPS connection.

[0506] 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.

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

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

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

[0510] 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).

[0511] Return to Figure 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.

[0512] 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 (e.g., 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 d1 priv. In one embodiment, trust-block2 also includes a timestamp (T). Device 4301 then sends the above data including trust-block2 to circle cloud 4350.

[0513] 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.

[0514] b. Synchronize with circles

[0515] 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.

[0516] Chain of Trust

[0517] For example, the process of "joining a circle" ( Figure 44 ), what enters trust chain 4360 is evidence asserting that device 2 is trusted by device 1. Thus, 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.

[0518] 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.

[0519] 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.

[0520] 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.

[0521] Circle Channel

[0522] In one embodiment, implementing Figure 45 The process shown is for synchronizing data between other devices in the same circle. In the illustrated example, device 4301 (d1) is the 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.

[0523] 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.

[0524] 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:

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

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

[0527] 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).

[0528] 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.

[0529] 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:

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

[0531] E(REK,data-to-be-synced)

[0532] 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.

[0533] 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, syncing data between devices as described may not require user authentication.

[0534] 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.

[0535] 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:

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

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

[0538] • 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.

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

[0540] • 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.

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

[0542] • 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.

[0543] • 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.

[0544] • 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.

[0545] An application that uses the described proprietary synchronization protocol in conjunction with embodiments of the present invention to perform user-controlled trust delegation to new devices, thereby sharing new registration content between the user's devices, without the user having to authenticate to a verifier each time a new registration content is delegated to another device.

[0546] 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.

[0547] M. Exemplary System Architecture

[0548] 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 may perform the underlying authentication techniques described herein). The secure transaction server may be owned and / or under the control of the relying party, or it may 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 discussed below. Figures 46A to 46B As enumerated in FIG. 4 , these figures illustrate that “relying parties” may include websites 4631 and other web services 4651 , as well as secure transaction servers 4632 - 4633 for performing authentication techniques on behalf of the websites and web services.

[0549] Specifically, Figures 46A to 46B Two embodiments of a system architecture including client-side and server-side components for authenticating a user are shown. Figure 46A The illustrated embodiment uses a browser plug-in based architecture to communicate with the website, while Figure 46B The illustrated embodiment does not require a browser. The various advanced authentication techniques and associated applications described herein can be implemented on any of these system architectures. For example, the authentication engine (e.g., 230) within the client device described above can be implemented as part of the secure transaction service 4601 including the interface 4602. However, it should be noted that the embodiments described above can be used with other systems other than Figures 46A to 46B The present invention may be implemented by a logical arrangement of hardware and software other than those shown.

[0550] Go to Figure 46A , the illustrated embodiment includes a client 4600 equipped with one or more authentication devices 4610 to 4612 for enrolling and authenticating end users. 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).

[0551] Although secure storage 4620 is shown outside the secure perimeter of one or more 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).

[0552] 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).

[0553] 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).

[0554] 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.

[0555] The secure transaction servers 4632 to 4633 are coupled to the secure transaction database 4640 to store user data, authentication device data, keys, and other security information required to support secure authentication transactions as described below. However, it should be noted that the basic principles of the present invention do not require the separation of Figure 46A 4630. For example, website 4631 and secure transaction servers 4632-4633 may be implemented within a single physical server or separate physical servers. Additionally, 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.

[0556] As mentioned above, the basic principle of the present invention is not limited to Figure 46A The browser-based architecture shown. Figure 46B An alternative implementation is shown in which a standalone application 4654 utilizes functionality provided by secure transaction services 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.

[0557] exist Figures 46A to 46B In either embodiment shown, the secure transaction servers 4632-4633 can generate keys that are then securely transmitted to the secure transaction service 4601 and stored in a verification device within the secure storage 4620. In addition, the secure transaction servers 4632-4633 manage a secure transaction database 4640 on the server side.

[0558] Figures 47 to 51A series of exemplary transactions for performing authentication device discovery, registration, enrollment, and authentication are shown in FIG. 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.

[0559] The following operations include: Verification of the device ( Figure 47 ); User registration through verification device ( Figure 48 ); Verify device registration ( Figure 49 ); User authentication through a registered authentication device ( Figure 50 ); and the implementation of secure transactions after verification ( Figure 51 ).

[0560] Figure 47 A series of transactions is shown 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 assess which device(s) are best suited for use with the enhanced security infrastructure. Only server 4730 screens the list of authentication devices. This list will be presented to the user, who can select one (or a group of) authentication devices to use for further authentication and secure transactions.

[0561] 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.

[0562] 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.

[0563] 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.

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

[0565] Once a device is detected, a registration operation can be initiated. The user can choose to use one or a group of discovered devices for enhanced security. In operation, the user can select a device from a list of devices displayed in a browser, application, or mobile device application. Figure 48 In the browser-based implementation shown, the secure transaction plug-in 4705 displays a device-specific registration graphical user interface (GUI). The secure transaction plug-in 4705 transmits the device identifier and registration request to the secure transaction service 4701 and waits for completion. If the user has 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 the device interface 4702). The user then interacts with the secure transaction plug-in 4705 GUI and follows the specified registration steps (e.g., swiping a finger, speaking into a microphone, taking a photo, etc.). Once completed, the user will be registered with the authentication device. It is worth noting that 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.

[0566] Figure 49A series of transactions for registering an authentication device is shown. During registration, keys are shared between the authentication device and one of the secure transaction servers 4732-4733. The keys are stored in secure storage 4720 of the client 4700 and in a secure transaction database 4720 used by the secure transaction servers 4732-4733. In one embodiment, the keys are symmetric keys generated by one of the secure transaction servers 4732-4733. However, in another embodiment discussed below, asymmetric keys 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), one or more keys 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).

[0567] Secure key provisioning protocols such as Dynamic Symmetric Key Provisioning Protocol (DSKPP) can be used to share keys with clients 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.

[0568] Go to Figure 49 In the specific details shown, 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.

[0569] Figure 50 Shown is 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.

[0570] Go to Figure 50In the specific details shown, the figure shows a browser-based implementation in which a user enters the uniform resource locator (URL) of a server 4730 into a browser 4704. In implementations using a stand-alone application or a 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.

[0571] 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.

[0572] Figure 51 A secure transaction after verification is shown 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 want to conduct and conducts the transaction exactly as they see it displayed in the GUI. In other words, this embodiment ensures that a "man-in-the-middle" cannot modify the transaction text to conduct a transaction that the user has not confirmed.

[0573] 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.

[0574] 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.

[0575] 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.

[0576] 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.

[0577] 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.

[0578] System and method for secure query policy for determining client authentication capabilities

[0579] 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.

[0580] 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.

[0581] Figure 52 One embodiment of a client-server architecture for implementing these techniques is shown. As shown, secure transaction service 4701 implemented on client 4700 includes policy filter 5201, which is used to analyze the policy provided by server 4730 and identify 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 environment 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.

[0582] Figure 52 The particular implementation shown in FIG4 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.

[0583] 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.

[0584] Using the authentication data extracted from secure storage 5220 and the policy provided by the server, policy filter 5201 may then identify a subset of authentication functions to use. Depending on the configuration, policy filter 5201 may identify the full list of authentication functions supported by both the client and the server, or may 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 may identify to the server the entire subset of common authentication functions: A, B, and C. Alternatively, if a higher level of privacy is desired, such as in Figure 52 A more limited subset of authentication functions may be identified to the server if indicated by user preferences 5230. For example, the user may 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 may establish a prioritization scheme for all authentication functions of the client 4700, and the policy filter may select the highest priority authentication function (or prioritized group of N authentication functions) that is common to both the server and the client.

[0585] Depending on which operation (registration or verification) is initiated by the server 4730, the secure transaction service 4730 performs the operation on the selected verification 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 FIG. Figure 52 Alternatively, in an embodiment that does not rely on the plug-in 4705 component of the web browser, the information can be passed directly from the secure transaction service 4701 to the server 4730.

[0586] Figure 53 A transaction diagram is shown that illustrates additional details of a series of exemplary registrations using query strategy transactions. 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 authentication 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.

[0587] 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.

[0588] 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.

[0589] 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.

[0590] The techniques described above for filtering server policies at the client can be implemented at various stages of 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 present invention are not limited to Figure 53 The set of specific transactions and the specific order of transactions stated.

[0591] Furthermore, as previously mentioned, a browser plug-in architecture is not necessarily required in order 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 mobile device application), Figure 53 The transaction graph shown (and the rest of the transaction graphs disclosed herein) can be simplified such that the browser 4704 is removed and the secure transaction service 4701 communicates directly with the server 4730.

[0592] System and method for efficient enrollment, registration, and authentication using multiple authentication devices

[0593] One embodiment of the present invention enables simultaneous registration, enrollment, and authentication of multiple devices, improving efficiency and user experience. For example, rather than requesting registration and authentication 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 authentication purposes, several tokens / devices can be selected simultaneously for a given transaction.

[0594] Figure 54 One embodiment of a client-server architecture for implementing these technologies is shown. 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 enrolling multiple devices at a time without the need for continuous back-and-forth communication with the server 4730 when enrolling / enrolling each device. Similarly, the server 4730 includes multi-device processing logic, which is used to issue commands directed to multiple verification 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.

[0595] As in the embodiment described above, Figure 54 The particular implementation shown includes a secure transaction plug-in 4705 for establishing communications 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.

[0596] 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.

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

[0598] Go to Figure 55A In the registration process, at 5501, a 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 a fingerprint sensor, speaking into a microphone, taking a photo with a 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 the client 4700 and accessible only through the secure transaction service 4701. Once registration for all N devices is complete, a notification may be sent to the server 4730 via transactions 5504 to 5505.

[0599] Regardless of how registration is performed, once completed, you can use Figure 55B , registering N devices with server 4730 using the transaction diagram shown in . At 5510, server 4730 generates a user-specific random challenge, which, as previously described, 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.

[0600] 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 via the secure connection. However, the underlying principles of the present invention are not limited to any particular key provisioning technology. 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.

[0601] 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.

[0602] In one embodiment, the keys registered with each authentication device are symmetric keys. Thus, 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, where one key is maintained as a public key in the secure transaction database 4720 on the server, and the private key is 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 encryption key.

[0603] Figure 55C , 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 (used to verify the client's identity). The server 4730 can then store the registrations in the secure transaction database 4720, as described above.

[0604] System and method for processing random challenges within an authentication framework

[0605] 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 random number. 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).

[0606] 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 can then use it 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.

[0607] Figure 56A One such embodiment is shown for use within the context of a registration process, and Figure 56B The embodiment is shown to be used within the context of a verification process. However, it should be noted that the basic principles of the invention can be used in other Figures 56A to 56B The present invention may be employed in other environments than those shown. For example, the techniques described herein may be used with any process that transmits time-sensitive code from a server to a client.

[0608] First go 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 ...

Claims

1. A system for binding verifiable claims, comprising: Client device; an authenticator of the client device, the authenticator being configured to securely store authentication data, the authentication data comprising one or more verifiable claims received from one or more claims providers, each verifiable claim having attributes associated with the verifiable claim, wherein the authenticator is configured to perform a key derivation operation based on a master secret key and a claims provider public key of a claims provider to generate a secret key; claim / attribute processing logic of the verifier, the claim / attribute processing logic being configured to generate a first verifiable claim binding for a first verifiable claim issued by the claim provider, the verifier receiving the first verifiable claim via secure communication established with the claim provider using the private key, wherein the verifier is configured to transmit a first signed assertion to a first relying party for verification with the first relying party, the first signed assertion including an attribute extension, the attribute extension containing data associated with the first verifiable claim binding; and Blockchain validation logic of the validator, the blockchain validation logic to validate blocks of a blockchain, wherein the validator includes a new validator to use blockchain entries to allow verifiable claims issued for an older validator to be transferred to the new validator.

2. The system of claim 1 , wherein the verifier further comprises signature generation logic for generating a first signature on the first verifiable claim issued by the claim provider, the claim / attribute processing logic for including the first signature in the attribute extension.

3. The system of claim 2, further comprising: Verification logic of the first relying party, the verification logic being operable to verify the first verifiable claim at least in part by verifying the first signature.

4. The system of claim 1 , wherein the claim / attribute processing logic is further configured to generate a second verifiable claim binding for a second verifiable claim issued by the claim provider; The verifier is configured to transmit the second signed assertion to a second relying party for verification to the second relying party, wherein the second signed assertion includes an attribute extension, and the attribute extension contains data associated with the second verifiable claim binding.

5. The system of claim 4, wherein the first verifiable statement and the second verifiable statement comprise statements that a user of the client device is associated with a particular online entity or other organization.

6. The system of claim 1, wherein the claim / attribute processing logic includes direct anonymous verification logic for communicating with the claim provider according to a direct anonymous verification protocol.

7. The system of claim 6, wherein the direct anonymous authentication protocol comprises elliptic curve direct anonymous authentication.

8. The system of claim 7, wherein the verifier is configured to maintain privacy when communicating with different claim providers using different elliptic curve direct anonymous verification private keys.

9. The system of claim 1, wherein the validator is configured to perform a join operation comprising transmitting a join request to the claims provider.

10. The system of claim 9, wherein the join operation is performed according to an enhanced elliptic curve direct anonymous verification join protocol.

11. The system of claim 1 , further comprising: A verification module of the authenticator or coupled to the authenticator, the verification module being configured to generate a signature using the block and a private key, the signature being usable by a device having a public key corresponding to the private key to verify the authenticity of the block.

12. A method for binding a verifiable claim, comprising: performing, at the verifier, a key derivation operation based on the verifier's master secret key and the claims provider public key of the first claims provider to generate a secret key; receiving, at the verifier, a first verifiable claim from the first claim provider using the secret key via secure communication established between the verifier and the first claim provider; securely storing verification data on a client device, the verification data comprising one or more verifiable claims received from one or more claims providers, including the first verifiable claim issued by the first claims provider, each verifiable claim having attributes associated with the verifiable claim; generating, on the client device, a first verifiable claim binding for the first verifiable claim issued by the first claim provider; transmitting a first signed assertion to a first relying party for verification with the first relying party, the first signed assertion including an attribute extension containing data associated with the first verifiable claim binding; Validating blocks of the blockchain by the blockchain validation logic of the validator; as well as Blockchain entries are used to allow verifiable claims issued for that validator to be transferred to a new validator.

13. The method of claim 12, further comprising generating a first signature on the first verifiable claim issued by the first claim provider and including the first signature in the attribute extension.

14. The method according to claim 13, further comprising: The first verifiable claim is verified by the first relying party at least in part by verifying the first signature.

15. The method of claim 12, further comprising generating a second verifiable claim binding for a second verifiable claim issued by the first claim provider; The verifier is configured to transmit the second signed assertion to a second relying party for verification to the second relying party, wherein the second signed assertion includes an attribute extension, and the attribute extension contains data associated with the second verifiable claim binding.

16. The method of claim 15, wherein the first verifiable statement and the second verifiable statement comprise statements that a user of the client device is associated with a particular online entity or other organization.

17. The method of claim 12, further comprising communicating with the first claim provider according to a direct anonymous attestation protocol.

18. The method of claim 17, wherein the direct anonymous authentication protocol comprises elliptic curve direct anonymous authentication.

Images