Extending secure key store for transaction confirmation

Abstract

The invention relates to extending secure key storage for transaction confirmation. For example, one embodiment of a system includes: a verifier on a client device, the verifier to securely store one or more private keys, at least one of the private keys being available to verify a block of a blockchain; and a validation module of or coupled to the validator for generating a signature using the block and the private key, the signature being usable by a device having a public key corresponding to the private key to validate the authenticity of the block.

Description

[0001] Information about divisional applications

[0002] This application is a divisional application of the Chinese invention patent application with application number 201880076556.5, application date November 27, 2018, and invention name “Extended secure key storage for transaction confirmation”. Technical Field

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

[0004] Figure 1 An exemplary client 120 with a biometric device 100 is shown. In 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 of 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 the biometric reference data 110 stored in a secure storage device 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 the authentication is successful (e.g., whether the score is above a certain specified threshold).

[0005] Systems that use biometric sensors to provide secure user authentication over a network have also been designed. In such systems, the score 135 and / or other authentication data generated by the application 105 can be sent over the network to authenticate the user to a remote server. For example, Patent Application No. 2011 / 0082801 (“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 in transactions), and registration / management of client authentication tokens (e.g., fingerprint readers, facial recognition devices, smart cards, trusted platform modules, etc.).

[0006] The assignee of the present application has developed a number of 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 13 / 730,795, entitled “System and Method for Implementing Transaction Signaling Within an Authentication Framework.”

[0007] In short, in the authentication techniques described in these co-pending applications, a user registers 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 registration 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 a user) can be kept locally on the user's client device (e.g., a smartphone, laptop, etc.) to protect the user's privacy.

[0008] 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 intended to authenticate a user at a given point in time. Additionally, "silent" authenticators may be used to authenticate a user's device (rather than the user) at a given point in time. These silent authenticators may rely on information extracted from the user's device and do not require user interaction (e.g., sending a machine ID).

[0009] 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) do not adequately confirm that the device is still in the possession of the legitimate user.

[0010] 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". Some of these methods have even been adopted by the 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 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 by the user).

[0011] However, there is a problem that providing location data or other personal data (e.g., facial image, clothing color, gait or typing characteristics…) or environmental data (e.g., temperature, humidity, WLAN SSID…) directly to the relying party to supplement the risk assessment violates the privacy of users 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.

[0012] 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 the authentication is performed (e.g., the machine being used, the network the machine is connected to, etc.) It would be advantageous to select and / or combine authentication modalities based on the currently detected risk.

[0013] When thinking about increasing the assurance level of authentication, we think of typical ways to increase the level of explicit authentication methods, such as requiring the use of more complex passwords, or using more accurate biometric methods, 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 (e.g., authenticating in San Francisco at 1 pm and authenticating in Tokyo at 2 pm on the same day seems unrealistic for a person).

[0014] Passwords are still the main explicit authentication method. Unfortunately, passwords are vulnerable to attacks and those attacks are scalable. In addition, entering passwords is cumbersome, especially on small devices such as smartphones. As a result, many users do not use password-based protection methods to lock their phones at all, or they use trivial PIN codes.

[0015] Some smartphones are using fingerprint sensors to provide a more convenient means of authentication. The use of biometric forms of authentication has been criticized for not providing adequate resistance to spoofing attacks and for introducing privacy issues due to the potential failure to properly protect the biometric reference data.

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

[0017] 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 location may require less authentication than a transaction from a Starbucks located in a remote area where the company has no business.

[0018] However, reliable location data may not be readily available for a variety of reasons. For example, an end user's device may not have GPS capabilities; the user may be located in a location where Wifi triangulation data is unavailable or unreliable; or a network provider may not support the provision of cell tower triangulation capabilities to augment GPS or WiFi triangulation capabilities. Other methods for inferring device location may not have sufficient assurance levels to meet the needs of an organization; 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 mask the true network origin of a user's device.

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

[0020] Another challenge for organizations deploying authentication is matching the “strength” of the authentication mechanism to the inherent risk 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.

[0021] Until now, organizations have had to rely on a fairly static response to the need for user authentication: the organization assesses the risks that users will face during the course of normally performed operations, as well as the mandates of any applicable regulations, and then deploys authentication schemes to protect against the risks and achieve compliance. To do this, organizations often need to deploy multiple authentication schemes to address the diverse range of risks that different users may face, which can be extremely expensive and cumbersome to manage.

[0022] The technology described in the co-pending application provides an abstraction that allows an organization to identify existing capabilities on a user device that can be used for authentication. This abstraction eliminates the need for an organization to deploy multiple different authentication schemes. However, the organization still needs a way to invoke the "correct" authentication mechanism when necessary. Existing implementations do not provide organizations with the ability to describe what 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 code changes in the future to use new authentication devices / tokens.

[0023] Today, electronic financial transactions are primarily conducted over the World Wide Web using browser applications. Websites such as Amazon.com, Dell, and Walmart sell billions of dollars of merchandise through their online portals, while banks and brokerages allow their customers to transfer billions of dollars between accounts online. One challenge these websites and others face is how to detect fraudulent activity. Fraudulent transactions can cost these companies billions of dollars.

[0024] The first line of defense against fraudulent transactions is the user's password. However, criminals can obtain passwords through a variety of techniques. Sometimes, the password is not complex enough and can be easily guessed or determined through brute force attacks. And sometimes, malware, worms, or viruses infect the user's computer. Then, the password can be obtained by logging keystrokes or scanning memory or hard disk storage devices. If the actual device is stolen, the password can be retrieved from the data retained in the memory or storage device. Once the password is compromised, the criminal can access the account and withdraw or transfer funds.

[0025] In an effort to prevent losses due to compromised user passwords, websites that process financial transactions employ risk assessments in which various metrics are used to determine whether the person initiating the transaction is actually the user who owns the account. Factors such as the time of the transaction, the location of the transaction, and the environment of the transaction are all good ways to assess whether a transaction is risky. For example, if a user does not typically perform any activity on their account at night, they will be less likely to initiate a transaction at 3:00 a.m. than at 3:00 p.m. Similarly, if a user lives in the United States but initiates a transaction in South Korea, this location difference 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.

[0026] Unfortunately, web browsers place very strict restrictions on what information websites can obtain about client systems. Because browsers expose users' machines to the outside (and potentially malicious) world, leaking any data that is not necessary poses a security risk to itself. Of course, it is feasible to record the transaction time, transaction location (e.g., via the user's IP address), and transaction amount. Websites currently use all of this data to determine whether a transaction is fraudulent. However, apart from these basic pieces of information provided by the browser, websites have no other information to use for risk assessment. Due to the restrictions on what information the browser can obtain, the risk assessment of the user's transaction is not very accurate. Summary of the invention

[0027] In one aspect, the present disclosure provides a system comprising: an authenticator on a client device, which is used to securely authenticate a user using the authenticator via biometric input, manual user input and / or by detecting a current condition associated with the client device; and a keystore circuit / logic, which is used to maintain secure storage of private keys, the keystore circuit / logic is used to calculate a digital signature to use a first private key to sign a digital object containing one or more attributes of the authenticator and input data when the user has been authenticated by the authenticator, the signed digital object can be verified by a relying party using a public key corresponding to the first private key, and the pair of the public key and the first private key is associated with the authenticator.

[0028] On the other hand, the present disclosure provides a system for implementing a private or public ledger, comprising: a public key management circuit / logic for receiving, processing and storing a public key and related confirmation statements in response to a user authorization; and the public key management circuit / logic for adding a public key to a record in the private or public ledger identified by a decentralized identifier DID.

[0029] On the other hand, the present disclosure provides a method comprising: securely authenticating a user by an authenticator on a client device via biometric input, manual user input and / or by detecting a current condition associated with the client device; maintaining secure storage of a private key; and calculating a digital signature to sign a digital object containing one or more attributes of the authenticator and input data using a first private key when the user has been authenticated by the authenticator, the signed digital object being verifiable by a relying party using a public key corresponding to the first private key, and a pair of the public key and the first private key being associated with the authenticator. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0032] Figure 2 An implementation of a Non-Intrusive Privacy Preserving Authenticator (NIPPA) is shown;

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

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

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

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

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

[0038] Figure 8 An implementation of an adaptive verification method is shown;

[0039] Fig. 9 graphically illustrating adaptive verification according to one embodiment;

[0040] Fig.10 One embodiment of a composite validator having multiple components is shown.

[0041] Fig.11 An embodiment in which two validators share components is shown.

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

[0043] Fig.13 A transaction diagram is shown, illustrating one implementation of authentication between two components.

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

[0045] Fig.15 A dynamic verifier according to one embodiment of the present invention is shown.

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

[0047] Fig.17 One embodiment of a system for a location-aware application that implements an authentication policy is shown;

[0048] Fig.18 An exemplary set of authentication policy rules is shown;

[0049] Fig.19 A method according to one embodiment of the present invention is shown;

[0050] Fig. 20 An embodiment of the invention is shown wherein location is determined or confirmed by proximity of other peer devices or network devices;

[0051] Fig.21 One embodiment of a system for authentication using an environmental sensor is shown;

[0052] Fig. 22 One embodiment of a method for authentication using an environmental sensor is shown;

[0053] Fig.23 One embodiment of a system for adaptively applying authentication strategies is shown;

[0054] Fig.24One embodiment of a method for adaptively applying an authentication strategy is shown; and

[0055] Fig.25 An exemplary client equipped with a biometric device is shown;

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

[0057] Fig.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;

[0058] Fig. 27 An exemplary heat map showing a web page employed in one embodiment of the present invention;

[0059] Fig.28A -B shows exemplary text, graphics, photos, videos, white space and other content that may be displayed to an end user;

[0060] Fig.29A -B shows an embodiment of a method for performing verification based on eye tracking and facial recognition and verification based on speech recognition and lip movement analysis;

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

[0062] Fig.31 One embodiment of a client architecture including a client risk assessment agent is shown;

[0063] Fig.32 illustrates exemplary types of client configuration data used by the client risk assessment agent;

[0064] Fig.33 One embodiment of a method for performing client risk assessment during authentication is shown;

[0065] Fig.34 One embodiment of a client performing a secure transaction with a local device is shown;

[0066] Fig.35 One embodiment of a client architecture for performing secure transactions with a local device is shown;

[0067] Fig.36 One embodiment of a method for performing a secure transaction with a local device is shown;

[0068] Fig.37 One embodiment of a system for user confirmation of online transactions is shown;

[0069] Fig.38 shows details of one embodiment of a client used in a system for user confirmation of online transactions;

[0070] Fig.39 An embodiment of a method for user confirmation of online transactions is shown;

[0071] Fig.40 One embodiment of a system for delegating trust from a trusted client device to a new client device is illustrated;

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

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

[0074] Fig.43 One embodiment of a system for synchronizing private data between devices is shown;

[0075] Fig.44 One embodiment of a method for adding a device to a circle of trust is shown;

[0076] Fig.45 One embodiment of a method for synchronizing data between devices is shown;

[0077] Fig.46A -B shows different exemplary architectural arrangements in which embodiments of the present invention may be implemented.

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

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

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

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

[0082] Fig.51 is a transaction diagram that shows how transaction details can be verified.

[0083] Fig.52 A query strategy filter implemented according to one embodiment of the present invention is shown.

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

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

[0086] Fig.55A -C shows three embodiments of the present invention for multi-authentication device processing.

[0087] Fig.56A -B shows a transaction diagram for detecting and responding to a random challenge timeout.

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

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

[0090] Fig.59 One embodiment of an architecture for authenticating transactions using signatures is shown.

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

[0092] Fig.62 An embodiment is shown in which a relying party uses metadata to authenticate a client;

[0093] Fig.63 An exemplary architecture including a Keymaster and a validator is shown;

[0094] Fig.64 Another embodiment of an architecture for processing formatted messages is shown;

[0095] Fig.65 An embodiment of storing and processing virtual AppIDs and / or relying party IDs is shown;

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

[0097] Fig.67 A system according to one embodiment of the present invention is shown; and

[0098] Fig.68 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 the purpose of explanation, many specific details are set forth herein to provide a thorough understanding of the present invention. However, it will be readily apparent to those skilled in the art that the present invention may be practiced without some of these specific details. In other cases, to avoid obscuring the basic principles of the present invention, well-known structures and devices are not shown or are shown in block diagram form.

[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." Although 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 a specific implementation 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 boundary of the computer to which it is communicatively coupled (e.g., the biometric sensor is not embedded in the same physical housing as the relying party computer). For example, the biometric device may be coupled to the relying party via a network (e.g., the Internet, a wireless network link, etc.) or via a peripheral input (such as a USB port). Under these conditions, the relying party may not know whether the device is a device authorized 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 physically conducting a transaction at a particular location, such as at an automated teller machine (ATM) or a point-of-sale (POS) retail checkout. However, as discussed below, authentication techniques used to authenticate a user may involve non-location components, such as communications 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 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 may be under the control of a third party that provides secure transaction services to the relying party as part of a business arrangement.

[0104] The term "server" as used herein refers to software executed on one hardware platform (or across multiple hardware platforms) that receives requests from clients via a network, then performs one or more operations in response, and transmits a response to the client, which typically includes the results of the operations. The server responds to client requests, thereby providing or helping to provide network "services" to the client. It is worth noting that a server is not limited to a single computer (e.g., a single hardware device for executing server software), but can actually be spread 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.) In addition, one embodiment returns the authentication status of the device to the relying party when authentication is required, rather than sensitive information such as a machine ID.

[0107] Some embodiments of the invention described below may work completely frictionless (i.e., without requiring any explicit user authentication). Behavioral or other techniques may be utilized to continuously measure an assurance level that indicates current assurance that the device is in the possession of an authorized user. The assurance level may be calculated, for example, based on the time that has elapsed since the last explicit user authentication (e.g., SIM card or phone unlock using a PIN or finger swipe). Assuming the amount of time that has elapsed is within a certain threshold (e.g., 5 seconds, 5 minutes, 1 hour, etc.), the device may be considered to be in a "legitimate user state" and the assurance level 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 may be measured based on a combination of the time that has passed since explicit user authentication and other variables that indicate the device is held by an authorized user (e.g., based on non-intrusive input detected from the device sensors). For example, the user's biometric gait may 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 frequent destinations may be tracked, stored, and subsequently used to determine the assurance level. For example, if the user is connecting to a relying party from a location known to be the user's home or office, the assurance level may be set to a relatively high value, while if the device is connecting from an unknown or remote location, the assurance level may be adjusted to a lower level.

[0109] Various other types of non-intrusive measurements may 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 Wifi device (such as a router or access point), a smart watch, other computing devices, a Nymi bracelet, and the like. Wifi devices may include visibility of Wifi networks within reach, such as a personal Wifi router at home, and Wifi-enabled computers used by co-workers or family members. In addition, certain specific characteristics of the client device, such as accelerometer characteristics and digital camera sensor pattern noise, may be utilized for non-intrusive measurements. Touch screen gestures for normal user interactions may also be analyzed and stored as reference data, and user typing behavior during normal user interactions may be analyzed and stored as reference data. Of course, the above are merely examples; the underlying principles of the invention are not limited to any set of any 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 a 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 dedicated 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 includes a non-intrusive privacy-preserving authenticator (NIPPA) 210, and the non-intrusive privacy-preserving authenticator (NIPPA) 210 includes an assurance calculator 212 for determining a current assurance level based on input from a non-intrusive authentication mechanism 230 (e.g., location, gait measurement, etc.) and one or more explicit user authentication devices 220 to 221 (e.g., fingerprint sensor, input device for entering 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 2 In the illustrated embodiment, non-intrusive authentication 230 includes a location authentication module 231 for performing location-based authentication using a location sensor 241 and historical location data 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, the location sensor 241 may include a GPS device and / or a module for detecting the current access point or cell tower to which the client 200 is connected (which may be used to estimate the current location of the device). Any sensor capable of providing data related to the user's location may be used. The 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 a "home" or "office" location (based on historical location data 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" in one embodiment (as described herein), the user has 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 in the office). The result of the location verification module 231 is provided to the assurance level calculation module 212, in which the result of the location verification module 231 can be included in 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 the historical user behavior (stored in the user and location data storage device 245). For example, the user behavior sensor 242 can provide accelerometer measurements, which the user behavior verification module can use to determine the gait of the user currently holding the device 200. The user behavior verification module can 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 legitimate user is holding the device. The results are provided to the assurance calculation module 212, where they are 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 in Figure 2 2 is shown as a separate module, but the location verification module 231, the user behavior module 232 and any other verification module 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 "legitimate user state" and adjust the assurance measurement value accordingly.

[0118] Once the assurance calculation module 212 derives 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 by a 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 communications 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" state within a defined time window (up to T1 seconds) after each such successful authentication. NIPPA 210 may periodically measure user behavior from various sensors 241 to 243, and when in the "legitimate user" state, NIPPA 210 may update its internal reference data vector based on the measured values. When not in the "legitimate user" state, NIPPA 210 may calculate a standardized "distance" from the reference data vector based on the current measured values. This "distance" is considered as a certainty that the legitimate user still holds the authenticator.

[0121] When asked to authenticate a user, NIPPA 210 may check to determine if it is in the "legitimate user" state. If so, the authentication is deemed successful and the maximum assurance level (e.g., 100) is returned. If not in the "legitimate 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 and 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 (guarantee level>=0), then the obtained guarantee level = guarantee 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 until t1+T1 is considered a "legitimate user" state. As mentioned, a non-intrusive authenticator can be trained within the legitimate 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 legal 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 legal user. After this calculation, the assurance level decreases over time (for example, the legal user may expose the device to illegal personnel). For example, at time t3, the assurance level has become significantly smaller than the value at time t2. In one embodiment, the non-intrusive assurance level is only calculated periodically to avoid consuming too much power and CPU performance.

[0126] At t5, another non-intrusive assurance level calculation occurs. At this time, the result is negative, which indicates 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 illustrated system architectures may be implemented within system architectures such as, but are 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 legitimate 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 it is determined at 404 that an authentication request occurred during the legitimate user state (e.g., resulting from a transaction with a relying party), then 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 to the internal reference data stored in operation 403. For example, a measurement associated with the user's gait (collected while in the legitimate user state) may be compared to the current gait measurement (collected at 407), and a correlation between the two (referred to as the "distance" from the reference data) may 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 based on the time since an explicit verification event. The assurance level is then transmitted to a relying party at 420.

[0130] Go to Figure 5If it is determined at 501 that the assurance level transmitted to the relying party is acceptable for the current transaction with the user, the relying party may send a response to the client device indicating successful authentication. If not, at 503, the relying party may send a response to the client 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 level of assurance required for a particular transaction, and the system will ensure that the required level of assurance is met, possibly using explicit user authentication in cases where 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, for example, GPS) as follows.

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

[0134] The "distance" (d) is then determined using "distance = (distance from current position (Lc) to the nearest center of region (Rn)) / r", where r is the radius of the region. If Lc is within the existing region, this value is less than or equal to 1; if Lc is outside, this value can become very large. The following formula is then used to calculate the guarantee level: Guarantee level = maximum (100-50*floor(d), -100); the value of the guarantee level is in the range of -100 to 100.

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

[0136] like Figure 7As shown, one embodiment of the present invention uses an extended time window in addition to the standard time window of the legitimate user state to update the behavioral reference data (i.e., training the system). Therefore, the complete 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 higher than 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 An 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.). In addition, as in previous embodiments, the assurance calculation module 212 calculates the assurance based on (e.g.,) the time since the last explicit authentication (provided by the timer 211) and / or the authentication data provided by the various authentication modules 230, 222. The secure communication module 213 establishes secure communications with the 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. 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 basic 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. Therefore, although the embodiments of the present invention are described with a "relying party", the basic principles of the present invention can be implemented using a server outside the perimeter of a network operated by a 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.). In addition, 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, but these elements can also be implemented within the client's adaptive authentication module 800 while still complying with the basic principles of the present 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. Available data may include, for example, the geographic location of client device 200 (e.g., derived from an IP address or provided by a mobile network operator), the round-trip latency of packets transmitted between client device 200 and relying party 250, the number of hops for network packets sent between client device 200 and relying party 250, a specific "user-agent" string sent by a 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 negatively correlated to the risk score), which can be used to determine the amount of additional assurance required to authenticate a user for a given transaction.

[0143] In one embodiment, based on the implicit risk score, the adaptive verification module on the relying party 810 or client device 800 determines a set of one or more verification 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 verification module 800, 810 obtains an indication of the required assurance level gain as a parameter. The adaptive verification module 800, 810 then uses this "gain" parameter to determine a set of most convenient verification techniques (non-intrusive 230 and / or explicit 222) to achieve (at least) the required gain. The adaptive verification module 800 may include a formal description of the selected verification technology group in the 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 pebble, or peripherals such as headphones, etc.); behavioral data (e.g., the way the user removes the device from a pocket, typing behavior, gait, etc.); time since the device was in a "trusted" state; and possible 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 verification method. If the device is a smart phone, this may simply be obtaining permission to use the phone (see above). Instead of requiring the user to select a verification method and then requiring the user to perform another explicit verification, the relying party 250 sends an indication of the required assurance level gain to the adaptive authenticator 800, 810, and the adaptive authenticator 800, 810 identifies a set of least invasive verification technologies. The adaptive verification module 800, 810 does not always require explicit (intrusive) user verification (such as entering a PIN or swiping a finger), nor is it based solely on non-intrusive forms. Instead, this 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 the intrusion / deception form may take time. For example, if the user's phone is lost and someone attempts to hack into the phone, it may take a day to capture the fingerprint from the display, make a suitable rubber finger sleeve and then use it to obtain access rights. Therefore, requiring the entry of a PIN after 24 hours or less since the last time it was in a trusted state will be sufficient to resist this type of attack. The next level of attack is the attack that captures the fingerprint before obtaining access rights. These attacks are actually less seen. However, if the relying party 250 needs to resist such attacks, the adaptive verification module 800, 810 may need to consider the presence of location data or other gadgets or peripherals in order to accept biometric forms.

[0147] Fig. 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 this case, the risk value may be set to a relatively high value (or, conversely, the implicit assurance level may be lower). However, if the user happened to have recently explicitly authenticated to the device (e.g., entered a PIN), this would tend to reduce the risk level (or increase the implicit assurance level).

[0149] The assurance level gain may be determined based on the assurance level required to complete the transaction. For example, this may 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 may 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 the user is authenticated using these techniques at 905. If not, then at 907, one or more explicit authentication modalities are implemented, possibly in conjunction with one or more non-intrusive authentication modalities. As mentioned, the least onerous modality to the end user may be selected (e.g., based on user-specified preferences).

[0151] Fig.10 A diagram is shown of how the embodiments of the invention described above may evaluate assurance levels to determine a form of authentication. At time t1, the user performs an explicit authentication (e.g., swipes a finger, enters a PIN, etc.). At time t2, the relying party requires 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 there is no need to trigger an explicit authentication.

[0152] In contrast, at time t4, the relying party requires authentication with an assurance level gain of al4. The non-intrusive authentication form will only achieve al5 at that time (as shown). Thus, in this case, the adaptive authenticator module will select at least one explicit authentication form to increase the assurance level from al5 to al4.

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

[0154] To address these issues, one embodiment of the present invention uses geographic location as a factor when performing implicit user authentication, but does not disclose the user's location to the relying party. This embodiment can be implemented alone or in combination with other non-intrusive authentication techniques 230 and / or explicit authentication techniques 222 described above (e.g., as part of a larger comprehensive authentication process). Instead of 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 geographic location 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 are typically located when performing authentication to the website. These locations may be areas within a predetermined number of miles or within a specific location (such as office, home, transportation routes, etc.). The selected locations may be stored locally on the client device and not sent to the relying party. These operations may be performed by the location authentication module 231 described above.

[0157] 2. In one embodiment, after registration 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 registration 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 may then put the score into an 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 contain the following security-related functions:

[0164] 1. Store and use cryptographic proof keys

[0165] 2. Generate, store and use password verification 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 you declare support for local user authentication (sometimes called "user authentication"), ensure that:

[0171] (a) authentication cannot be bypassed / forged by a software application (e.g., malware "enters" a PIN into an authenticator); (b) the confidentiality of authentication data is protected (e.g., malware cannot access the user-entered PIN or reference data); and (c) user authentication is required before a new authentication key is generated and a certain amount of time must elapse before such an authentication key can be used.

[0172] One way to implement the authenticator is to implement all components responsible for the above functions 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 when it is executed.

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

[0174] 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 Fig.13 and associated text). In addition, the protection logic may utilize additional hardware / software protection mechanisms built into the client platform (e.g., such as secure elements (SE), trust chain technology, trusted user interface technology, OS-based protection mechanisms, etc.). Details associated with each of these implementations are set forth below.

[0175] Fig.12 An 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 a confirmation key 1215 (for confirming the model and / or integrity of the validator to the relying party as part of the registration process) and a verification key 1216 (for establishing 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 a confirmation key 1215 and a verification key 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.

[0176] Authenticators built from multiple components in this way are called "composite authenticators" because they are made up of separate, independent components that each have their 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, Fig.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 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 algorithm) 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 thus resist hardware-based attacks (e.g., such as differential power analysis (DPA)).

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

[0178] 1. Safety Measures (SM) 1 : In one embodiment, each component (e.g., Figures 12 to 13 The user authentication component 1210, display component 1212, or authentication kernel 1214 shown has its own "component authentication key" pair (CAK) (e.g., CAK pairs 1304, 1305, and 1306, respectively), which is used to register with other components (possibly mutually) and authenticate messages sent to other components. Fig.13As noted, each component 1210, 1212, 1214 includes component authentication logic 1301, 1302, 1303, respectively, for entering into an inter-component authentication transaction using a CAK pair 1304, 1305, 1306, respectively. In one embodiment, the CAK pairs 1304, 1305, 1306 are public / private key pairs, but the underlying principles of the invention are not limited to such specific implementations. In this specific 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 can at least authenticate the public keys) 1321; DC 1212 knows the public keys of UVC and AK 1321; and 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 that must communicate by sharing public keys with those components. The component can then authenticate to those components using the techniques described below.

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

[0180] Fig.141401. It is a transaction diagram showing how verification between two components (AK 1214 and DC 1212) can be implemented. At transaction 1400, the component verification logic 1303 of AK generates a challenge and sends it to the component verification logic 1302 of DC in transaction 1401. In one embodiment, the challenge is a random number or a random number selected by the component verification logic 1303. In operation 1402, the component verification logic 1302 of 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 content of the transaction). As those skilled in the art will appreciate, generating a signature may involve implementing a hash function on the challenge using the private key. At transaction 1403, the component verification logic 1302 of DC sends the signature back to the component verification logic 1303 of AK for verification. The component verification logic 1303 of AK now knows the challenge (e.g., the random number it previously generated), the signature generated using the private key of the CAK pair of DC, and the public key of the CAK pair of DC. In transaction 1404, AK's component authentication logic 1303 uses the public key of DC's CAK pair to verify the signature using the random number, thereby authenticating DC. If mutual authentication is implemented, DC can also use a set of public keys similar to transaction authentication AK 1214.

[0181] 3. Safety Measures (SM) 3 : Depending on the specific implementation, additional security mechanisms may be used to protect communications between components. These additional security mechanisms are described in Fig.13 13 is 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 limit access to the application programming interface (API) of AK to only trusted programs (e.g., such as legitimate UVC and DC). As another example, the operating system can also add a UVC or DC packet identifier to any API call to AK. However, it should be noted that the basic principles of the present invention are not limited to the specific hardware / software protection mechanisms discussed above.

[0182] 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., fingerprint sensor) and trusted applications within a trusted execution environment, both of which utilize 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. Therefore, in this embodiment, when the user swipes a finger on the fingerprint sensor, the trusted application starts and verifies the fingerprint data against the stored reference data. Then, the trusted application sends the score to AK 1214 implemented as a secure element, and then AK 1214 enters a series of verification transactions with relying parties 1320 to verify the user (e.g., as described in the co-pending application).

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

[0184] 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 the large storage requirements and hardware interface requirements of these authentication types. All of these different types of authentication can be implemented in a secure and trusted manner by means of different UVC components utilizing the same AK component (which can be implemented as a secure element as discussed).

[0185] It should be noted that, by using the above method, various components communicate logically using cryptographically protected (e.g., signed) messages. This logical communication can still be "facilitated" by some other entity (e.g., such as the security transaction logic discussed below). In addition, in one embodiment, the inter-logical component messaging described herein is transparent to the relying party 1320, which directly enters into the verification and validation transaction with the verifier kernel 1214 (e.g., using the verification key 1215 and the validation key 1216, respectively). In one embodiment, the AK uses the verification key 1215 to verify the model and / or integrity of the verifier during registration. For example, the relying party may send a challenge that the AK signs using the verification key 1215. The relying party then uses the corresponding key to verify the signature (e.g., if the verification key is a private key, a public key is used). Once the verifier has registered with the 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.

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

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

[0188] Static Composite Validator

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

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

[0191] 1304, 1306); and

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

[0193] Therefore, if Fig.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 authentication keys 215 and also selects a predefined AAID (and associated authentication key) to use when performing transactions with a relying party 1320.

[0194] 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) "confirmation key", an intrusion into a component is not considered equivalent to an intrusion into the authenticator. In addition, 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 that may be similar to an AAID, but is only associated with the AK 1514 (and not with the RP or any other external entity).

[0195] As an additional optimization, in one embodiment, the Online Certificate Status Protocol (OCSP, RFC2560 ) is used as a revocation verification method (e.g., "validation") for each CAK certificate. More specifically, AK 1514 may 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. AK 1514 may also have a single confirmation key for all AAIDs, or AK 1514 may optionally have a confirmation key for each AAID, or a combination thereof.

[0196] 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) if it is 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 specific implementation) or can be verified using some certificate stored in the TrustStore (i.e., linked to such a certificate).

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

[0198] Dynamic Composite Validator

[0199] See also Fig.16 A composite validator 1601 having the following characteristics is a "dynamic composite validator" if:

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

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

[0202] 1614's AAID 1602, 1603 is received as part of the registration message sent from AK 1614. Fig.16 Only UVC 1610 and AK 1614 are shown, but alternative embodiments such as Figure 31604 and 1615 respectively. As mentioned, the registration message sent to RP 1320 also has multiple (linked) signatures, one of which has the confirmation key 1605 of AK, and each of the other components (e.g., the confirmation key 1604 of UCC and the confirmation key of DC (not shown)). As mentioned, in one embodiment, AK 1614 includes the confirmation messages of other components in its confirmation message sent to RP 1320 if and only if the communication with the other components is trusted.

[0203] Therefore, the dynamically constructed 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 specific implementation, in one embodiment, in order 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 authenticated using a direct anonymous authentication (DAA) scheme, which is a cryptographic protocol that implements authentication of a trusted platform while protecting user privacy. Because multiple AAIDs and linked authentication messages are visible to the RP, the specific implementation of the dynamic composite authenticator affects the authentication specifications used between the authenticator 1601 and the relying party 1320.

[0204] UVC / DC Assertion Verification

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

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

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

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

[0209] 1. Find an internal truststore containing a list of acceptable public CAKs. Public CAKs can either be stored directly in the TrustStore, or there can be a separate public key certificate for each CAK that chains to a root certificate in the TrustStore.

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

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

[0212] 4. Verify the revocation status of the certificate containing the public CAK of the UVC or DC. Since the AK is only interested in the revocation information of very few certificates / keys (i.e., the certificates / keys of the current UVC or DC), the Online Certificate Status Protocol (OCSP) (mentioned above) revocation verification can be utilized. Assuming that the AK does not have network connectivity, the OCSP response is expected as part of the incoming data from the UVC and / or DC.

[0213] Optimized verification method

[0214] Further optimizations may be implemented in an embodiment where asymmetric key operations are too expensive compared to symmetric key operations. In this case, the key registration message created by the UVC and / or DC and sent to the AK contains the symmetric key SK (e.g., in place of an empty User Authentication Key field as described above). The modified key registration data message generated by the UVC and sent to the AK may be encrypted using the AK's public CAK (or some other trusted public key belonging to the target component). The modified signature message generated by the UVC and / or DC and sent to the AK is not asymmetrically signed using the CAK, but rather it 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.

[0215] D. Location-aware authentication technology

[0216] 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 used for authentication. For example, the client and / or server may determine the physical location of the client device and feed that location to 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 is consistent with the location definition in the rule.

[0217] like Fig.17 As shown, one embodiment of the present invention includes a client device 1700 having an authentication policy engine 1710, which is used to implement the location-aware authentication policy described herein. Specifically, this embodiment includes a location category determination module 1740, which is used to identify 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" can be defined, including known geographic points and / or areas. The location category data can be continuously updated and stored in a permanent location data storage device 1745 (e.g., a flash storage device or other permanent storage device). The location category determination module 1740 can then compare the current location provided by the sensor 1741 with the defined "category" to determine the current location category of the client device 1700.

[0218] 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 a dotted line from the relying party to the verification policy engine). Thus, the verification policy can be uniquely customized for the verification requirements of each relying party. In addition, the required verification level (as defined by the verification policy) can be determined based on the current transaction. For example, a transaction that requires the transfer of a large amount of money may require a relatively high verification assurance threshold, while a non-monetary transaction may require a relatively low verification assurance threshold. Therefore, the location-aware verification techniques described herein may be sufficient for some transactions, but for some transactions, may be used in combination with more stringent verification techniques.

[0219] 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 technology 1712 to be used for the determined category. By way of example and not limitation, Fig.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. Fig.18 1 is shown as a tabular data structure, but the underlying principles of the invention are not limited to any particular type of data structure to implement the rule set.

[0220] 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 authentication, voice or facial recognition, and retinal scanning, among others.

[0221] Non-intrusive authentication techniques 1742-1743 may include a user behavior sensor 1742 that collects data related to the user's 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.

[0222] In one embodiment, secure storage 1725 is a secure storage for storing verification keys associated with each verification device 1720 - 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.

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

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

[0225] Category 2: Client is located within a specified bounded zone. 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.

[0226] Category 3: Client is outside the specified boundaries. 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, then the associated authentication policy is applied.

[0227] In one embodiment, additional categories are defined using Boolean combinations of the categories and policy rules defined above. For example, Boolean operations AND, OR, NOT, and nesting of Boolean operations allow complex conditions to be expressed. 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.

[0228] A variety of mechanisms can be used to determine the client's current physical location (in Fig.17 Generally represented as position sensor 1741), including but not limited to the following:

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

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

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

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

[0233] Position displacement inference: The exact location of the device may not be known, but the statistical probability of the location may be used as an approximation for the purpose of evaluating the strategy. 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, so that an approximate location can be calculated. Possible methods of 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.

[0234] Fig.19 An 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.

[0235] At 1901, the location of the client 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) of the current location are identified 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 fingerprint scanning, PIN entry, etc.) may be required. At 1904, authentication techniques are employed, and if it is determined at 1905 that the authentication is successful, then at 1906, the transaction requiring authentication is authorized.

[0236] As described above, the required level of authentication may be determined based on the current transaction. For example, transactions requiring 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 may be used in combination with more stringent authentication techniques for some transactions.

[0237] 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 PIN entered by the user is incorrect, the user may be required to re-enter the PIN and / or perform biometric verification.

[0238] 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 the execution of stronger verification 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 a user / client is connecting from an unknown location or an unexpected location. In addition, embodiments of the present invention enable location-aware access to information. Alternatively, a relying party can use a location-centric strategy to provide users with additional access to location-specific information. By way of example and not limitation, when a user located at Wal-Mart logs into his Amazon.com account on his mobile phone, he can be allowed to access specials from Amazon.com.

[0239] As described above, the location of the client device 1700 may be determined using a variety of different techniques. In a 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., Wifi adapter, Bluetooth adapter, LTE adapter, etc.) may always "see" a set of peer network devices (e.g., other computers, mobile phones, tablet computers, etc.) and network infrastructure devices (e.g., Wifi access points, cell phone towers, etc.). Therefore, the presence of these devices may be used to verify when the user is working. Other locations may be defined by the presence of devices in a similar manner, such as when the user is at home.

[0240] For example, using the techniques described herein, a location may be defined as "with my coworkers" or "at work," where the presence of a set of peer devices known to be owned by the user's coworkers may 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 may be considered to be at a lower risk than if no known devices were detected.

[0241] Fig. 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, the 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 towers 2020-2021. As used herein, the client device 1700 can "see" without formally establishing a connection with each other device. For example, the client can see a variety of peer devices connected to the work LAN and / or can see the wireless signals generated by those devices, regardless of whether the client is connected to those devices. Similarly, the client device 1700 can see the basic service set identifiers (BSSIDs) of a variety of different Wifi access points (e.g., Wifi from a nearby hotel, coffee shop, work Wifi access point). The client device 1700 can also see a variety of different cell 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.

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

[0243] 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 that a more stringent verification (e.g., biometric verification, such as a fingerprint scan and / or a request to enter a PIN) be performed.

[0244] In one embodiment, the device proximity detection logic 2001 identifies a set of other devices in the vicinity of the client that have been authenticated. For example, if several of the user's colleagues have successfully authenticated, then 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 companions. In this embodiment, peer-to-peer communications via standards such as 802.11n may be utilized to collect authentication tokens from peer devices that can be used to prove that those peer devices have been authenticated.

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

[0246] In one embodiment, historical device proximity data 2004 is collected and shared between 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 an input to determine the risk of an attempted authentication from a particular location.

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

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

[0249] like Fig.21 As shown, additional sensors 1743 that provide additional assurance about 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 establish correlations with the known supplemental data 2110 related to the location provided by the location sensor 1741 (or the location 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. Fig.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).

[0250] The supplemental data correlation module 2140 may use data provided by the additional sensors 1743 in a variety of different ways to establish correlations with the supplemental location data 2110. For example, in one embodiment, the supplemental location data 2110 includes current local weather conditions at the location provided by the location sensor 1741. The supplemental data correlation module 2140 compares the humidity, temperature, or air pressure collected from the additional sensors 1743 with the real-time local weather data 2110, identifying situations where the sensor data is inconsistent with the 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 the local weather conditions, the supplemental data correlation module 2140 may generate a low correlation score and the location may be considered less trustworthy. Therefore, the verification policy module 1711 may require that a more stringent verification technique 1712 (e.g., fingerprint, PIN entry, etc.) be performed to approve the transaction.

[0251] As another example, the supplemental data correlation module 2140 may compare the altitude provided by the altimeter pressure sensor 2103 to 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 may generate a low correlation score and the location may be considered less trustworthy. Due to the low correlation score, the verification strategy module 1711 may attempt to use stronger verification to mitigate the higher risk of the transaction.

[0252] In one embodiment, the supplemental data relevance 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 that the user is not operating in the same physical location as those known users. For example, if a group of verified users are identified who are operating in the same physical area, and all of those users' devices indicate that the local temperature in the area is 10°C, the supplemental data relevance module 2140 may generate a low relevance score for the end user whose temperature sensor 2101 indicates that the local temperature is 20°C. Thus, the verification policy 1711 may require a more stringent verification technique 1712.

[0253] As another example, the supplemental data correlation module 2140 may compare current readings to historical data for a particular user. For example, as mentioned, the sensor data may 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 may then look for discontinuities 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 require an additional level of scrutiny to be performed on the transaction.

[0254] The supplementary data correlation module 2140 can establish various different types of correlations between the sensor data and the supplementary location data while still complying with the basic 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 (e.g., between 0 and 1) indicating the level of correlation. In one embodiment, various threshold levels can be set for the difference between the detected sensor 1743 and the supplementary location data 2110. For example, if the temperature measured by the temperature sensor 2101 differs from the current temperature (collected from other devices or the Internet) by more than 3 degrees, a first threshold value can be triggered (causing the correlation score to become low). Every additional difference of 3 degrees from the current temperature can then result in a new threshold being met (causing a corresponding decrease in the correlation score). However, it should be noted that these are only examples of one embodiment of the present invention; the basic principles of the present invention are not limited to any particular way of performing correlation.

[0255] Fig. 22 A method according to one embodiment of the present invention is shown in . 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, together 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 the supplemental location data 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.

[0256] At 2203, a correlation is established between the supplemental location data and the sensor data provided by the device sensor. In one embodiment, a relatively high correlation will result in a relatively high correlation score, 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) indicating the similarity between the sensor reading and the supplemental data.

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

[0258] 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 at 2208 the transaction is blocked.

[0259] The above-described embodiments achieve many 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. In addition, embodiments of the present invention can prevent transactions from unauthorized locations, thereby reducing unauthorized access by limiting the locations where users can even attempt to verify. In addition, these embodiments can force the use of stronger verification to respond to location-specific risks (for example, a relying party can minimize the inconvenience of verification when a user is accessing information from a known location, while still maintaining the ability to require stronger verification when the user / client is accessing from an unknown or unexpected location or a location that cannot fully prove authenticity using multiple inputs).

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

[0261] like Fig.23 As shown, one embodiment of the present invention includes an adaptive authentication strategy engine 2345 that allows an organization to - For example, a relying party 1750 with a secure transaction service (hereinafter referred to as a "relying party") - specifies 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.

[0262] In one embodiment, authentication device data 2329 includes data associated with each of 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, as well as technical details about this sensor, such as the manner in which the sensor stores sensitive data (e.g., in cryptographically secure hardware, an EAL 3 certificate, etc.) and the false acceptance rate (indicating how reliable the sensor is in generating user authentication results).

[0263] In one embodiment, the authentication device classes 2328 specify logical groupings of authentication devices 2329 based on their capabilities. For example, a particular 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.

[0264] Various individual attributes may be used to define the authentication device class, such as the type of authentication factor (e.g., fingerprint, PIN, face), the security assurance level of the hardware, the storage location of confidential information, the location where the authenticator performs cryptographic operations (e.g., in a secure chip or secure attachment), and a variety of other attributes. Another set of attributes that may be used is related to the location where the "matching" operation is performed on the client. For example, a fingerprint sensor may capture and store fingerprint templates in a secure storage device on the fingerprint sensor itself, and perform all authentication against those templates within the fingerprint sensor hardware itself, thereby forming a highly secure environment. Alternatively, the fingerprint sensor may be a peripheral device that only captures an image of the fingerprint but uses software on the main CPU to perform all capture, storage, and comparison operations, thereby forming a less secure environment. Various other attributes associated with the specific implementation of "matching" may also be used to define the authentication device class (e.g., whether the match is performed in (or not in) a secure element, a trusted execution environment (TEE), or other form of secure execution environment).

[0265] 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 complying with the underlying principles. Furthermore, it should be noted that a single verification device may be classified into multiple device categories, depending on how the verification device categories are defined.

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

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

[0268] In addition to the monetary amounts involved, interaction categories may also be defined based on the sensitivity of the data involved. For example, transactions that disclose confidential or other private data of a user may be classified as "disclosed confidential interactions," while transactions that do not disclose such data may be defined as "non-disclosed confidential interactions." Various other types of interactions may be defined using different variables and a variety of minimum, maximum, and intermediate levels.

[0269] Finally, a set of verification rules 2326 may be defined that relate to verification devices 2329, verification device categories 2327, and / or interaction categories 2327. By way of example and not limitation, a particular verification rule may specify that for "high value transactions" (as specified by interaction category 2327), only fingerprint sensors (as specified as verification device category 2328) that store sensitive data in cryptographic security hardware that has passed EAL 3 certification 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 verification rule may define other verification parameters that are acceptable. 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 that the user previously provided to the relying party). Rules may be defined using any of the above-mentioned individual attributes specified for the verification device and / or verification device category, such as the type of verification factor (e.g., fingerprint, PIN, face), the security assurance level of the hardware, the storage location of confidential information, and the location where the authenticator performs cryptographic operations.

[0270] Alternatively or in addition, it may be specified in the rule 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 in hardware and performs the calculation in hardware, but does not care about the assurance level of the hardware (as defined by the verification device class 2328 containing a list of verification devices that meet these parameters).

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

[0272] Additionally, a rule or set of rules may be used to create neatly ordered combinations of authentication policies for an interaction. For example, the rules may 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 may also be preferred as the next best alternative (e.g., in order of priority).

[0273] 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 communicate with adaptive authentication policy module 2350 (at Fig.23 The rules are applied by communicating with the client 1700 (shown as a component within the client's authentication engine 2310). The adaptive authentication policy module 2350 can then identify a group of one or more authentication technologies 2312 to comply with the specified authentication policy. For example, if the relying party's adaptive authentication policy engine 2345 specifies a set of prioritized authentication technologies, the adaptive authentication policy module 2350 can select the highest priority authentication technology available on the client 1700.

[0274] The result of the verification technique 2312 is 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 verification engine 2311 of the relying party, which will then allow the transaction.

[0275] In one embodiment, data from the client device sensors 1741-1743 may also be used by the assurance calculation module 2340 to generate an assurance level. For example, a location sensor (e.g., a GPS device) may indicate the current location of the client device 1700. If the client device is in an expected location (e.g., at home or at work), the assurance calculation module 2340 may use this information to increase the assurance level. Conversely, if the client device 1700 is in an unexpected location (e.g., a foreign country that the user has never visited before), the assurance calculation module 2340 may use this information to reduce the assurance level (thereby requiring stricter explicit user authentication to be performed 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.

[0276] Fig.23 The system shown in can operate differently based on the specificity of transmitting the client verification capabilities and other information to the relying party. For example, in one embodiment, the specific model of each explicit user verification 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 verification strategy engine 2345 can clearly identify the required verification mode based on the verification rules implemented for the current transaction and the risks associated with the client. For example, the adaptive verification strategy module 2345 can verify the "validity model 123" fingerprint sensor installed on the client for a given transaction request.

[0277] 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 convey a message 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 one in N. The client device may specify similar general information related to 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 the particular authentication device.

[0278] In yet another embodiment, the client device 1700 does not transmit any data related to its verification capability to the relying party. On the contrary, in this embodiment, the adaptive verification strategy module 2345 communicates the required verification level, and the adaptive verification strategy module 2350 on the client selects one or more verification techniques that meet that verification level. For example, the adaptive verification strategy module 2345 can convey the 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 strategy module 2345 can also communicate the verification category in a prioritized manner. Based on this information, the adaptive verification strategy module 2350 on the client can then select one or more verification techniques 2312 required for the current transaction.

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

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

[0281] 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, a transaction may be associated with a particular interaction category based on variables such as the amount of money involved or the sensitivity of the information involved.

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

[0283] In any case, a set of authentication techniques consisting of one or more authentication techniques is selected based on the requirements specified via the rules and the authentication capabilities of the client at 2405. If the 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).

[0284] Many benefits can be achieved through the embodiments of the present invention described herein. For example, these embodiments reduce the workload required to integrate verification capabilities at the relying party. For example, there is no need to write code to compile verification policies, and the rules can be configured through a simple graphical user interface. All that the relying party needs to do in order to integrate is to define a policy for a class of interactions (e.g., "large transfers") and have the integration code use the policy identifier to determine the correct verification mechanism to utilize when interacting with the policy engine.

[0285] Additionally, these implementations simplify authentication policy management. This approach expresses authentication policy outside of code, which makes 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 effective.

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

[0287] G. Systems and methods for eye tracking during verification

[0288] Generally speaking, authentication techniques are robust against spoofing if (a) they use secret information for authentication or (b) it is 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. Therefore, password attacks often focus on obtaining user passwords. Recent attacks have shown that servers that store authentication passwords are vulnerable.

[0289] In contrast to password-based authentication, when using biometrics for authentication, the biometric information is usually public. For example, a user's fingerprint can be obtained from (almost) any object the user touches. Similarly, a user's face is usually not hidden and can therefore be seen and captured by anyone, and is often published on social networks.

[0290] In the real world, we can rely on our own recognition abilities when looking at a person, because it is difficult to "create" another person with the same biometric characteristics. For example, it is also difficult to "create" another person with the same face and mannerisms. This is why governments put facial pictures 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 deceive the system, just create something (such as a picture of the face) that the computer will recognize. In other words, "this means that biometrics only work when the authenticator can verify two things: one is that the biometric information comes from a person during verification, and the other is that the biometric information matches the master biometric information on file" (see Reference 1 in the list of references provided before the claims of this specification).

[0291] In the past, research into automatic facial recognition has focused on reliably identifying faces using static images and videos. See, for example, Reference 2 below. There are several relatively robust facial recognition technologies 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 defenses are either not needed or are still performed by humans (e.g., in law enforcement applications).

[0292] The popularity of biometric authentication methods, especially facial recognition, has been driven by the ubiquity of cameras in computing devices such as laptops and smartphones and the shortcomings of passwords, the most popular authentication method. 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 fooled using photos (see Reference 4). Although Android 4.1 (also known as "Jelly Bean") uses an improved method that adds some liveness detection, it can still be easily fooled by presenting two photos (one with open eyes and one electronically modified with closed eyes) to the camera in sequence on a computer monitor (see Reference 5).

[0293] Although some may argue that this shortcoming is due to resource limitations on mobile devices, it also shows that commercial software available for PCs, and even research on anti-spoofing detection, is not yet very mature. The assignee of this application conducted tests using PC-based facial recognition software, and the test results showed that:

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

[0295] On Macbook KeyLemon 2.6.5 running on GitHub performs a simple eye-blink test as a liveness check. It can be successfully fooled by showing 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 make it look like they are closed; (3) the real image again.

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

[0297] Fig.25 An exemplary client 2520 with a biometric device 2500 for performing facial recognition is shown. In 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 of 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 a secure storage device 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. The application 2505 can then use the score or "yes / no" result to determine whether the authentication was successful.

[0298] There are multiple potential attack points to deceive facial recognition systems (see references 10, 11). Fig.25 denoted as (1) to (8) in the figure. 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), feature vector (4), 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).

[0299] Protection mechanisms to prevent replaying old captured data to the feature extraction unit (2) are covered in the Trusted Computing Group's approach and in potential extensions to ARM TrustZone (at least in theory). Basically, the approach is to add cryptographic protection mechanisms (e.g., HMAC or electronic signatures) to the sensor and package the sensor in a tamper-proof manner, similar to the protection mechanisms used in current smart card chips. The feature extraction engine can then verify the integrity of the incoming data.

[0300] Although the embodiments of the present invention described below utilize eye tracking techniques to confirm the "liveliness" of the user, in one embodiment, these techniques 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 defense methods against fake biometrics (see Reference 12):

[0301] 1. Data-driven characterization

[0302] a. Still images

[0303] i. Detect resolution loss by rescanning the image and analyzing the 2D Fourier spectrum (Reference 13)

[0304] ii. Utilize the different reflection characteristics of real faces and image prints. The theory is based on the Lambertian reflection characteristics (reference 14)

[0305] iii. Exploiting the different micro-textures of real faces and image prints caused by printing defects (Reference 15).

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

[0307] b. Video

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

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

[0310] (Reference 17).

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

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

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

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

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

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

[0317] Texture Differences

[0318] The effect of printing and rescanning the image can be detected. It is intuitively clear that the image quality does not improve after printing and rescanning. The study in Reference 15 shows that the difference can be detected algorithmically by analyzing the micro texture: "A close look at the difference between a real face and a print of a face shows that the face and the print reflect light differently because the face is a complex non-rigid 3D object, while the photograph can be viewed as a flat rigid object."

[0319] The algorithm has been tested against images included in the NUAA Image Spoofing Database. An average performance of 16.5ms is reported for processing images on a 2.4GHz Intel Core 2 Duo CPU with 3GB RAM using unoptimized C++ code.

[0320] Infrared, not visible light

[0321] 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 incorporated into typical laptops, tablets or smartphones.

[0322] Optical flow based methods

[0323] A real face is a three-dimensional object. Faces usually move during normal conversation. The 2D motion of the central part of the face, i.e. the part closer to the camera, is expected to be higher than the 2D motion of the face area farther from the camera (references 20, 21, 22). For this type of detection, a sequence containing at least 3 consecutive images is required.

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

[0325] Moving pictures, not static images

[0326] A liveness detection method based on blinking is described in reference 23. This method seems to be quite robust against simple photo-based spoofing attacks. In addition to recognizing the face, the method also locates the eyes and checks whether closed eyes can be seen in the observed image sequence. As seen from large-scale experiments on Android 4.1, this method is obviously not very robust against "photoshop" attacks. See reference 5.

[0327] Generally speaking, in order to fool such motion picture-based systems, the attacker must generate a sequence of small images and must present that sequence to the sensor. In a world with powerful image editors, free video editors, and tablet PCs, this is very easy to do.

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

[0329] Scenes and eye blinks were included in the analysis in Ref. 23. The performance was measured to be approximately 50 milliseconds per video frame (20fps) on an Intel Core 2 Duo 2.8GHz with 2GB RAM.

[0330] Challenge Response Method

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

[0332] A method of confirming the presence of a person by eliciting a direct response from the individual. The response 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 the system from attack.

[0333] (National Science and Technology Council's Biometrics Technology Subcommittee)

[0334] Multimodal systems

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

[0336] The impact of simulated spoofing attacks on such multimodal systems was analyzed in Ref. 26. The main result is that not all fusion schemes improve robustness against spoofing attacks, which means that in some fusion schemes, fooling just a single biometric method is enough to fool the entire multimodal system. Analysis of existing schemes using real spoofing attacks yielded similar results. See Ref. 27.

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

[0338] 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 kind of result.

[0339] 2) Systems with the following conditions:

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

[0341] b) Cheating any one feature in this multimodal system is no more complex than cheating the same feature in a unimodal system.

[0342] 3) Systems with the following conditions:

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

[0344] 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 invention described below belong to this category.

[0345] 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 series of random screen layouts that mix text, white space, images, and video clips can be presented to the user to induce eye movements 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. In addition, 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.

[0346] Reading a web page or other content type does not involve a smooth movement of the eyeballs along the content, but involves a series of short 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 intentions, interests, and characteristics. A "heat map" is a collective representation of what area a group of people gaze at when viewing a web page or email (see Hartzell, "Crazy Egg Heatmap Shows Where People Click on Your Website" (Nov 30, 2012)).

[0347] like Fig.26A As shown, one embodiment of the present invention includes a verification 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.

[0348] To perform facial recognition operations, the facial recognition module 2604 relies on facial recognition templates stored in the secure facial recognition database 2646. Specifically, as discussed above, the matching logic within the facial recognition module 2604 compares facial features extracted from the video image 2603 to the facial template data stored in the 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 the database 2646 may be generated by a registration process in which a user registers a facial image or other biometric data with the client device 2600. The score generated by the facial recognition module 2604 may then be combined with scores from other verification modules (e.g., such as the eye tracking module 2605 discussed below) to form an assurance level 2606 that represents the degree of assurance that a legitimate user is initiating the current transaction. In one embodiment, each score must reach a certain threshold in order to generate a sufficient assurance level 2606 for a particular transaction. In one embodiment (assuming the threshold has been reached), the scores may be added or combined using another mathematical formula (eg, the scores may be weighted, averaged, summed, or combined in any other manner).

[0349] 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 described 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 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.

[0350] In one embodiment, the eye tracking module 2605 determines the correlation between the image being displayed (which may include text, graphics, video, pictures, and / or blank areas) and the user's eye movement. 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 eye has 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 eye and the template, resulting in a relatively high score. Conversely, if the user's eye has not moved to this area (or has not moved at all), the eye tracking module 2605 will detect a low correlation, resulting in a corresponding low score.

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

[0352] 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 has 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., may require a higher than usual correlation with the template data to increase the assurance level to an acceptable value for the current transaction).

[0353] In one embodiment, secure storage 2625 is a secure storage device 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).

[0354] Fig.26BAnother embodiment is shown, in which in addition to (or in place of) the facial recognition module 2604 and the eye tracking module 2605, the verification engine 2610 also includes a speech recognition module 2660 and a lip movement analysis module 2670. 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 voice print stored in the voice database 2665. In one embodiment, the voice print is generated during the training / enrollment process, in which the user is prompted to say certain words or phrases. After receiving the digitized audio signal generated by the spoken word / phrase, the speech recognition module 2660 generates the voice print 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 voice prints and comparing the voice prints with captured speech signals, 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.

[0355] 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 words / phrases as those used during the enrollment process, so that the speech recognition module 2660 can compare similar speech features with those captured in the voiceprint.

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

[0357] In addition, one embodiment also includes a lip movement analysis module 2670 that performs analysis on the movement of the user's lips when the user speaks a word / phrase. For example, the lip movement analysis module 2670 can compare the user's video image 2603 when the user speaks a word / phrase, and determine the degree to which the audio stream captured via the microphone 2680 matches the video stream. If the user's lips are not synchronized with the captured audio stream, this can indicate that the current user is deceiving the system (e.g., playing a recording of the legitimate user's voice). In order to determine whether there is synchronization, 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 a period of time when the user's mouth is open (i.e., lips are separated) will produce a larger volume than a period of time when the user's mouth is closed (lips together). Similarly, it would be expected that vowels would be heard during the time when the user's lips are separated, and consonants would be heard during the time when the user's lips are together.

[0358] Additionally, in one embodiment, the lip movement analysis module 2670 may 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 may be captured during an enrollment process where images of the user saying certain words / phrases are recorded and the relevant data is extracted and stored in the database 2675.

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

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

[0361] although Fig.26B Not shown in Fig.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 can be considered to be included in Fig.26B in the implementation scheme.

[0362] Fig. 27 An exemplary "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).

[0363] When designing web pages, perform eye tracking and heat map analysis as part of usability analysis. Studies (e.g., see Refs. 29, 30) have found that web users spend 80% of their time looking at information above the fold of a page. 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 a page and 30% looking at the right half. Therefore, conventional layouts are more likely to make a website profitable.

[0364] 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 related to 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).

[0365] Fig.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 organizations. The grouping may also be part of a screen saver or other application. In one embodiment, text 2805 and images / videos 2801 are displayed simultaneously. In another embodiment, the text is displayed first, followed by images / videos 2801. In either case, it is expected that the user's eyeballs will be directed to the lower right corner of the display 2601 (where the images / videos 2801 are displayed).

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

[0367] In one embodiment, 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 different image / video elements 2800 to 2802 are located are randomly selected. In such cases, the eye movement template can specify a specific operating mode for displaying content, but will not specify the actual content or actual location. Instead, the content and location are selected by the eye tracking module 2605, which will then assume that the user's eyes should be attracted to the content being displayed and generate correlations and scores based on the degree detected.

[0368] 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 that is typically displayed during a transaction may be displayed. In such a case, 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. Fig. 27 as shown) and determine if there is a correlation with the heat map and the location the end user is viewing.

[0369] In summary, the embodiments described herein can present a series of random 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 established between the captured scan path and the expected scan path. Additionally, an embodiment of the present invention can then re-verify that the face is still recognized.

[0370] 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, mysterious symbols, or even mathematical formulas. Accordingly, one embodiment of the eye tracking module 2605 learns the individual-specific features of eye movements triggered by different types of images. The similarity of the measured features from the video image 2603 to the 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, and other content displayed on the display 2601).

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

[0372] First go to Fig.29A , at 2901, a particular 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 eye tracking type, and the eye tracking module 2605 may determine how, where, and when to display the content.

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

[0374] Fig.29B Shows that Fig.29A A series of speech recognition operations and lip movement related operations are performed in parallel. Or, Fig.29A The operations in -B may be performed sequentially (in any order) until an acceptable level of assurance has been achieved.

[0375] At 2911, audio and video of the current user holding the client device is captured and digitized. At 2912, a specific voice print is selected from a voice database (e.g., a voice print previously recorded for the user during the enrollment process), and a voice recognition operation is performed. At 2917, a score / assurance level indicating the correlation between the current user's voice and the voice print is generated. At 2913, the correlation between the digitized audio and the lip movements of the video captured for the current user is determined, 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 the reference lip movement data collected during the enrollment process of the legitimate user. At 2916, a score / assurance level indicating the degree to which the captured lip movements match the reference lip movements is generated. 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.

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

[0377] At 2907, it is determined 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 not permitted at 2908 or additional verification techniques are required to be performed to increase the level of assurance. For example, at this stage, the user may be required to swipe a finger on a fingerprint sensor or enter a PIN associated with the user's account. If it is determined at 2910 that the additional verification techniques are sufficient, the transaction is permitted at 2909.

[0378] H. Systems and methods for collecting and utilizing client data during authentication for risk assessment

[0379] Some types of authenticators are very trustworthy, while others are not. Therefore, a relying party can have a range of assurance levels for an authenticator, and can use certain types of client data to perform a risk assessment (e.g., adjust that assurance level up or down). For example, if the remote authenticator has a secure element or trusted execution environment (TEE), the attestation key can be used to securely sign the attestation. The attestation key remains inside the secure element and is not accessible 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.

[0380] If the remote verifier does not contain a secure element, then attestation signing must be done 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 will sign the verification attempt. However, since the code performing the verification is separate from the white box that performs 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).

[0381] Finally, if none of the above is available, the entire authentication operation can be performed entirely in software. This is the least secure approach because both the authentication code and the attestation key itself can be compromised.

[0382] In any of the above examples, it would be beneficial if a 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).

[0383] 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 when authenticating 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 for risk calculation, (2) how to obtain additional data that cannot be securely provided by a web browser, and (3) how to perform the assessment in a manner that does not compromise the user's privacy.

[0384] 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 does, the website can 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 the update status of the operating system.

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

[0386] Another defense method, especially in terms of worm defense, is a firewall. If a software firewall is installed and enabled on the user's machine, this greatly reduces the number of attack entry points. Open ports that would normally serve any request sent via wires from a random Internet host are weakened. Therefore, even if the service listening on the port has an unpatched security hole, 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. Through port scanning, a web browser can indirectly detect firewalls with limited effectiveness. Therefore, in one embodiment, a native proxy application locates and collects firewall configuration data to determine whether a firewall is installed, and if installed, also determines the update status of the firewall.

[0387] If a user's computer is physically stolen, a large amount of information can be collected by criminals and used 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 have been encrypted and uses this information as part of its risk assessment of the client.

[0388] In addition, as discussed above, if the client uses a secure element or a 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 verifier does not contain a secure element, a software-protected "white box" can be used to protect the verification data (e.g., verification keys). 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 a 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 mode of operation). One embodiment of the present invention allows the relying party to collect the above-mentioned client data to determine the specific way in which the verification is being performed, so that the client risk can be assessed when performing the verification.

[0389] like Fig.30As shown, in one embodiment of the present invention, the client device 3000 includes a client 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 risk assessment agent 3004 is a native code agent application designed to run directly within the native operating system (OS) 3010 of the client 3000. Therefore, the client risk assessment agent 3004 is not subject to the restrictions associated with browser plug-ins and other types of program code, which are limited in their ability to access client data for security reasons. In other words, the client risk assessment agent 3004 is permitted to collect data that HTML and Javascript code running in a browser environment is not permitted to access. Therefore, even though it can be implemented within a browser environment, the verification engine 3010 will still be able to access the additional risk analysis provided by the client risk assessment agent 3004 (although it should be noted that the verification engine 3010 does not need to be implemented within a browser context while still complying with the basic principles of the present invention).

[0390] 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 with a remote relying party 3051 over the network (e.g., such as a financial transaction, an online purchase, access to confidential information in a user's account, etc.). In one embodiment, a 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, a relying party 3051 may require a relatively higher assurance level than, for example, a transaction involving access to a user's email account. Although shown as a single entity, a "relying party" may include a website or other online service equipped with a separate secure transaction server for performing the basic verification techniques described herein.

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

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

[0393] 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 result 3005. Specifically, the user authentication result 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 an end user via a keypad, and / or various other types of explicit user authentication devices and / or technologies.

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

[0395] 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 to generate assurance levels. For example, the sensor 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 possibility that the user is a legitimate user. On the contrary, if the user is in an unexpected location, such as a foreign country that the user has never visited before, this increases the possibility that the user is not a legitimate user. Therefore, in one embodiment, the assurance calculation module 3006 will tend to increase the assurance level when the user is in the expected location and reduce the assurance level when the user is in an unexpected location.

[0396] Various other sensors 3043, such as temperature sensors, humidity sensors, and accelerometers, may be used to collect data related 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 ​​are significantly different, this may indicate that the client device 3000 is being spoofed. The comparison of the claimed location to the temperature / humidity may be performed on a remote server (such as described below with respect to FIG. Fig.46A -B described secure transaction server 4632). In another embodiment, the 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 holds the client device 3000.

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

[0398] 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 result 3005 to derive the 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 a client that has 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 elevated risk to the assurance level calculation module 3006. Risk levels may be specified in a variety of ways while still complying with the basic principles of the present invention. For example, risk levels may be based on percentages (e.g., 0% = minimum risk, 100% = maximum risk, and all numbers between the two represent different levels of intermediate risk) or numerical values ​​on a scale (e.g., 1 = minimum risk, 10 = maximum risk, and all numbers between the two represent different levels of intermediate risk).

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

[0400] It should be noted that for simplicity, Fig.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.

[0401] like Fig.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 may be implemented to ensure the security of the configuration data 3050, such as chain of trust techniques and secure zones.

[0402] One consideration in allowing additional risk information to be provided to a website is not to ignore the rationale for why the browser does not provide this information in the first place. Of course, malicious websites can make full use of this information and web browser developers have good reasons to keep this information from being obtained by malicious websites. Therefore, as mentioned, in one embodiment, the basic client configuration data 3050 is not provided directly to the relying party 3051. Instead, in one embodiment, the client risk data is evaluated directly on the client device by the client risk assessment agent 3004, and the risk value is provided to the assurance level calculation. The relying party 3051 only needs to know whether the verification was successful (if the assurance level was specified in advance) and / or the current assurance level. This protects the client's configuration data 3050 from being disclosed.

[0403] Fig.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.

[0404] 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 higher assurance levels (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.

[0405] At 3204, an authentication technique is selected that, if successfully completed, will raise the level of assurance 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.

[0406] At 3205, it is determined 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 allowed. 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 it is determined at 3207 that the additional verification techniques are sufficient, the transaction is permitted at 3208. If not, the transaction is not allowed at 3206.

[0407] I. Systems and methods for performing verification for local transactions

[0408] Embodiments of the invention described herein include techniques for authenticating a user for a local transaction 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 to purchase goods or services at a retail store or other retail location equipped with a local secure transaction device.

[0409] like Fig.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 the client device 3300 wishes to perform a transaction locally with the secure transaction device 3350, it initiates a series of authentication transactions with the relying party 3351 (an example of which is described below). For example, the user may be required to swipe a finger on a fingerprint reader on the client device 3300 and / or enter a PIN or other password via a client keypad. The result of the authentication may then be transmitted from the client device 3300 to the 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.

[0410] In response to successful authentication, relying party 3351 may transmit a signal to local secure transaction device 3350 to perform an operation. 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.

[0411] In addition, if Fig.33 As shown, a local secure communication channel may be established between the client device 3300 and the local secure transaction device 3350 to supplement the user verification process. The local secure channel may be established using various wireless communication technologies such as near field communication (NFC), Bluetooth, or WiFi (e.g., 802.11x channels), etc., using the wireless communication interfaces on the client device 3300 and the local secure transaction device 3350. For example, when in the vicinity of the local secure transaction device 3350, the client device 3300 may 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.

[0412] 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 as evidence of the current location of the client device 3300 during the authentication process. 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.

[0413] In addition, the relying party 3351 may transmit a password or other authentication data to the client device 3300, which may then forward the password or other authentication data to the local secure transaction device 3350 via a local secure channel to authenticate the client device. For example, in one embodiment, the relying party 3351 transmits a barcode to the client device 3300 and transmits the corresponding code to the local secure transaction device. The local secure transaction device 3350 may then use a barcode scanner or camera to read the barcode (e.g., from the display of the client device 3300) to perform authentication (i.e., compare the code received from the relying party with the code read from the barcode). Alternatively, the local secure transaction device 3350 may transmit the code read from the barcode to the relying party, which will then confirm whether the code matches. Conversely, the relying party 3351 may transmit a password or other authentication data to the local secure transaction device 3350, which will then forward these data to the client device 3300 for authentication. Therefore, the local secure channel can be used to exchange data for a variety of authentication technologies.

[0414] As mentioned, in a specific embodiment, the local security 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 all exposed to the "outside world", and they are susceptible to tampering. For example, debit card records and pins can be easily stolen with low-tech devices (such as hidden magnetic stripe readers, mirrors, and cameras). In one embodiment, a remote verification technology involving communication between a client 3300 and a 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. Verification itself can be performed on the client device 3300 of a customer equipped with a biometric verification device.

[0415] In one embodiment, for cash withdrawal, the user will come near 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 his 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.

[0416] 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 secure transaction server 3351 of the relying party.

[0417] Fig.34 3300. As shown, the client device 3300 of this embodiment includes a local verification application 3304 that communicates with both the local secure transaction device 3350 and the relying party 3351 to coordinate the various local verification techniques described herein. In one embodiment, the local verification application 3304 establishes a local secure channel with the local secure transaction device 3350, and the verification engine 3310 performs remote verification to the relying party to verify that the legitimate user holds the client device 3300.

[0418] In one embodiment, the verification engine 3310 performs verification by entering into a series of transactions with a secure transaction server of a relying party, 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 biometric device of a client to generate biometric template data (e.g., by swiping a finger, taking a photo, recording a voice, etc.). The registration may be performed under the guidance of a secure transaction server of a relying party 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).

[0419] 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 may 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 may specify the assurance level required for a given transaction. For example, for a financial transaction involving a large transfer of funds, the relying party 3351 may require a relatively higher assurance level than, for example, a transaction involving access to a user's account.

[0420] In one embodiment, the assurance level calculation module 3306 transmits the assurance level (e.g., specified as a value, percentage, code, etc.) to the relying party 3351 without disclosing any confidential user information, thereby protecting the user's privacy. In another embodiment, the 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 of whether the transaction is approved or denied to the relying party 3351, again without disclosing the user's private information to the relying party 3351.

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

[0422] 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 current or most recent explicit user authentication via one or more explicit user authentication devices 3320-3321. This may include, for example, fingerprint authentication via a fingerprint device, facial recognition authentication via a camera and facial recognition hardware / software, voice recognition via a microphone and voice recognition hardware / software, retinal scanning using a camera and associated hardware / software, password / PIN entry by an end user via a keypad, and / or various other types of explicit user authentication devices and / or techniques.

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

[0424] 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 to generate assurance levels. For example, the sensor 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 security 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 near the local security 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 when the user is in an expected location and reduce the assurance level when the user is in an unexpected location.

[0425] Various other sensors 3343 (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 can indicate that the client device 3300 is being deceived. The comparison of the claimed location and temperature / humidity can be performed on a remote server (such as a secure transaction server used by the relying party 3351). 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 possibility that the legitimate user holds the client device 3300.

[0426] Local verification application 3304 may be implemented in a variety of ways while still complying with the underlying principles of the 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. Fig.34 are shown as separate logical components, but Fig.34 The verification engine 3310 shown in FIG. 3304 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 executed within a web browser environment (e.g., when a user enters the vicinity of a local secure transaction device 3350 or connects to a relying party web page to initiate a transaction).

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

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

[0429] At 3501, the client enters the vicinity of a local secure transaction device (e.g., an ATM), and at 3502, a secure connection is established with the local secure transaction device via a local channel. As mentioned, the local channel may be implemented using near field communication, Bluetooth, Wifi, 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 is able to authenticate to a relying party with a high level of assurance that the legitimate user is in possession of the client device, and if the client device is able to authenticate its current location to the relying party, then the local channel may be unnecessary.

[0430] 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 is in possession of 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.

[0431] 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 the privacy of the user (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.

[0432] If the verification is determined to be successful at 3504, then 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 operation 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 basic principles of the present invention.

[0433] If the authentication at 3504 is unsuccessful (e.g., because an acceptable level of assurance is not reached), then at 3505, the transaction is denied and / or one or more additional authentication techniques may be required. 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 at 3506 it is determined that the additional techniques are sufficient, then the transaction is permitted at 3507. If not, the transaction is again denied and / or the additional authentication techniques are attempted.

[0434] J. User Confirmation for Online Transactions

[0435] 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 need to approve a transaction initiated by a soldier, an executive may need 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 the transaction can proceed.

[0436] 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. Fig.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 the client device 3600 authenticates to the 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.).

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

[0438] 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 having users registered as "approver" indicating that the user of client device 3600 is attempting to complete a transaction. Notifications may be sent in a variety of ways in accordance with the underlying principles of the invention. For example, if client devices 3601-3602 are mobile devices, push notifications may be sent to client devices 3601-3602. Alternatively or in addition, notifications may be sent via email, text messaging (e.g., SMS), instant messaging, or any other technology capable of delivering messages to client devices 3601-3602.

[0439] 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., withdrawal, transfer between accounts, etc.). Alternatively, the notification may include a link (such as a hyperlink or other type of pointer) that directs the user of client devices 3601-3602 to an approval service on a relying party. Upon selecting the link, the details of the transaction may be provided to the user of client devices 3601-3602 (e.g., in a web page or other useful format for providing information).

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

[0441] Fig.37 3600-3602 employed in one embodiment of the present invention are shown in FIG. Specifically, the client devices 3600-3602 of this embodiment include a secure transaction application 3704 that is used to communicate with the relying party 3650 and coordinate the transaction approval techniques described herein. The secure transaction application 3704 can be a standalone application that interfaces with the verification engine 3710 via a secure application programming interface (API). Alternatively, the secure transaction application 3704 can be implemented as a mobile device application or a web browser plug-in.

[0442] 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 can display the text in a secure window and ask the user to provide verification to confirm the transaction. The application can start a timer and periodically verify the content of the current window being displayed to the user (e.g., by generating a signature on the content). The verification cycle can be randomly selected. Therefore, 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 of the transaction.

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

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

[0445] Return to Fig.37, in one embodiment, authentication may 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 may be employed, wherein a user registers with a biometric device 3720-3721 of 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 relying parties 3650 via a network (e.g., a website or other relying party equipped with a secure transaction service); and subsequently authenticates with those relying parties 3650 using data exchanged during the registration process (e.g., an encryption key pre-set into 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 (eg, see Request for Comments (RFC) 6063). However, the underlying principles of the invention are not limited to any particular key provisioning protocol.

[0446] During the authentication phase, keys are used, for example, to generate signatures, verify signatures, and / or encrypt communications between clients 3600-3602 and relying parties 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 a user) can be kept locally on the user's client device (e.g., a smartphone, laptop, etc.) to protect the user's privacy.

[0447] In one embodiment, the verification engine 110 includes an assurance level calculation module 3706 that is used to calculate 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 only access to user information.

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

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

[0450] 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 current or most recent explicit user authentication via one or more explicit user authentication devices 3720-3721. This may include, for example, fingerprint authentication via a fingerprint device, facial recognition authentication via a camera and facial recognition hardware / software, voice recognition via a microphone and voice recognition hardware / software, retinal scanning using a camera and associated hardware / software, password / PIN entry by an end user via a keypad, and / or various other types of explicit user authentication devices and / or techniques.

[0451] In one embodiment, secure storage 3725 cryptographically protects the biometric reference data record for each user authentication device 3720-3721 (e.g., using a symmetric key to wrap the data to make storage 3725 secure). Although secure storage 3725 is shown as being outside the security perimeter of 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.

[0452] 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 to generate assurance levels. For example, the sensor 3743 may include a location sensor (such as a GPS sensor) to indicate the current location of the user. 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 possibility that the user is a legitimate user. On the contrary, 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 when the user is in the expected location and reduce the assurance level when the user is in an unexpected location.

[0453] 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 can indicate that the client device 3600 to 3602 is being deceived. The comparison of the claimed location and temperature / humidity can be performed on a remote server (such as a secure transaction server 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 possibility that the legitimate user holds the client device 3600 to 3602.

[0454] Another non-intrusive authentication technique includes 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., swiped a finger across a fingerprint reader just a few minutes ago), this would tend to indicate that the legitimate user still holds the client device (leading to a high baseline assurance level). Conversely, if the last explicit authentication was hours or days ago, a new explicit user authentication may be required to achieve an acceptable assurance level.

[0455] Fig.38 , a method according to one embodiment of the present invention is shown in . At 3801, a user of a client triggers a transaction that requires confirmation by N other users. For example, a user 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 verified by implementing one or more verification techniques described herein.

[0456] 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 2 of them need to confirm to allow the transaction to proceed.

[0457] In one embodiment, a push notification may 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 may 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 may be registered with the server to receive confirmation messages over two or more communication channels. For example, a user may receive both a push notification and an email containing a confirmation request.

[0458] Regardless of how the confirmation request is sent, at 3803, all or a subset of the N users perform authentication to the server in the confirmation process. Any remote authentication technology 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, the 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., ensure that when the user confirms the transaction, he / she has viewed the actual unaltered text describing the transaction).

[0459] 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 passed since the confirmation request was sent. Once it is determined at 3805 that the confirmation timer has reached a threshold (e.g., a few 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.

[0460] K. Systems and methods for delegating trust

[0461] Existing authentication systems do not allow new authenticators to be enabled using registered authenticators on a trusted client. For example, if a user has a fingerprint sensor on her phone that she has registered with multiple websites, and then she installs a voice authenticator on her phone, she cannot automatically register her voice authenticator with all the websites where she registered her fingerprint sensor. Instead, in this case, the user must step through the same registration and enrollment process to register the voice authenticator with the relying party. Similarly, if the user purchases a new device with a new set of authenticators, the user must re-register and re-register all the new authenticators with the server.

[0462] The embodiments of the present invention described below allow users to easily use trusted client devices that have been enabled and registered with one or more relying parties to enable and register authenticators on new client devices. Specifically, these embodiments can be used to enable new authenticators, enable new client devices, and keep registration synchronization between multiple client devices.

[0463] Fig.39 A high-level overview of trust delegation according to 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 independent of the underlying principles of the present invention. Various technologies may be used, such as near field communication (NFC), Bluetooth, Wifi Direct, use of quick response (QR) codes, and establishment of HTTPS connections. In one embodiment, the devices may exchange large random tokens (LRTs) required for secure connections, and may establish a connection by providing the captured LRT to an online service and bootstrap secure communications via the service.

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

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

[0466] like Fig.40As shown, trust delegation modules 4000 to 4001 can be executed on new device 3900 and trusted device 3902, respectively, to establish a secure connection, exchange registration content, and verify registration content to the secure transaction service 4004 on each relying party 3950. As used herein, a "trusted verifier" is a verifier that a user has registered with one or more relying parties. A "new verifier" is a verifier that a user wishes to enable using all relying party registration content currently used for a trusted verifier. Therefore, if a 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 verifier. The goal of an embodiment is to convert the verification engine 3710 of a new device 3900 from a new verifier to a trusted verifier. A "trusted device" is a device with a trusted verifier, and a "new device" is a device with a new verifier.

[0467] Trust delegation is the process of enabling a new authenticator with a trusted authenticator. Therefore, the premise of trust delegation is: the user has a trusted device; the user has a new device; the user wants to delegate trust from the trusted device to the new device.

[0468] Return to Fig.40 In one embodiment, the user initiates a trust delegation application 4000 on the new client device 3900 and a trust delegation application 4001 on the trusted client device to establish an initial secure connection. In one embodiment, the trust delegation application may be a mobile device application that is specifically designed to perform the trust delegation operations described herein. In another embodiment, the trust delegation application may be a browser plug-in that is executed in response to 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). In addition, the trust delegation applications 4000 to 4001 may be software modules within a larger application (such as a verification application designed to manage verification to a relying party). However, it should be noted that the basic principles of the present invention are not limited to any particular implementation of the trust delegation applications 4000 to 4001.

[0469] 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., providing biometric input to the user authentication device 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 application 4000-4001 to perform the delegation process.

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

[0471] 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), the key pair includes a private key (ND_Uauth.priv) and a public key (ND_Uauth.pub), and the trust delegation application 4000 sends the N new device public keys to the trust delegation application 4001 on the trusted device 3902.

[0472] 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 a private key associated with a specific registration performed to the corresponding relying party. The trust delegation application 4001 may also insert a timestamp into the generated signature, which may then be used by the relying party to verify the exact time at which 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., application ID codes identifying services at the relying party), a user name registered for the user at the relying party, a key ID code used by the relying party to locate the appropriate key during verification, and any other data related to the verification process.

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

[0474] In one embodiment, after the registration data has been stored in the local secure storage device 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 the relying party (e.g., 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 Fig.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.

[0475] 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 the 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., enter a security code) from the new client device 3900. Additionally, at this stage, the secure transaction service 4004 may verify the timestamp inserted into the signature and ensure that the timestamp is not older than a threshold amount of time.

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

[0477] 1. Confirmation of the new device public key (ND_Uauth.pub) associated with the relying party. In one embodiment, the confirmation includes a signature generated over the public key (eg, using the relying party's public key).

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

[0479] 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 the key ID to query its secure transaction database 4025 to retrieve the public key).

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

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

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

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

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

[0485] 4. Verify the certification of the new device public key (ND_Uauth.pub) associated with the relying party.

[0486] In one embodiment, this verification is performed using the relying party's private key.

[0487] Fig.41 One embodiment of a method for securely transferring registration data from a trusted device to a new device is shown in Fig.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.

[0488] First go to Fig.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 registered by the trusted device with the relying party.

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

[0490] Now go to Fig.42 , at 4201, the new client (having executed Fig.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 use one or more biometrics or other verification techniques for verification. As discussed above, at 4204, the new device prepares a response, which includes a confirmation of the new device's public key, a signature generated with the new device's private key (e.g., on a challenge), and a signature generated with the private key of the trusted device and 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.

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

[0492] Furthermore, it should be noted that some of the operations involved may be implemented in a variety of ways. For example, the security protocol for delegating trust may 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) may generate a number of new key pairs (ND_Uauth), and the authenticator on the trusted device may sign the public keys of these key pairs.

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

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

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

[0496] 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 access data in plain text (e.g., unencrypted format), thereby protecting the privacy of users.

[0497] 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 may be employed outside the context of a remote user authentication system as described for other embodiments of the present invention. However, these synchronization techniques may be used to perform synchronization for these remote user authentication embodiments. For example, in one embodiment, these synchronization techniques may be used to synchronize registration data for each website or other online service visited by a user between multiple devices.

[0498] 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 is used to store 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 an 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 an asymmetric public / private key pair of device d. In one embodiment, d.priv never leaves device d. "Chain of trust" means persistent data stored on the circle cloud that contains information about devices trusted by the user and their relationships. "Circle channel" means a secure communication channel provided by the circle cloud, which is used by two (or more) devices to exchange and synchronize data between them.

[0499] 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. Fig.43 Describing these embodiments, the figure shows three client devices 4301-4303, which have privacy synchronization applications 4311-4313 for implementing the protocols and techniques described herein, and secure data storage devices 4321-4332 for storing data used for joining and synchronization. Device 4301 is sometimes referred to herein as device d1, device 4302 is sometimes referred to as device d2, and device 4303 is sometimes referred to as device d3.

[0500] In one embodiment, joining and synchronization are performed by 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.

[0501] a. Join the circle

[0502] 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 authorized by another device 4301 that is already part of the existing circle.

[0503] Fig.44 4301. At 4401, a user authorizes a new device 4302 on an existing trusted device 4301. For example, in one embodiment, a 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.

[0504] At 4402, in one embodiment, the privacy sync applications 4311-4312 cause the devices 4301-4302 to establish a secure connection. Various technologies may be used to establish a secure connection, such as near field communication (NFC), Bluetooth, WifiDirect, using a quick response (QR) code, and establishing an HTTPS connection.

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

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

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

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

[0509] 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-block1 includes a signature generated over the public key of device 4301 using the private key of device 4302. In one embodiment, the trust-block1 entry also includes a timestamp (T).

[0510] Return to Fig.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.

[0511] 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 reads and verifies the integrity of d2.pub and T using sk.sym (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.

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

[0513] b. Sync with circles

[0514] In this process, devices 4301 to 4303 belonging to the same circle synchronize data between them. Different application-specific sub-protocols may be implemented immediately after this process. For example, an online cloud storage application may want to keep the user's data synchronized on all devices and retain an encrypted copy on the circle cloud. Another application may propagate a message to the devices in the circle. For example, in one embodiment, registration data used by a device to verify 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 complying with the basic principles of the present invention. All such sub-protocols may use the basic process blocks described below.

[0515] Chain of Trust

[0516] For example, the "join circle" process ( Fig.44 ), what goes into the trust chain 4360 is the evidence that asserts that device 2 is trusted by device 1. Thus, the 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 and there is no block asserting that device 4302 trusts device 4301, then the trust chain 4360 is considered broken. In one embodiment, the 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.

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

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

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

[0520] Circle Channel

[0521] In one embodiment, implementing Fig.45 The process shown is to synchronize data between other devices in the same circle. In the illustrated example, device 4301 (d1) is a device that has new data and wants to send 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.

[0522] 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 SK relative to each other device using the Diffie-Hellman key exchange algorithm. Diffie-Hellman is a well-known algorithm that allows two parties that were previously unaware 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.

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

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

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

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

[0527] At 4505, the device 4301 encrypts the data to be synchronized with the REK—that is, 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.

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

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

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

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

[0532] In one embodiment, the "join circle" operation described above may require user authentication of device 1 and device 2. When the protocol is implemented using the remote authentication technology described herein, the user may be required to (for example) "swipe" a finger to authenticate the two devices to initiate and complete the "join circle" process. In contrast, in one embodiment, syncing data between devices as described may not require user authentication.

[0533] The protocols and associated technologies described herein allow for the construction of a network of devices that trust each other. Notably, all data transmitted to and from the cloud and stored in the cloud is encrypted. Thus, data can be synchronized between multiple devices without storing any confidential data on the cloud, thereby improving user privacy protection.

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

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

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

[0537] • A system and method in which a device uses a Diffie-Hellman or similar key exchange algorithm to generate two-way session keys and encrypts data with those keys.

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

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

[0540] ●A system and method in which a persistent circle group key is used to encrypt synchronization data.

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

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

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

[0544] ●An application that uses the described private synchronization protocol in conjunction with an embodiment of the present invention to perform user-controlled trust delegation to new devices, thereby sharing new registration content between the user's devices, where the user does not need to authenticate to the authenticator each time he delegates new registration content to other devices.

[0545] A group of validators that belong to the same user and form a circle, where these validators synchronize their validation key pairs using the private synchronization protocol described above to share the registration content of a single validator with other validators that belong to the same circle.

[0546] M. Exemplary System Architecture

[0547] It should be noted that the term "relying party" is 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 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 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 in FIG. 46A to FIG. 46B As listed in, these figures show that "relying parties" may include websites 4631 and other network services 4651, as well as secure transaction servers 4632-4633 for performing verification techniques on behalf of the websites and network services.

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

[0549] Go to Fig.46A , the illustrated embodiment includes a client 4600 equipped with one or more authentication devices 4610 to 4612, which are used to enroll and authenticate end users. As described above, the 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); and non-biometric devices, such as a trusted platform module (TPM) and a smart card. A user can enroll a biometric device by providing biometric data (e.g., swiping a finger on a fingerprint device), and the secure transaction service 4601 can store these biometric data as biometric template data (via interface 4602) in a secure storage device 4620.

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

[0551] The verification devices 4610 to 4612 are communicatively coupled to the client via an interface 4602 (e.g., an application programming interface or API) exposed by the secure transaction service 4601. The secure transaction service 4601 is a secure application for communicating with one or more secure transaction servers 4632 to 4633 via a network and for interfacing with a secure transaction plug-in 4605 executed within the environment of 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 verification device 4610 to 4612, such as a device identification code, a user identification code, user registration data (e.g., a scanned fingerprint or other biometric data), and a key for performing the secure verification techniques described herein. For example, as discussed in detail below, a unique key may be stored in each verification device and used when communicating with the server 4630 via a network (such as the Internet).

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

[0553] 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 initiated in response to a specific HTML tag inserted into the HTML code of a web page by a network server 4631 (hereinafter sometimes referred to 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.

[0554] The secure transaction servers 4632-4633 are coupled to the secure transaction database 4640 to store user data, authentication device data, keys, and other security information required to support the secure authentication transactions described below. However, it should be noted that the basic principles of the present invention do not require separation of Fig.46A Logical components within the secure enterprise or web destination 4630 are shown. For example, the website 4631 and secure transaction servers 4632-4633 can be implemented within a single physical server or separate physical servers. In addition, the website 4631 and transaction servers 4632-4633 can be implemented within integrated software modules executed on one or more servers to perform the functions described below.

[0555] As mentioned above, the basic principle of the present invention is not limited to Fig.46A The browser-based architecture shown. Fig.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.

[0556] exist FIG. 46A to FIG. 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 device 4620. In addition, the secure transaction servers 4632-4633 manage a secure transaction database 4640 on the server side.

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

[0558] The operations described below include: verification of the device detection ( Fig.47 ); User registration through verification device ( Fig.48 ); Verify device registration ( Fig.49 ); User authentication through a registered authentication device ( Fig.50 ); and the implementation of secure transactions after verification ( Fig.51 ).

[0559] Fig.47 A series of transactions for detecting authentication devices on a client machine is shown. After successful completion of device detection, the server 4730 has detailed information about the authentication devices attached to the client and will be able to evaluate which (which) devices are best suited for use with the enhanced security infrastructure. Only the server 4730 screens the list of authentication devices. This list will be provided to the user, and the user can select one (or a group of) authentication devices to use for further authentication and implementation of secure transactions.

[0560] In operation, the user authenticates and logs into the website using a username and password in a browser. Only then is the user required to provide a username and password. The server 4730 determines that the user is not currently using enhanced security (e.g., by querying the secure transaction database 4720) and suggests to the user that it be changed to enhanced security.

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

[0562] 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 may be presented with a list filtered by the website and may select one or a group of authentication devices.

[0563] Fig.48 A series of transactions for registering a user with a verification 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 (e.g., fingerprint, voice sample, etc.) of the user so that the same verification device can be used to verify the user during subsequent transactions. The registration operation can be performed separately on the client without interacting with the server 4730. The user interface provided for registration can be displayed in a browser extension, or can be displayed in a separate application or mobile device application.

[0564] Once a device is detected, an enrollment 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. Fig.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 the registration request to the secure transaction service 4701 and waits for completion. If the user has already registered with the verification device on the client, the user may only need to verify his identity (i.e., the user will not need to register again). If the user is not currently registered, the secure transaction service 101 starts the registration process by activating the physical verification 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 verification device. It is worth noting that once the user is registered with the device, it can use this registration to register or authenticate with any website or network service, as described herein.

[0565] Fig.49A series of transactions for registering a verification device is shown. During registration, a key is shared between the verification device and one of the secure transaction servers 4732 to 4733. The key is stored in the secure storage 4720 of the client 4700 and in the secure transaction database 4720 used by the secure transaction servers 4732 to 4733. In one embodiment, the key is a symmetric key generated by one of the secure transaction servers 4732 to 4733. However, in another embodiment discussed below, an asymmetric key may be used. In this embodiment, a public key may be stored by the secure transaction servers 4732 to 4733, and a second related private key may be stored in the secure storage 4720 on the client. In addition, in one embodiment (also discussed below), the key may be generated on the client 4700 (e.g., by the verification device or verification device interface rather than the secure transaction servers 4732 to 4733).

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

[0567] Go to Fig.49 In the specific details shown, once user registration or user verification is completed, the server 4730 generates a randomly generated challenge (e.g., a cryptographic random number) that the client must present during device registration. The random challenge can be valid for a limited period of time. The secure transaction plug-in detects the random challenge and forwards it to the secure transaction service 4701. In response, the secure transaction service initiates an out-of-band session (e.g., an out-of-band transaction) with the server 4730 and communicates with the server 4730 using a key provisioning protocol. The server 4730 locates the user using the username, verifies the random challenge, verifies the verification code if the device's verification code has been sent, and creates a new entry for the user in the secure transaction database 4720. It can also generate a key, write the key to the database 4720, and send the key back to the secure transaction service 4701 using a key provisioning protocol. Once completed, the verification device and the server 4730 share the same key if symmetric keys are used, or different keys if asymmetric keys are used.

[0568] Fig.50 A series of transactions for authenticating a user to a registered authentication device are shown. Once device registration is complete, server 4730 will accept a token generated by the local authentication device as a valid authentication token.

[0569] Go to Fig.5047. In the specific details shown, the figure shows a browser-based implementation in which a user enters a uniform resource locator (URL) of a server 4730 in a browser 4704. In an implementation using a stand-alone application or a mobile device application (rather than a browser), the user may enter the network address of a network service, or the application or mobile device application may automatically attempt to connect to the network service at the network address.

[0570] For a browser-based implementation, the website embeds a query for registered devices in an HTML page. This can be done in many ways other than embedding the query in an HTML page, such as through Javascript or using HTTP headers. The secure transaction plugin 4705 receives the URL and sends it to the secure transaction service 4701, which searches the secure storage device 4720 (which, as discussed, includes a database of authentication device and user information) and determines whether there is a user registered within the URL. If so, the secure transaction service 4701 sends a list of preset devices associated with the URL to the secure transaction plugin 4705. The secure transaction plugin then calls the registered JavaScript API and passes this information to the server 4730 (e.g., a website). The 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 asks the user to authenticate. The user then provides the required authentication measure (e.g., swiping a finger on a fingerprint reader, speaking for voice recognition, etc.). The secure transaction service 4701 identifies the user (this step can be skipped for devices that do not support storing users), 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. The server 4730 identifies the user from the secure transaction database 4720 and verifies the token by generating the same token on the server 4730 (e.g., using its copy of the key). Once verified, the verification process is complete.

[0571] Fig.51 A secure transaction after verification is shown for a browser-based implementation. This secure transaction is designed to provide greater security for certain types of transactions (e.g., financial transactions). In the illustrated embodiment, the user confirms each transaction before making the transaction. Using the illustrated technique, the user confirms what transaction he / she wants to make and makes the exact content he / she sees displayed in the GUI. In other words, this embodiment ensures that a "middleman" cannot modify the transaction text to make a transaction that the user has not confirmed.

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

[0573] The following example will help highlight the operation of this embodiment. The 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 a secure transaction server 4732-4733 that implements one or more embodiments of the present invention described herein. The merchant website authenticates the user and completes the transaction.

[0574] The secure transaction servers 4732-4733 receive the transaction details (TD) and place a "secure transaction" request in an HTML page and send it to the client 4700. The secure transaction request includes the transaction details and a random challenge (e.g., a random number). The secure transaction plug-in 4705 detects the request for a transaction confirmation message and forwards all data to the secure transaction service 4701. In an embodiment that does not use a browser or plug-in, the information can be sent directly from the secure transaction server to the secure transaction service on the client 4700.

[0575] For browser-based implementations, the secure transaction plug-in 4705 displays a 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, the secure transaction service 4701 or application 4754 can display the window 5101. The secure transaction service 4701 starts a timer and verifies the contents of the window 5101 being displayed to the user. The verification period can be randomly selected. The secure transaction service 4701 ensures that the user sees valid transaction details in the window 5101. If it detects that the content has been tampered with, it prevents the generation of a confirmation token.

[0576] After the user provides valid authentication (e.g., swiping a finger on 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 the secure transaction server 4732-4733 to ensure that the transaction details have not been modified between the server and the client. The secure transaction service 4701 sends the generated token and username to the secure transaction plugin 4705, which forwards the token to the secure transaction server 4732-4733. The secure transaction server 4732-4733 identifies the user using the username and verifies the token. If the verification is successful, a confirmation message is sent to the client and the transaction is processed.

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

[0578] 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, which indicates the authentication functions accepted by the server. The client then analyzes the server policy to identify a subset of authentication functions that it supports and / or that the user has indicated that it wants to use. The client then registers and / or authenticates the user using a subset of authentication tokens that matches the provided policy. Thus, there is less impact on the client's privacy because the client is not required to transmit detailed information about its authentication functions (e.g., all of its authentication devices) or other information that can be used to uniquely identify the client.

[0579] By way of example and not limitation, a client may include many authentication capabilities, such as a fingerprint sensor, voice recognition capabilities, facial recognition capabilities, eye / optical recognition capabilities, a trusted platform module (TPM), and smart cards, among others. However, for privacy reasons, a user may not wish to reveal all of the details of its capabilities to a requesting server. Therefore, using the techniques described herein, a secure transaction server may transmit a server policy to a 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 of the available authentication options.

[0580] Fig.52 An 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 a policy filter 5201, which is used to analyze the policy provided by the server 4730 and identify the verification function subgroup to be used for registration and / or verification. In one embodiment, the policy filter 5201 is implemented as a software module executed within the environment of the secure transaction service 4701. However, it should be noted that the policy filter 5201 can be implemented in any manner while still complying with the basic principles of the present invention, and can include software, hardware, firmware or any combination thereof.

[0581] Fig.52 The particular implementation shown in FIG. 4 includes a secure transaction plug-in 4705 for establishing communications with a secure enterprise or web destination 4730 (sometimes referred to simply as a "server 4730") using the techniques previously discussed. For example, the secure transaction plug-in may recognize a specific HTML tag 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 that implements the policy filter 5201.

[0582] 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 of all authentication devices). If the user has registered the user with his authentication device, the user's registration data is stored in the secure storage 5220. If the client has registered the authentication device with the server 4730, the secure storage can also store the encryption secret key associated with each authentication device.

[0583] 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 be used. 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, then 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 Fig.52 A more limited subset of authentication functions may be identified to the server if indicated by user preferences 5230 in the policy filter. 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.

[0584] Depending on what 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, such as Fig.52 Alternatively, in an implementation 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.

[0585] Fig.53 A transaction diagram is shown showing additional details of a series of exemplary registrations using a query strategy transaction. In the illustrated embodiment, the user has not previously registered the device with the server 4730. Therefore, at 5301, the user may enter a username and password as an initial one-time authentication step, which at 5302 are forwarded to the server 4730 via the client browser 4704. 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.

[0586] 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 functions supported by server 4730. In the illustrated example, the server policy is communicated to secure transaction service 4701 via transaction 5306.

[0587] 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 obtain 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 one it claims to be.

[0588] Alternatively or in addition, 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 with 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.

[0589] The techniques described above for filtering server policies at the client can be implemented at various different stages of the series of transactions described above (e.g., during device discovery, device registration, device provisioning, user authentication, etc.). That is, the basic principles of the present invention are not limited to Fig.53 The set of specific transactions and the specific order of transactions stated.

[0590] Furthermore, as previously mentioned, a browser plug-in architecture is not necessarily required in order to comply with the basic principles of the present invention. For architectures that do not involve a browser or a browser plug-in (e.g., such as a stand-alone application or a mobile device application), Fig.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.

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

[0592] One embodiment of the present invention is able to register, enroll, and authenticate multiple devices simultaneously, thereby improving efficiency and user experience. For example, instead of 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 to multiple devices in one operation or a series of sequential operations performed locally on the client. For authentication, several tokens / devices can be selected simultaneously for a given transaction.

[0593] Fig.54 An embodiment of the client-server architecture for implementing these technologies is shown. As shown, the secure transaction service 4701 implemented on the client 4700 includes a multi-device processing logic 5401, which is used to perform specified operations, such as registering and registering multiple devices at one time without the need to continuously communicate back and forth with the server 4730 when registering / registering each device. Similarly, the server 4730 includes a multi-device processing logic, which is used to issue commands pointing to multiple verification devices. In one embodiment, the multi-device processing logic 5401 is implemented as a software module executed in 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 way while still complying with the basic principles of the present invention, and can include software, hardware or firmware components or any combination thereof.

[0594] As in the embodiments described above, Fig.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 comply with the underlying principles of the present invention.

[0595] The multi-device processing logic 5402 on the server 4730 may transmit a command 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 the command 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 of all N devices is complete.

[0596] Figures 55A to 55CA series of exemplary multi-device transactions are shown in FIG. Fig.55A A multi-device registration process is shown, which can be performed without any interaction with the server 4730 (e.g., the registration of 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 a client (not shown) to register a user with N devices. Figures 55B to 55C Two different implementations for registering multiple devices with server 4730 are shown.

[0597] Go to Fig.55A In the registration process in, at 5501, the user indicates that he wants to register with N authentication devices (representing all or a subset of available authentication devices) on the client. In response, at 5502, the secure transaction plug-in is called, and at 5503, a device-specific graphical user interface (GUI) is generated to allow the user to traverse the process or register with the authentication device #1. During the registration process, the user interacts with the secure transaction plug-in according to the instructions (for example, by placing a finger above the fingerprint sensor, speaking to the microphone, taking a photo with a camera, etc.). In one embodiment, registration is performed for each of the N devices until the registration for the Nth device is completed at 5504. Different device-specific scripts and / or user interfaces can be presented to the user to register the user with each individual authentication device. As previously discussed, when the user registers with each device, the user registration data can be stored in the secure storage device 720 on the client 4700 and can only be accessed through the secure transaction service 4701. Once the registration for all N devices is completed, a notification can be sent to the server 4730 via transactions 5504 to 5505.

[0598] Regardless of how you perform the registration, once completed, you can use Fig.55B , to register N devices with server 4730. 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 together with a command to register N authentication devices to server 4730. At 5512, secure transaction service 4701 creates a secure connection with server 4730 and transmits identification data for N devices together 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.

[0599] At 5513, the server 4730 authenticates the N devices, generates a key for each of the N devices, and sends the N keys back to the secure transaction service via a secure connection. In one embodiment, the dynamic symmetric key provisioning protocol (DSKPP) is used to exchange keys with the client via a secure connection. However, the underlying principles of the invention are not limited to any particular key provisioning technology. Alternatively, in an embodiment that does not rely on the DSKPP protocol, a key may be generated in each authentication device and then transmitted to the server 4730.

[0600] 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 a secure storage device 720 on the client and associated with a 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.

[0601] In one embodiment, the key registered to each verification device is a symmetric key. Therefore, the same copy of each key is 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 can be generated, in which 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 basic principles of the present invention are not limited to any particular type of encryption key.

[0602] Fig.55C 4700. 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 device 720, as previously described. Once all keys have been registered, the secure transaction service 4701 provides a notification to the server at 5515 along with a random challenge (for verifying the identity of the client). The server 4730 may then store the registrations in the secure transaction database 4720, as described above.

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

[0604] One embodiment of the present invention improves the way random challenges are generated and processed by a 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 time...

Claims

1. A system comprising: an authenticator on a client device for securely authenticating a user using the authenticator via biometric input, manual user input, and / or by detecting a current condition associated with the client device; as well as A keystore circuit / logic for maintaining secure storage of private keys, the keystore circuit / logic for computing a digital signature to sign a digital object containing one or more attributes of the verifier and input data using a first private key when the user has been authenticated by the verifier, the signed digital object being verifiable by a relying party using a public key corresponding to the first private key, and a pair of the public key and the first private key being associated with the verifier.

2. The system according to claim 1, further comprising: A digest / hash circuit / logic may be plugged in which will be integrated into the keystore circuit / logic and executed to calculate the digital signature.

3. The system of claim 2, wherein the pluggable digest / hash circuitry / logic includes pre-processing circuitry / logic for pre-processing input data in a specified manner to generate the digital object.

4. The system according to claim 3, further comprising: Secure transaction circuitry / logic for securely displaying valid information associated with the input data prior to receiving authorization from the user to proceed with the digital signature.

5. The system of claim 1, wherein the digital object includes one or more data fields that are not controlled by the validator.

6. The system of claim 5, wherein the one or more data fields not controlled by the validator are marked by a number followed by a data structure.

7. The system of claim 1, wherein the relying party is operable to identify an entity that generated the pair of the public key and the first private key.

8. The system of claim 1, wherein the digital signature is used to indicate one or more characteristics of a user authentication method to thereby authenticate the user.

9. The system of claim 1, wherein the one or more attributes of the authenticator and input data include one or more of a transaction text confirmed by the user, an actual personal identification number (PIN) length, and a firmware version of the authenticator.

10. The system of claim 1, wherein the digital object contains a formatted message to be verified by the relying party.

11. The system of claim 1 , wherein the signed digital object contains a block that is added to a blockchain along with the digital signature generated using the first private key.

12. A system for implementing a private or public ledger, comprising: public key management circuitry / logic for receiving, processing and storing public keys and associated certification statements in response to user authorization; as well as The public key management circuit / logic is used to add a public key to a record in the private or public ledger identified by a decentralized identifier DID.

13. The system of claim 12, further comprising: An authenticator on a client device for securely authenticating a user via biometric input, manual user input, and / or by detecting a current condition associated with the client device, the authenticator for performing the authentication using a public key.

14. The system of claim 13, wherein the authenticator is configured to register one or more of the public keys with one or more relying parties using a cryptographic challenge response protocol.

15. The system of claim 14, wherein a relying party of the one or more relying parties is used to verify that the DID entry in the ledger correctly supports the public key used for verification.

16. The system of claim 15, further comprising: A rules processing engine associated with the validator, the rules processing engine being configured to allow a user to formulate logical rules associated with the public or private ledger, including combining multiple verification techniques in order for a verification operation to be considered valid.

17. A method comprising: securely authenticating a user by an authenticator on a client device via biometric input, manual user input, and / or by detecting a current condition associated with the client device; Maintain secure storage of private keys; as well as A digital signature is calculated to sign a digital object containing one or more attributes of the verifier and input data using a first private key when the user has been verified by the verifier, the signed digital object being verifiable by a relying party using a public key corresponding to the first private key, and a pair of the public key and the first private key being associated with the verifier.

18. The method of claim 17, wherein the digital object is generated by preprocessing input data in a specified manner.

19. The method of claim 18, wherein valid information associated with the input data is securely displayed prior to receiving authorization from the user to proceed with the digital signature.

Images