JP2016521403A - Advanced authentication technology and its applications - Google Patents

Abstract

Systems, apparatus, methods, and machine-readable media for performing advanced authentication techniques and related applications are described. For example, one embodiment of the method receives one or more policies for receiving a policy that identifies an acceptable set of authentication functions, determining a set of client authentication functions, and authenticating a user of the client. Filtering an acceptable set of authentication functions based on the determined set of client authentication functions to arrive at a filtered set of authentication functions.

Description

  (Cross-reference of related applications)

  This patent application is a co-pending US Provisional Patent Application No. 61 / 804,568 filed Mar. 22, 2013 entitled “Advanced Methods of Authentication And Its Applications”. Claim the interests and priority of the issue.

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

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

  This patent application is also a co-pending US Provisional Patent Application No. 61/804, filed March 22, 2013 entitled “Advanced Methods of Authentication And Its Applications”. US patent application Ser. No. 14 filed Dec. 31, 2013 entitled “System and Method for Adaptive User Authentication” which also claims the benefit and priority of 568. / 145,466 part continuation application.

  This patent application is also a co-pending US Provisional Patent Application No. 61/804, filed March 22, 2013 entitled “Advanced Methods of Authentication And Its Applications”. No. 568, filed Dec. 31, 2013 entitled “System and Method for Location-Based Authentication” which also claims the benefit and priority of 568 This is a continuation-in-part application of No. 14 / 145,533.

This patent application is also a co-pending US Provisional Patent Application No. 61/804, filed March 22, 2013 entitled “Advanced Methods of Authentication And Its Applications”. The benefit and priority of 568 also claims "System and Method for Confirming Location Using Supplemental Sensor and / or Location Data" and This is a continuation-in-part of US patent application Ser. No. 14 / 145,607, filed Dec. 31, 2013.
(Technical field)

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

  FIG. 1 illustrates an exemplary client 120 having a biometric authentication device 100. During normal operation, the biometric sensor 102 reads raw biometric data from the user (eg, captures the user's fingerprint, records the user's voice, snaps the user's photo, etc.), and the feature extraction module 103 Extract specific features of raw biometric data (for example, focus on a predetermined region of a fingerprint, a predetermined facial feature, etc.). The matcher module 104 compares the biometric reference data 110 stored in the secure storage of the client 120 with the extracted feature 133, and generates a score 153 based on the similarity between the extracted feature and the biometric reference data 110. The biometric reference data 110 is typically the result of a registration process in which a user registers a fingerprint, audio sample, image or other biometric data in the device 100. The application 105 can then use the score 135 to determine whether the authentication was successful (eg, whether the score is above a predetermined specific threshold).

  The system is also designed to provide secure user authentication over a network using biometric sensors. In such a system, the score 135 and / or other authentication data generated by the application 105 can be transmitted over a network to authenticate the user by a remote server. For example, Patent Application Publication No. 2011/0082801 (“'801 application”) describes strong authentication (eg, protection against identity theft and phishing), secure transactions (eg, “malware in browsers” and transactions). Protection against "man-in-the-middle" attacks), as well as registration / management of client authentication tokens (eg fingerprint readers, facial recognition devices, smart cards, trusted platform modules, etc.) A framework is described.

  The assignee of this patent application has developed various improvements to the authentication framework described in the '801 application. Some of these improvements are described in the following set of US patent applications all filed on Dec. 29, 2012 ("co-pending applications") assigned to the present assignee: No. 13 / 730,761, Query System and Method to Determine Authentication Capabilities, US Patent Application No. 13 / 730,776, Efficient Member Registration with Multiple Authentication Devices, System and Method for Efficiently Enrolling, Registering, and Authenticating With Multiple Authentication Devices, US Patent Application No. 13 / 730,780, for handling random challenges within an authentication framework System and Method for Processing Random Challenges Within an Authentication Framework, US Patent Application No. 13 / 730,791, System and Method for Implementing Privacy Classes Within an Authentication Framework, US Patent Application No. 13 / 730,795, within Authentication Framework System and Method for Implementing Transaction Signaling Within an Authentication Framework.

  Briefly, a co-pending application uses a client biometric device to generate biometric template data by a user (eg, by swiping a finger, snapping an image, recording audio, etc.). Register the biometric device with one or more servers (e.g., a website or other trusted party with a secure transaction service as described in co-pending applications) via the network; Thereafter, an authentication technique is described in which data exchanged during the registration process is used (for example, an encryption key set in the biometric authentication device) to be authenticated by those servers. Once authenticated, the user is allowed to perform one or more online transactions with a website or other trusted party. In the framework described in the co-pending application, sensitive information such as fingerprint data and other data that can be used to uniquely identify the user is used to protect the user's privacy to protect the user's privacy. Or locally on a notebook computer, etc.).

  An authentication code as described above requires some form of interaction with the user, such as swiping a finger or entering a PIN. These “normal” authentication codes are intended to authenticate the user at a given point in time. In addition, a “silent” authentication code can also be designed and used to authenticate a user's device (rather than the user) at a given time. These silent authentication codes can rely on information extracted from the user's device without interaction with the user (eg, device ID transmission).

  However, there are certain use cases where the explicit user interaction that is required presents too much friction (eg, Near Field Communication (NFC) payments, authentication without being bound by expensive transactions) “Silent” authentication techniques, such as device ID transmission, do not provide sufficient certainty that a legitimate user remains in possession of the device.

  Anthony J.H. 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” (currently http://www.cse.msu.edu/biometrics/Publications/Face/NiinumaJain_ContinuousAuth_spi.p. Several “continuous” authentication methods have been proposed by the research community. Some of these methods have been adopted by the industry such as BehavioSec, “Measuring FAR / FRR / EER in Continuous Authentication”, Stockholm, Sweden (2009). While these methods generally provide a level of assurance that legitimate users still own the device without adding friction to the authentication process, they focus on a single modality (ie wearable tokens). , Walking recognition, face and clothing color recognition, and user keyboard input).

  However, one problem that exists is that in some parts of the world, location data or other individuals (e.g. facial images, clothing colors, etc.) may be relied upon to a trusted party to supplement risk estimates that violate user privacy. , Walking or input characteristics, ...) or environmental data (eg, temperature, humidity, wireless LAN SSID, ...). Therefore, there is a need for more advanced remote authentication technologies that are non-invasive and that adequately protect end user privacy.

  Furthermore, the strength of current authentication methods (eg, passwords, fingerprint authentication, etc.) is approximately constant over time, but the resulting risk is that the current environment in which authentication is performed (eg, equipment used, equipment used) Based on the network to which it is connected). It may be beneficial to select and / or combine authentication modalities based on current detected risks.

  Given the increased level of authentication assurance, typical methods to improve the level of clear authentication methods require more complex passwords or more accurate biometrics such as fingerprints and facial recognition Such as using a method. In practice, the authentication assurance level (or transaction risk derived therefrom) also determines whether authentication was performed from the same device as before and whether the location of the authentication is practically close to the location of the last successful authentication ( For example, the authentication at 1 pm in San Francisco and the authentication at 2 pm in Tokyo on the same day depends on other data such as it seems unrealistic for one person.

  Passwords are still the dominant and clear authentication method. Unfortunately, they are easily attacked and their attacks scale well. Furthermore, it is troublesome to enter a password, particularly in small devices such as smartphones. As a result, many users either do not use password-based protection methods to lock their cell phones or use trivial PIN codes.

  Some smartphones use fingerprint sensors to provide a more convenient way to authenticate. The use of biometric modalities for authentication has been criticized for introducing privacy issues because they are not impersonating attack resistance sufficiently and potentially not adequately protecting biometric reference data. ing.

  Various “fusion” methods for combining biometric modalities have been proposed. Some of them address usability issues by reducing the false rejection rate (FRR), and others address security issues by reducing the false acceptance rate (FAR). These methods have proposed a static fusion algorithm so far. Unfortunately, this approach still results in a level of assurance that varies in response to “other inputs” (as described above).

  For a particular class of transactions, the risks associated with the transaction can be closely related to the location where the transaction is taking place. For example, you may be encouraged to allow transactions that appear to come from restricted countries, such as those listed in the US office of a foreign asset control list (eg, Cuba, Libya, North Korea, etc.) . In other cases, it may be desirable to allow transactions to proceed if a stronger authentication mechanism is used; for example, transactions performed within a company's physical facility may be Less authentication may be required than is done from Starbucks located in remote locations that do not have business.

  However, reliable location data may not be readily available for various reasons. For example, the end user's device may not have GPS capability, the user may be in a location where WiFi triangulation data is not available or unreliable, and the network provider may have GPS or WiFi triangulation capability In some cases, the provided cell tower does not support the triangulation function. Other approaches to infer device location may not have a sufficient level of assurance to meet the needs of the organization; for example, reverse IP search to determine geographic location is It can be sufficiently granular or it can be masked by a proxy designed to mask the true network origin of the user's device.

  In these cases, the organization seeking to assess the risk of the transaction may provide additional data to provide them with additional assurance that the individual is located in a specific geographic area to drive the authentication decision. You may need it.

  Another challenge for organizations to deploy authentication is to match the “strength” of the authentication mechanism to the inherent risks presented by the particular user's environment (location, device, software, operating system) Requests (requests for access to restricted information or to perform specific operations) are made according to user or device and organization management policies.

  To date, organizations have had to rely heavily on static responses to their users' authentication needs. That is, the organization evaluates the risks faced by the user during the operations they normally perform and any applicable regulatory delegation requirements, and then deploys authentication solutions to protect against the risks and achieve compliance To do. This is usually an organization to deploy multiple authentication solutions to address the many different risks that those different users may face, which can be particularly costly and cumbersome to manage Need.

  The technology described in the co-pending application provides an abstraction that allows an organization that can be used for authentication to identify existing functionality on a user's device. This abstraction protects organizations from the need to deploy different solutions for different authentications. However, organizations still need a way to activate the “correct” authentication mechanism as needed. Existing implementations provide no functionality to the organization to explain what authentication mechanisms are appropriate in the context. As a result, organizations will probably need to codify their authentication policies in the code and will need to make code changes in the future to make the solution brittle and allow the use of new authenticators / tokens. Will do.

  Electronic financial transactions are today conducted mainly through the World Wide Web using browser applications. Amazon. Sites like Com, Dell, and Walmart sell billions of dollars through their online portals, and banks and brokerage firms have billions of dollars in funding their customers from online accounts. It is possible to move. One challenge for websites like these is how to detect fraud. Fraudulent transactions can cost billions of dollars for these companies.

  The first thing used to defend against fraudulent transactions is the user's password. However, criminals can obtain passwords through various techniques. Sometimes passwords are weak in complexity and can be easily guessed or determined by brute force attacks. At other times, malware, worms or viruses can infect the user's computer. The password is then obtained by recording keystrokes or scanning a memory or hard disk storage device. If the real device is stolen, the password can be recovered from data remaining in memory or storage. If the password is compromised, the criminal has the ability to access the account to withdraw or transfer funds.

  In an effort to prevent damage caused by user password violations, sites dealing with financial transactions have various ways to determine whether the person who initiated the transaction is actually the user who owns the account. Adopt risk assessment where metrics are used. Factors such as transaction time, transaction location, and transaction status are all good ways to assess whether a transaction is at risk. For example, if the user does not have any activity in his account, usually at night, it is unlikely that the transaction will start from 3:00 AM to 3:00 PM. Similarly, if the user lives in the United States but the transaction is initiated in Korea, the difference in location will be a warning sign. Finally, if the amount being processed is significantly different than normal, this is another signal for potential fraud.

  Unfortunately, web browsers place very severe restrictions on the information that a website can obtain about a client system. Since the browser exposes the user's equipment to the outside (and possibly malicious) world, leaking more data than necessary is a unique security risk. Indeed, the transaction time, transaction location and transaction size (eg, via the user's IP address) can be recorded. The website currently uses all of this data to determine if the transaction is fraudulent. However, beyond these basic pieces of information provided by the browser, the website has no other information to use for risk assessment. Due to the limited information that the browser can obtain, the risk assessment for a user's transaction is not very accurate.

  A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:

1 illustrates an exemplary client with a biometric authentication device. 1 illustrates one embodiment of a non-invasive privacy preservation and authentication device (NIPPA). Figure 3 graphically illustrates the operation of one embodiment of the present invention during a "legitimate user state" and the next legitimate user state. FIG. 4 illustrates one embodiment of a method for non-invasive privacy preservation authentication. FIG. 4 illustrates a distance function used for location-based authentication in one embodiment. Figure 2 graphically illustrates the operation of one embodiment of the present invention using an extended legitimate user status window. Figure 2 illustrates an adaptive authentication module according to one embodiment of the invention. 1 illustrates one embodiment of an adaptive authentication method. Figure 2 graphically illustrates adaptive authentication according to one embodiment. 1 illustrates one embodiment of a composite authentication device having a plurality of components. FIG. 4 illustrates one embodiment where two authentication devices share components. 1 illustrates one embodiment of an authentication device that includes components of authentication logic for managing component authentication key (CAK) pairs for authenticating the components. FIG. 6 is a transaction diagram illustrating one embodiment of authentication between two components. 1 illustrates a static authentication device according to one embodiment of the present invention. 1 illustrates a dynamic authentication device according to one embodiment of the present invention. 1 illustrates an exemplary system architecture in which embodiments of the present invention may be implemented. 1 illustrates one embodiment of a system for executing a location awareness application for an authentication policy. Fig. 3 illustrates an exemplary set of authentication policy rules. 1 illustrates a method according to one embodiment of the present invention. FIG. 4 illustrates one embodiment of the present invention where location is determined or verified by the proximity of another peer or network device. 1 illustrates one embodiment of an authentication system using environmental sensors. Fig. 4 illustrates one embodiment of an authentication method using environmental sensors. 1 illustrates one embodiment of a system for adaptively applying an authentication policy. FIG. 4 illustrates one embodiment of a method for adaptively applying an authentication policy. 1 illustrates an exemplary client with a biometric authentication device. 1 illustrates one embodiment of an authentication engine that includes a gaze tracking module and a face recognition module. FIG. 3 illustrates an exemplary heat map for a web page used in one embodiment of the present invention. Illustrative text, graphics, photos, videos, blank areas and other content that can be displayed to the end user are illustrated. Illustrative text, graphics, photos, videos, blank areas and other content that can be displayed to the end user are illustrated. FIG. 4 illustrates one embodiment of a method for performing authentication based on optotype tracking and face recognition. Fig. 3 illustrates different architecture configurations in which embodiments of the present invention may be implemented. 1 illustrates one embodiment of a client architecture including a client risk assessment agent. Fig. 3 illustrates an exemplary type of client configuration data used by a client risk assessment agent. FIG. 4 illustrates one embodiment of a method for performing client risk assessment during authentication. FIG. 4 illustrates one embodiment of a client performing a secure transaction with a local device. FIG. 3 illustrates one embodiment of a client architecture for performing secure transactions with a local device. FIG. 4 illustrates one embodiment of a method for performing a secure transaction with a local device. 1 illustrates one embodiment of a system for user confirmation of online transactions. FIG. 3 illustrates details of one embodiment of a client used in a system for user confirmation of online transactions. Figure 3 illustrates one embodiment of a method for user confirmation of an online transaction. 1 illustrates one embodiment of a system for delegating trust from a trusted client device to a new client device. FIG. 6 illustrates additional details of one embodiment of a system for delegating trust from a trusted client device to a new client device. FIG. 4 illustrates one embodiment of a method for delegating trust from a trusted client device to a new client device. 1 illustrates one embodiment of a system for synchronizing private data between devices. FIG. 6 illustrates one embodiment of a method for adding a device to a trust circle. FIG. 4 illustrates one embodiment of a method for synchronizing data between devices. Fig. 3 illustrates different exemplary architecture configurations in which embodiments of the present invention may be implemented. Fig. 3 illustrates different exemplary architecture configurations in which embodiments of the present invention may be implemented. FIG. 6 is a transaction diagram illustrating a method by which an authentication device of a client device can be discovered. FIG. 6 is a transaction diagram illustrating a method by which a user can register with an authentication device. FIG. 6 is a transaction diagram illustrating a method by which a key can be registered with an authentication device. FIG. 4 is a transaction diagram illustrating how user authentication can be implemented within an authentication framework. FIG. 6 is a transaction diagram illustrating a method by which transaction details can be verified. FIG. 3 illustrates an implemented query policy filter according to one embodiment of the present invention. FIG. 6 is a transaction diagram illustrating a method by which a query policy registration operation is implemented in one embodiment of the invention. 1 illustrates one embodiment of an architecture for implementing the processing of multiple authentication devices. Figure 3 illustrates three embodiments of the present invention for processing multiple authentication devices. Figure 3 illustrates three embodiments of the present invention for processing multiple authentication devices. Figure 3 illustrates three embodiments of the present invention for processing multiple authentication devices. FIG. 6 illustrates a transaction diagram for detecting and responding to a random challenge timeout. FIG. 6 illustrates a transaction diagram for detecting and responding to a random challenge timeout. FIG. 3 illustrates an architecture for implementing privacy classes according to one embodiment of the present invention. FIG. 6 is a transaction diagram for implementing a privacy class according to one embodiment of the present invention. FIG. 3 illustrates one embodiment of an architecture for using signatures for authentication and transactions. 1 illustrates an exemplary embodiment of a computer system for carrying out embodiments of the present invention. 1 illustrates an exemplary embodiment of a computer system for carrying out embodiments of the present invention.

  Described below are embodiments of devices, methods, and machine-readable media for performing advanced authentication techniques and related applications. Throughout the description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are not shown, or are shown in block diagram form in order to avoid obscuring the basic principles of the invention.

  The embodiment of the present invention described below includes a client device having an authentication function such as biometric authentication or PIN input. These devices are sometimes referred to as “tokens”, “authentication devices” or “authentication units”. Certain embodiments focus on face recognition hardware / software (eg, a camera and associated software for recognizing the user's face and tracking the user's eye movements), and some embodiments include For example, a fingerprint sensor, voice recognition hardware / software (eg, a microphone and related software for recognizing the user's voice), and an optical recognition function (eg, an optical scanner for scanning the user's retina and Additional biometric devices including associated software) can be used. Authentication functions can also include non-biometric devices such as trusted platform modules (TPMs) and smart cards.

  In a mobile biometric implementation, the biometric device may be remote from a trusted party. As used herein, the term “remote” is not part of the security boundary of the computer to which the biometric sensor is communicatively coupled (eg, not embedded in the same physical enclosure as the trusted party computer). ) Means. As an example, the biometric device can be coupled to a trusted party via a network (eg, the Internet, a wireless network link, etc.) or via a peripheral input such as a USB port. Under these conditions, whether the device is authenticated by a trusted party (eg, one that provides an acceptable level of authentication and integrity protection) and / or whether a hacker has compromised the biometric device There is no way for a trusted party to know. Trust in a biometric authentication device depends on the specific implementation of the device.

  The term “local” means that the user has completed a transaction at a particular location, such as an automated teller machine (ATM) or point of sale (POS) retail checkout location. As used herein. However, as described below, the authentication techniques used to authenticate the user can include non-location elements such as communication over a network with a remote server and / or other data processing device. Further, although specific embodiments are described herein (such as ATMs and retail stores), the basic principles of the present invention are implemented within the context of any system where transactions are initiated locally by an end user. It should be noted that

  The term “trusted party” sometimes refers to the underlying authentication described herein, not just the entity that is attempting to perform the user's transaction (eg, a website or online service that performs the user transaction). It is used herein to refer to a secure transaction server that is implemented on behalf of that entity that can implement the technology. The secure transaction server may be under the control of an owned and / or trusted party, or under the control of a third party that provides secure transaction services to a trusted party as part of the business structure. There may be.

The term “server” is used on a hardware platform (or multiple) that receives a request from a client over a network, performs one or more operations as a response, and sends a response to the client, usually including the results of the operation. Are used herein to refer to software that is executed (over a hardware platform). The server responds to the client's request to provide or serve to provide a network “service” to the client. It is important to note that the server is not limited to a single computer (eg, a single hardware device running server software), and in fact, potentially multiple hardware at multiple geographic locations. It may be across the hardware platform.
A. Non-invasive privacy protection certification

  One embodiment of the present invention uses “normal” authentication techniques (eg, finger swipe, code entry, etc.) to train an authentication system for recognizing non-invasive authentication situations. Further, one embodiment returns the device's authentication status to a trusted party rather than sensitive information such as device ID when authentication is required.

  Some embodiments of the invention described below can operate completely frictionless (ie, without the need for explicit user authentication). Behavior or other techniques can be used to continually measure the level of assurance that indicates the current assurance that an authenticated user owns the device. The assurance level can be calculated, for example, based on the time elapsed since the last explicit user authentication (eg, unlocking the SIM card or phone by PIN or finger swipe). Assuming that the amount of elapsed time is within a certain threshold (eg, 5 seconds, 5 minutes, 1 hour, etc.), the device is in a “legitimate user state” and the assurance level is set to the maximum value. (Eg, 100 on a normalized scale of -100 to 100).

  Following the legitimate user status, the assurance level includes explicit user authentication and other indications that the authenticated user owns the device (eg, based on non-invasive input detected from the device sensor) It can be measured based on the combination of elapsed time from the variables. For example, a user's biometric walking is measured using an accelerometer or other type of sensor in combination with software and / or hardware designed to generate a walking “fingerprint” from the user's normal walking pattern can do. Furthermore, the distance to frequent destinations of legitimate users can be tracked and stored and subsequently used to determine the level of assurance. For example, if the user is connected to a trusted party from a known location, such as the user's home or work, the assurance level can be set to a relatively high value while the device is unknown Or, when connecting from a remote location, the assurance level can be adjusted to a low level.

  Various other types of non-invasive measurements can be made by authenticated users, such as, for example, devices that include network identification or client devices such as Bluetooth devices, near field communication (NFC) devices, routers and access This can be done to determine if you have a device connected to a Wifi device, such as a point, smartwatch, other computing device, Nymi bracelet, etc. WiFi devices can include WiFi network visibility in the range of WiFi routers at home and WiFi-enabled computers used by colleagues and family members. In addition, certain specific characteristics of the client device, such as characteristics of the acceleration sensor and sensor pattern noise of the digital camera, can be used for non-invasive measurements. Normal user interaction touch screen gestures can also be analyzed and stored as reference data and user typing behavior from normal user interaction. Of course, the above is merely exemplary, and the basic principles of the present invention are not limited to any set of non-invasive variables.

  The net result is that the assurance level that the legitimate user still owns the device can be sent to the trusted party in the authentication response. In one embodiment, the assurance level is “signed” or authenticated by a key (eg, a trusted party-specific key established and certified during the registration phase as described below). In one embodiment, the assurance level is normalized to a value between -100 and 100, where -100 means "almost certainly not a legitimate user" and 0 means "don't know". 100 means “almost certainly a legitimate user”.

  In one embodiment, the trusted party can ask the client device to use an additional “normal” authenticator response if the assurance level is not allowed for the assumed transaction. Regardless of the level of authentication required, one embodiment does not disclose personal data to trusted parties. Instead, one specific trusted party-specific encryption key is used to authenticate the authenticator to the trusted party.

  One embodiment of an architecture for providing non-invasive privacy protection authentication is for determining a current assurance level based on input (eg, position, gait measurements, etc.) from the non-invasive authentication mechanism 230. Includes a non-invasive privacy protection authentication unit (NIPPA) 210 including a guarantee calculation unit 212 and one or more explicit user authentication devices 220-221 (eg, fingerprint sensor, input device for entering ID code, etc.) It is shown in FIG. In one embodiment, the explicit user authentication devices 220-221 include the same or similar architecture as shown in FIG.

  In the embodiment shown in FIG. 2, the non-invasive authentication unit 230 is a history or user-specific stored in the location sensor 241 and a user / location data storage 245 (which can be implemented, for example, as a file system or database). A position authentication module 231 for performing position-based authentication using the position data. By way of example and not limitation, the position sensor 241 may be a current access point to which a GPS device and / or a client 200 (which may be used to estimate the current position of the device) is connected. Or a module for detecting the cell tower can be included. Any sensor that can provide data related to the user's location can be used. The location authentication module 231 determines the effect of the current location of the client device on the assurance level. For example, if the device is currently in the “home” or “work” position (depending on history or user-specific location data 245), the assurance level can be adjusted upwards, whereas the device If it is in an unknown location that is currently away, the assurance level can be adjusted downward. In one embodiment, in addition to automatically training the system during a “legitimate user state” (described herein), the user can manually designate a specific location as “trustworthy” And therefore have a high level of assurance (eg when the user is at home or at work). The result of the location verification module 231 is provided to a guarantee calculation module 212 that can be broken down into a current guarantee level calculation.

  The user behavior authentication module 232 uses one or more user behavior sensors 242 to determine the degree to which the current user behavior matches historical user behavior (stored in the user and location data storage 245). Rely on. For example, the user behavior sensor 242 can provide accelerometer readings that can be used by the user behavior authentication module to determine the walking of a user who currently owns the device 200. And it is the user (collected before explicit user authentication and stored in the storage device 245) to reach a level of trust that the legitimate user owns the device These measurements can be compared with known gait. The result is provided to the guarantee calculation module 212 so that it can be decomposed into a current guarantee level calculation.

  Various other / additional authentication devices 233 can collect data from other / additional sensors 243 to perform authentication operations so that the results are broken down into current assurance level calculations. The guarantee calculation module 212 can be provided.

  Although shown as separate modules in FIG. 2, the location authentication module 231, the user behavior module 232, and any other authentication module 233 can form part of the guarantee calculation module 212. The basic principles of the present invention can be implemented using a variety of different logical configurations.

  As shown, in one embodiment, the guarantee calculation module 212 relies on the timer 211 when measuring the amount of time that has elapsed since the last explicit user authentication. As will be described in detail below, the amount of time that has elapsed since the last explicit user authentication is used to determine whether the device is currently in a “legitimate user state” and adjust the guarantee measurements accordingly. Can be used for

  When the guarantee calculation module 212 reaches the current guaranteed measurement, it can communicate the measurement to a trusted party (in one embodiment, a cloud service) established via the secure communication module 213. For example, each authenticator 220-221 including the non-invasive authenticator 230 can exchange a trusted party-specific and certified key in a registration operation (pre-authentication). The assurance level returned to the authentication operation can be part of a message signed / encrypted with a trusted party-specific authentication key. Further, as described below, the message can also include a nonce (eg, a random challenge) generated by a trusted party.

  In one embodiment, the secure storage device 225 is a secure provided for storing an authentication key associated with each of the authenticators and used by the secure communication module 213 to establish secure communication with a trusted party. It is a storage device.

  As described above, in one embodiment, NIPPA 210 may use the existing (valid user) state to maintain a “valid user” state within a defined time window (up to T1 seconds) after each such successful authentication. Leverage explicit user authentication techniques (eg, password-based system login, SIM card unlock, etc.). The NIPPA 210 can periodically measure the user's behavior from the various sensors 241 to 243, and can update the internal reference data vector according to the measured value in the “valid user” state. Although not in the “valid user” state, NIPPA 210 can calculate a normalized “distance” to the reference data vector based on the current measurements. This “distance” is certainly considered to be that the legitimate user still owns the authenticator.

  If asked to authenticate the user, NIPPA 210 can check to determine if it is in a “legitimate user” state. If so, authentication is considered successful and a maximum assurance level (eg, 100) is returned. If not in the “legitimate user” state, the NIPPA 210 may return the assurance level calculated by the assurance calculation module 212 based on the latest measurements. The NIPPA 210 can combine the guarantee level with the time difference td (td = tc−tm) of the measurement value tm with respect to the current time tc. In one embodiment, this is done using the following logic.

(1) If (guaranteed level ≧ 0), the obtained guaranteed level = guaranteed level ^* (maximum (T0−td, 0) / T0), T0 is the maximum allowable time difference;

  (2) In the case of (guarantee level <0), the obtained guarantee level = guarantee level.

  The operation of one embodiment of the present invention according to the above equation is illustrated in FIG. At time t1, the user performs explicit authentication (eg, finger swipe, PIN entry, etc. to unlock the SIM card). The time window up to t1 + T1 is considered a “legitimate user” state. As described above, the non-invasive authentication unit can train within a valid user state. For example, the user's gait can be measured and / or the location the user has visited can be recorded and subsequently used to perform non-invasive authentication.

  At time t2 (outside the valid user state), the guarantee calculation module 212 calculates a guarantee level based on the non-invasive authentication unit. The result is positive indicating that the device is almost under the full control of a legitimate user. After this calculation, the assurance level decreases with time (for example, a legitimate user may expose the device to an unauthorized person). For example, at time t3, the guarantee level is greatly reduced from time t2. In one embodiment, the non-invasive guarantee level is only calculated periodically to avoid consuming excessive power and CPU performance.

  At t5, another non-invasive guarantee level calculation occurs. This result is negative, indicating that the device may not be under the full control of the legitimate user. This negative assurance level is not changed until another calculation is performed based on the non-invasive authenticator (eg, at time t6).

  A method according to one embodiment is illustrated in FIGS. The method can be implemented in a system architecture such as that shown in FIG. 2, but is not limited to any particular system architecture.

  In 401, an explicit authentication event occurs such as a swipe on the fingerprint sensor or a PIN entry to unlock the device. A timer can also be started to measure the elapsed time since an explicit authentication event. At 402, the legitimate user state is entered, and at 403, various aspects of the user's behavior can be measured and stored for later reference (eg, location, user walking, etc.). If an authentication request (eg, resulting from a transaction with a trusted party) occurs during the legitimate user state determined at 404, a maximum assurance level is selected at 405 and sent to the trusted party at 420.

  At 406, the system exits the legitimate user state (eg, because the timer indicates that the specified amount of time has elapsed). At 407, the system periodically measures user behavior by comparing the data from the sensor against the internal reference data stored in operation 403. As an example, a measurement related to a user's gait (collected when in a valid user state) can be compared to a current gait measurement (collected at 407) and the correlation between the two ( (Referred to as “distance” to the reference data) can be calculated. If an authentication request is received outside the legitimate user state determined at 408, the current assurance level is calculated at 409 based on the distance to the internal reference data and the potential time from an explicit authentication event. The The assurance level is then sent at 420 to the trusted party.

  Referring to FIG. 5, if the assurance level sent to the trusted party is acceptable for the current transaction with the user determined at 501, the trusted party authenticates the client device successfully. A response can be sent. Otherwise, at 503, the trusted party sends a response to the client indicating that additional authentication is required (eg, potentially explicit user authentication if non-invasive authentication is insufficient). be able to.

  In an alternative embodiment, the trusted party can initially specify the level of assurance required for a particular transaction, and if the non-invasive authentication technique is insufficient, the system can potentially provide explicit user authentication. To ensure that the required assurance level is met. The system can then send an indication to the trusted party that the authentication was successful (rather than the assurance level).

  As described above, one embodiment of the present invention calculates the distance from a set of known user positions to determine the assurance level. Referring to FIG. 6, position-based measurements (eg, GPS, etc.) can be used to calculate a “distance” function as follows.

  In the preprocessing operation, all measurement positions (Ln) are assigned to their closest “region”. A region is defined as a circle having a radius of r (eg, 10 meters). The regions are arranged so that the minimum number of regions covers all Ln. All regions that cover less than M locations are deleted from the set of regions (ie, they are not considered the user's “frequent” locations).

The “distance” (d) is determined by using distance = (distance of the current position (Lc) to the nearest center of the region (Rn)) / r, where r is the radius of the region. If Lc is in an existing region, this value is small or equal to 1 and can be very large if Lc is outside. And the guarantee level is calculated using: guarantee level = Max (100−50 ^* floor (d), − 100). This is in the range of -100 to 100.

  In some of the above embodiments, the legitimate user still owns the client device within a specific time window explicitly following authentication or if the current behavior is very similar to the measured behavior Assume that However, the above embodiment only updates the behavior criteria data within a specific time window after explicit authentication.

As shown in FIG. 7, one embodiment of the present invention uses an extended time window to update the behavior criteria data in addition to the standard time window for the legitimate user status (ie, Train the system). As a result, a complete time window (including standard time window and extended time window) can be defined as follows: (1) A valid user state time window follows a successful explicit user authentication. In the case (ie, t1... T1 + T1), or (2) the returned guarantee level is equal to or greater than a certain threshold T (eg, T = 90 at t2, t4, etc.). Setting the threshold to zero is undesirable because it is very easy for an attacker to “shift” the behavioral criteria for his favor.
B. Adaptive authentication technology

  FIG. 8 illustrates one embodiment of the present invention for implementing an adaptive authentication technique. As with the embodiments described above, this embodiment includes one or more non-invasive authentication modules 230 for performing non-invasive authentication (eg, based on location, sensed user behavior, etc.) Including one or more explicit authentication modules 222 for performing explicit user authentication (requires PIN, fingerprint scanning, etc.). Further, as in the previous embodiment, the guarantee calculation module 212 may, for example, the time since the last explicit authentication (provided by the timer 211) and / or the authentication provided by the various authentication modules 230, 222. Perform warranty calculations based on the data. The secure communication module 213 establishes secure communication with the trusted party 250 (eg, using a secure encryption key as described above).

  In one embodiment, the adaptive authentication module 800 uses non-invasive authentication techniques and explicit / invasive authentication that can be used to reach a sufficient level of assurance for the current transaction with the trusted party 250. Dynamically select from technology. Alternatively or additionally, the adaptive authentication module 810 at the trusted party 250 can perform an authentication selection technique to reach a sufficient level of assurance. The basic principles of the present invention remain the same regardless of whether the authentication selection technique is implemented in the client device 200 (by the adaptive authentication module 800) or in the trusted party 250 (by the adaptive authentication module 810).

  In addition, the “trusted party” 250 shown in FIG. 8 can implement the authentication techniques described herein on behalf of a trusted party and can provide results to the trusted party. A reliable third party server can be presented. Therefore, while embodiments of the present invention are described in terms of a “trusted party”, the basic principles of the present invention are implemented using a server outside the boundaries of a network operated by a trusted party. Can do.

  As described in more detail below, in one embodiment, the adaptive authentication module 810 is based on variables associated with the client device (eg, based on the current IP address, round trip delay time of the IP packet, etc.). A risk engine 812 to determine the risk level. Further, the assurance level gain analysis element 811 can determine the amount that must be increased so that the current assurance level reaches an acceptable assurance level. Although these elements are shown in FIG. 8 as components of the trusted party adaptive authentication module 810, they are also implemented in the client adaptive authentication module 800 while still adhering to the basic principles of the present invention. May be.

  In one embodiment, once the client device 200 is connected to the trusted party 250 (eg, to initiate a transaction), the risk engine 812 may determine the risk (or assurance level) based on all currently available data. ). This may be sent, for example, between the client device 200 and the trusted party 250, eg, the geographical location of the client device 200 (eg, derived from an IP address or provided by a mobile network operator). The round-trip delay time of the packet, the number of hops for network packets sent between the client device 200 and the trusted party 250, the specific “user agent” string sent by the user agent running on the client device 200 Can be included. In one embodiment, risk engine 812 may then use an implicit “risk score” that can be used to determine an additional amount of assurance required to authenticate the user for the specified transaction. Evaluate this data to reach (or a preliminary assurance level that is inversely related to the risk score).

  In one embodiment, based on the implicit risk score, the adaptive authentication module at trusted party 810 or client device 800 has the potential to increase the overall assurance level to the level required for the intended transaction. The above set of authentication modules 222, 230 is determined (ie when combined with a pre-assurance level / implicit risk score). In one embodiment, the assurance level gain analysis module 811 determines the required amount of gain, and the adaptive authentication modules 800, 810 comprise the required assurance level gain indication as a parameter. The adaptive authentication module 800, 810 can then determine this “gain to determine the most convenient set of authentication techniques (non-invasive 230 and / or explicit 222) to achieve (at least) the required gain. "Parameter. The adaptive authentication module 800 can include a formal description of a selected set of authentication techniques, depending on the trusted party 250 (eg, as an authenticated extension). The trusted party 250 can then verify whether the resulting overall assurance level meets the required level.

  By way of example and not limitation, the adaptive authentication module 800 is derived from an authentication modality such as device fingerprint (eg, recognition of sensor defects or camera sensor pattern noise); environmental information (eg, GPS-based location; WiFi network). Location; presence or absence of wired or wireless connection to other gadgets such as Nymi, smartwatch (pevel) or headset, etc .; behavior data (eg, how the user takes the device from the pocket, behavior input, walking, ...); the time that the device was in a "trusted" state; and one or more authentication modalities (biometric or other) that are potentially necessary to achieve the required (remaining) gain at the assurance level ) Can be combined with new explicit authentication results.

  The result of the above technique is that the user can select the most convenient authentication method. In the case of a smartphone, this can simply have access to the phone (see above). Instead of asking the user to select an authentication method and then requiring the user for other explicit authentication, the trusted party 250 can identify adaptive authentication that identifies at least a set of invasive authentication techniques Instructions for necessary guarantee level gain are transmitted to units 800 and 810. The adaptive authentication modules 800, 810 do not always require explicit (invasive) user authentication (such as PIN entry or finger swipe), nor simply those based on non-invasive modalities. Instead, the authenticator selects the appropriate combination of all available modalities (on the client side) so that the required assurance level gain is achieved.

  As described in detail above, hacking / spoofing modalities can be time consuming, so the time since the device was in a reliable state is important. For example, if a user loses the phone and someone tries to hack it, it can be used to gain access after the fingerprint is captured from the display and the appropriate rubber finger is created May take a day. As a result, the PIN input required within 24 hours from the last trusted state provides sufficient protection against this type of attack. The next level of attack is one where fingerprints are captured before accessing the device. These attacks are rarely seen in practice. However, if the trusted party 250 needs protection against such an attack, the adaptive authentication module 800, 810 can detect the presence of location data or other gadgets or peripherals to accept the biometric modality. You may need to consider.

  A method according to one embodiment of the present invention is illustrated in FIG. As described above, a “trusted party” as used herein may be an actual party that relies on accurate authentication of the user, or a third party that authenticates the user on behalf of the trusted party. Service.

  At 901, a client device connects to a trusted party to perform a transaction (eg, a transaction logging into an online account, a financial transaction, etc.). At 902, the trusted party analyzes any available data associated with the client device to determine the risk value and the assurance level gain required to authenticate the user. For example, the data may indicate that the user is connected to a trusted party from an unknown network location (eg, a foreign country that the user has not visited before) and / or a network routing hop between the client and the trusted party It can be shown that the number or latency is greater than or equal to the threshold. In such a case, the risk value can be set to a relatively high value (or conversely, the implicit assurance level can be lowered). However, if the user has recently been explicitly authenticated (eg, PIN entry) to the device, this tends to reduce the risk level (or increase the implicit assurance level).

  The assurance level gain can be determined based on the assurance level required to complete the transaction. This can be achieved, for example, using the following equation: Implicit guarantee level + guarantee level gain = necessary guarantee level or guarantee level gain = necessary guarantee level-implicit guarantee level. In addition, various other equations can be used to determine the assurance level gain while adhering to the basic principles of the present invention.

  At 903, an indication of the required guarantee level gain is received. If non-invasive authentication techniques are sufficient to meet the assurance level gain determined at 904, they are used at 905 to authenticate the user. Otherwise, at 907, one or more explicit authentication modalities are potentially implemented in combination with one or more non-invasive authentication modalities. As described above, the modality may be selected so as to have the least burden on the end user (eg, based on user-specified preferences).

  FIG. 10 graphically illustrates how the above-described embodiments of the present invention can evaluate assurance levels to determine authentication modalities. At time t1, the user performs explicit authentication (eg, finger swipe, PIN entry, etc.). At time t2, the trusted party requests authentication with a guarantee level gain of al4. The non-invasive authentication modality provides all of the higher assurance levels than al4, so there is no need to trigger explicit authentication.

  In contrast, at time t4, the trusted party requests authentication with a guarantee level gain of al4. The non-invasive authentication modality provides al5 at that time (as shown in the graph). As a result, in this case, the adaptive authenticator module selects at least one explicit authentication modality to increase the assurance level from al5 to al4.

  One embodiment of the present invention uses implicit location-based authentication techniques to protect end user privacy. As mentioned above, sharing a user's current location (eg, as provided by GPS) with a trusted party poses an important privacy issue. Thus, users often do not want to share such data.

  To address these issues, one embodiment of the present invention uses geolocation as a factor in performing implicit user authentication, but does not disclose the user's location to a trusted party . This embodiment can be implemented alone (eg, as part of a larger comprehensive authentication process) or in combination with other non-invasive 230 and / or explicit 222 authentication techniques described above. Instead of sending the actual location from the client device, a unique assurance level may be sent (at least in part) based on the geolocation data, thereby protecting the user's privacy.

  One embodiment uses the following operations for user / device registration and trusted party registration.

  1. The user obtains and specifies one or more locations where he / she typically performs authentication by the website. This can be a predefined mile or area within a particular location (such as work, home, transportation route, etc.). These selected locations can be stored locally on the client device and are not sent to a trusted party. These operations can be executed by the position authentication module 231 described above.

  2. In one embodiment, after registration is complete, the client device can be trusted via a secure communication channel (eg, using the secure communication module 213 and other registration techniques described herein). Share keys with the parties.

  In one embodiment, the following operations are performed during authentication.

  1. The client device determines its current position using one or more geolocation techniques (eg, using a position sensor 241 such as an embedded GPS to obtain the current position).

  2. The position authentication module 231 in the client compares the already registered position with the current position, and generates a score (for example, 0 to 100) indicating the distance. The guarantee calculation module 212 can then include a score in the guarantee calculation (as described above).

3. The client device generates a signature, signs the score / assurance level, and sends it to the trusted party 250 for final authentication.
C. Composite authentication section

Some of the embodiments of the invention described herein use a client-side “authentication unit” that encapsulates the following security-related functions:
1. 1. Storage and use of encryption certification key 2. Generation, storage and use of encryption authentication key 3. Local user verification or user existence verification Secure display of information about end users

In one embodiment, some of the functions (eg, FIGS. 3 and 4) are optional. Furthermore, one embodiment of the present invention includes an authenticator that achieves the following security objectives.
1. Verify that the certification key is: (a) used only to prove an authentication key generated and protected by FIDO authentication and (b) does not leave the FIDO authentication boundary.
2. If local user authentication (sometimes referred to as “user authentication”) is claimed to be supported, verify that: (a) authentication is a software application (eg, PIN to authenticator) Cannot be bypassed / forged by “entering malware”; (b) the confidentiality of the authentication data is protected (eg, the malware cannot access the PIN or reference data entered by the user) And (c) user authentication is required before generating a new authentication key, and time is reached before using such an authentication key.

  One way to implement the authenticator is to implement all of the 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) (eg, on a client platform that supports trusted execution). In this implementation, the TA is signed to ensure that the authenticator cannot be changed at runtime and that the TEE protects the TA.

  In one embodiment of the present invention, each authentication unit is logically divided into a plurality of independent components each including independent security and authentication functions. For example, in FIG. 11, rather than implementing all of the components responsible for the above functions in a single module protected by a single shell, the authenticator 1100 may include two separate independent authenticators: Implemented by components: a user verification component (UVC) 1101 and an authenticator kernel (AK) 1103, each with its own protection logic 1110 and 1112. In this example, the AK 1103 securely manages the certification key 1104 and the authentication key 1105 for the authentication unit 1100, and the UVC 1101 manages the user authentication / presence function 1106 and the secure display function 1107 (specific examples thereof). Are described below and in co-pending applications).

  As described in detail below, each component's protection logic 1110, 1112 is a component authentication engine for authenticating all components by one or more other components running on the client device. (See, eg, FIG. 13 and related documents). In addition, the protection logic can take advantage of additional hardware / software protection mechanisms built into the client platform (eg, secure element (SE), chain of trust technology, trusted user interface technology, OS-based Protection mechanism). Details associated with each of these embodiments are described below.

  FIG. 12 illustrates an embodiment of the present invention constructed from a set of authenticator components in which a plurality of logical authenticators 1201-1202 are protected. Specifically, the component building block for the logical authentication unit 1201 includes a user verification component (UVC) 1210 for managing user verification and existence, and an accuracy in which information displayed to the end user is confirmed by a transaction. A display component (DC) 1212 for ensuring that the information is secure (ie "what you refer to is what you sign" or WYSIWYS), and can be trusted as part of the registration process To establish secure communication with a trusted party using a certification key 1215 (to prove the model and / or integrity of the authenticator to the parties) and a unique authentication key for each trusted party And an authentication unit kernel (AK) component 1214 for securely managing the authentication key 1216. The component building block for the logical authenticator 1202 includes a UVC 1220 for managing user verification and presence, and an authenticator kernel (AK) component 1214 for securely managing the certification key 1215 and the authentication key 1216. Including. Therefore, in this example, multiple logical authenticators share the same basic AK component 1214 for managing and protecting keys. In other embodiments of the present invention, other types of components can be shared among multiple authenticators. As described above, each of the components has its own independent protection logic to ensure that it meets the security goals.

  An authentication unit constructed from components in this way is referred to as a “composite authentication unit” because each is composed of independent and separate components having their own protective shells. One advantage of the composite authenticator approach is that once a component is built for a single authenticator, it can be used between multiple authenticators, thereby making the new secure authenticator more efficient. It is possible to be built. For example, as shown in FIG. 12, the same authenticator kernel component 1214 is shared between the two logical authenticators 1201-1202. Further, each authenticator component can be implemented in a manner optimized for its specific needs. For example, but not limited to its authentication and user authentication of a face recognition-based authenticator that biometric segmentation and query algorithms may be too large to implement in a secure element (SE) or trusted execution environment (TEE) SE / TEE can further be used to protect the key. In this example, user verification components (eg, including segmentation and matching algorithms) can be executed outside of SE / TEE, while authentication kernel components may be implemented within SE / TEE. . Similarly, a fingerprint-based authenticator implemented in TEE, for example, SE to protect its proof and user authentication key and thus protect against hardware-based attacks such as differential power analysis (DPA). An authentication kernel can also be used.

In one embodiment, the following security measures are implemented to provide an acceptable level of security for the authentication part of the components described herein (eg, meet the specified security objectives above): For "acceptable"). These security measures are described with reference to FIG. 13 which shows additional details associated with each of the components 1210, 1212, 1214 used to implement the authenticator 1201 in FIG.
1. Security Measure (SM) 1: 1: In one embodiment, each component (eg, the user verification component 1210, display component 1212 or authentication kernel 1214 shown in FIGS. 12-13) registers with other components. Its own “component authentication key” pair (CAK) (eg, CAK pairs 1304, 1305, and 1306, respectively) used to (potentially mutually) authenticate messages sent to other components Have As shown in FIG. 13, each component 1210, 1212, 1214 uses a CAK pair 1304, 1305, 1306, respectively, to enter an authentication transaction between components, respectively. 1302 and 1303. In one embodiment, the basic principles of the present invention are not limited to such an implementation, but CAK pairs 1304, 1305, 1306 are public / private key pairs. In this implementation, each of the components has a public key for those components that it needs to authenticate. For example, UVC 1210 knows DC and AK public keys 1321 (or at least the public key can be verified); DC 1212 knows UVC and AK public keys 1321; AK 1214 Know the public keys of DC and UVC. In one embodiment, at startup, the components first enter a registration transaction for other components that need to communicate by sharing their public key with these components. It can then be authenticated using these components using the techniques described below.
2. Security Measure (SM) 2: Each component can authenticate other components that receive the message by verifying the public CAK of these components. For example, in FIG. 13, AK 1214 can verify the public CAK of all UVC 1210 and DC 1212, which supports (ie, public keys in CAK pairs 1304 and 1305). The UVC and DC can also validate AK 1214's public CAK (ie, CAK pair 1306) if mutual authentication is implemented.

FIG. 14 is a transaction diagram illustrating how authentication can be performed between two components (AK 1214 and DC 1212). In transaction 1400, AK component authentication logic 1303 generates a challenge and sends it to DC component authentication logic 1302 in transaction 1401. In one embodiment, the challenge is a random number or nonce selected by component authentication logic 1303. In operation 1402, the DC component authentication logic 1302 uses the private key from the CAK pair 1305 to generate a signature and potentially additional data (eg, whether the user has approved the transaction content) across the challenge. To do. As will be appreciated by those skilled in the art, generating a signature can include implementing a hash function across the challenge using a secret key. In transaction 1403, the DC component authentication logic 1302 returns a signature to the AK component authentication logic 1303 for verification. The AK's component authentication logic 1303 receives the current challenge (eg, the nonce it was previously generated), the signature generated using the DC's CAK pair's private key, and the DC's CAK pair's public key. know. In transaction 1404, the public key of the DC's CAK pair is used to verify the signature using a random number, thereby authenticating the DC. The DC can also verify the AK 1214's public key using a similar set of transactions if mutual authentication is implemented.
3. Security Measure (SM) 3: Depending on the specific implementation, additional security mechanisms can be used to protect communications between components. These additional security mechanisms are illustrated in FIG. 13 as supplemental hardware / software protection mechanisms 1310. By way of illustration and not limitation, by way of example, these hardware / software protection mechanisms 1310 include a secure element (SE), a chain of trust technologies, a trusted user interface technology, an OS level access control mechanism. , Including those mechanisms built into the client platform, such as white box encryption, code obfuscation and execution integrity protection. Using ARM® TrustZone ™ or similar technology, for example, the operating system can access AK's application programming interface (API) only for trusted programs (eg, legitimate UVC and DC). Can be limited. As another example, the operating system can also add a UVC or DC package 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 described above.

  By way of example, in one embodiment, AK 1214 provides a good protection mechanism for encryption keys, but is implemented as an applet in a secure element that does not have a user interface. UVC 1210 can be implemented as a combination of hardware (e.g., a fingerprint sensor) both utilizing ARM TrustZone or similar technology and a trusted application within a trusted execution environment. The DC 1212 can be implemented as a trusted application using a “trusted user interface” function as defined by the global platform. Therefore, in this embodiment, when the user swipes a finger on the fingerprint sensor, a reliable application is activated and verifies the fingerprint data against the stored reference data. The score is then sent to AK 1214 implemented as a secure element that subsequently enters a series of authentication transactions by a trusted party 1320 to authenticate the user (eg, as described in a co-pending application). .

  In addition, different UVCs may be implemented as software components running on a rich OS (eg, Android) using a combination of white box encryption, code obfuscation, and runtime integrity protection. For example, an integrated video camera can be used in combination with face recognition software. Other UVCs are implemented as a trusted application or software that runs on a rich OS using a combination of white-box encryption, code obfuscation and runtime integrity protection and provides a PIN-based user verification method. Also good.

  Therefore, the component-based approach described herein can be easily adapted to the requirements of different authentication technologies. For example, some types of authentication, such as voice recognition and face recognition, are implemented as software components using normal location operating systems due to significant storage requirements and hardware interface requirements for these authentication types. It is necessary to All of these different types of authentication are implemented in a secure and reliable manner using different UVC components that utilize the same AK component (which can be implemented as a secure component as described). be able to.

  Note that with the above approach, the various components communicate logically using cryptographically protected (eg, signed) messages. This logical communication can be further “facilitated” by several other entities (eg, secure transaction logic described below). Further, in one embodiment, the inter-logical component messaging described herein can be performed directly with the authenticator kernel 1214 (eg, using a proof key 1215 and an authentication key 1216, respectively). Transparent to the trusted party 1320 entering. In one embodiment, the AK uses the certification key 1215 to verify the authenticator model and / or integrity during registration. For example, the trusted party can send a challenge that the AK signs using the certification key 1215. The trusted party then uses the corresponding key (eg, the public key if the certification key is a private key) to verify the signature. When the authenticator registers with a trusted party, the authentication key 1216 is assigned to that trusted party. The AK then uses an authentication key 1216 associated with the trusted party to ensure secure communication with the trusted party after registration.

  As an additional security measure, in one embodiment, each component's component authentication logic 1301-1303 can delete that CAK pair if a component compromise is detected.

Two different types of composite authentication units can be implemented using the basic principles of the present invention: a “static” composite authentication unit and a “dynamic” composite authentication unit.
Static compound authentication part

Referring to FIG. 15, in one embodiment, a composite authentication unit 1501 having the following characteristics is referred to herein as a “static” composite authentication unit.
1. For each authenticator 1501, the trusted party 1320 has / needs access to a public certification key (corresponding to certification key pair 215 rather than public "component authentication key" (CAK) 1304, 1306); and 2 . For each supported combination of components (eg, UVC, DC and AK), a specific authenticator certification ID (AAID) 1505 is pre-designated.

  Therefore, as shown in FIG. 15, for the static composite authentication unit, each individual authentication unit 1501 is specified by its specific AAID 1505. The AK has one or more certification keys 215 and is one of the predefined AAIDs (and associated certification keys) that will be used in conducting transactions with the trusted party 1320. Select.

  Since the CAK pair is not shared with the trusted party 1320, it can be unique to the authenticator without affecting user privacy. This also means that such a key can be revoked individually if a successful hacking of an individual component is detected. Since CAK is not used as a “certification key” (visible to the public), hacking a component is not considered equivalent to hacking an authenticator. Further, since the communication and security mechanism of the composite authentication unit 1501 is not visible outside the authentication unit, the implementation of the static composite authentication unit is a specification that defines the interaction between the authentication unit 1501 and the trusted party 1320. Does not affect. In one embodiment, each component 1510, 1514 is assigned a unique component ID that can be similar to an AAID, but it is only related to AK 1514 (not related to RP or other external entities). do not do).

  As a further optimization, in one embodiment, the online certificate status protocol (OCSP, RFC 2560) can be used as a revocation checking method (eg, “validation”) for each CAK certificate. Specifically, AK 1514 may require a sufficiently recent OCSP response for UVC or DC certification associated with a public CAK to accept incoming messages. AK 1514 can also have one certification key used for all AAIDs, or it can have one certification key per AAID, or a combination thereof, as needed.

  In one embodiment, the AK can maintain a static list of AAIDs. Alternatively, it can allow an AAID received from an external entity (eg, 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 / DC public CAK). Private signing_key can be owned by an AK vendor. The public signing_key is a direct part of the AK's trust store (in the trust store implementation) or uses several certificates stored in a trust store (ie chained to such a certificate). Can be verified.

The architecture of the user device 1500 shown in FIG. 15 also includes a browser / application 1510 for establishing communication with the trusted party 1320 and secure transaction logic 1520 for enabling communication with the authenticator. For example, as shown, in one embodiment, the secure transaction logic 1520 passes between the components 1510, 1514 of each authenticator 1501 by exposing an application programming interface (API) for the various components. Allows messages to pass through. Therefore, in this embodiment, all communication between components such as the exchange of registration data and messages occurs via the secure transaction logic 1520. By way of example, secure transaction logic 1520 can also be implemented as a “secure transaction service” described in a co-pending application (part of which is described below). Browser / application 1510 can be used to establish communication with trusted party 1320 via a network, such as the Internet.
Dynamic composite authentication part

Referring to FIG. 16, a composite authentication unit 1601 having the following characteristics is a “dynamic composite authentication unit”:
1. A “component authentication key” (CAK) so that the trusted party 1320 has and requires an associated public key (eg, referred to as “key registration data” in the OSTP specification). ) 1604, 1604 are processed as certification keys; and A trusted party 1320 receives a plurality of AAIDs 1602, 1603 (depending on the number of components in the authenticator 1601). In one embodiment, it receives AAIDs 1602, 1306 of all components 1610, 1614 of authenticator 1601 as part of a registration message sent from AK 1614 via secure transaction logic 1620 and browser / application 1610. To do. FIG. 16 illustrates only UVC 1610 and AK 1614, but an alternative embodiment (as shown in FIG. 3) sends AAID for AK, DC and UVC to RP 1320. As mentioned above, however, the basic principles of the present invention are not limited to any particular set of components for implementing authentication. In one embodiment, the registration message sent to RP 1320 may also include multiple (chained) signatures, one with AK's certification key 1605 and other components (eg, UVC certification key 1604 and DC certification). For each of the keys (not shown). As described above, in one embodiment, AK 1614 includes the other component's certification message in its own certification message for RP 1320 only if it trusts communication with the other component.

Therefore, the dynamically configured authentication unit 1601 dynamically combines a plurality of components (or in the other method in which two authentication units are configured to acquire a new authentication unit). Realized. Since CAK is related to RP in this implementation, they do not have to be a specific authenticator in one embodiment to protect user privacy. Instead, they are pre-generated / populated as a shared key, or using a direct anonymous authentication (DAA) scheme, a cryptographic protocol that allows trusted platform authentication while maintaining user privacy Authenticated. Since multiple AAIDs and chained certification messages are visible to the RP, the implementation of the dynamic composite authentication unit affects the authentication specification used between the authentication unit 1601 and the trusted party 1320.
UVC / DC certification verification

  Regardless of whether a dynamic or static authenticator is used, in one embodiment, UVC 210 and DC 212 process according to the authentication specification used between AK 214 and trusted party 1320. Send their output data, such as user validation results (UVC) and user consent of the displayed transaction text (DC) to AK 214, as can be done.

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

  For authentication, in one embodiment, UVC 210 and DC 212 create a message signed by CAK (not a user authentication key).

The following verification steps are implemented by AK in one embodiment of the present invention.
1. Search the internal trust store that contains a list of acceptable public CAKs. The public CAK may be stored directly in the trust store or may be a public key certificate for each of the CAKs that are chained to the root certificate in the trust store.
2. The AK verifies the signature of the input data from the UVC and / or DC using a public CAK (eg, as described above with respect to SM1 and SM2).
3. Check for additional platform specific protection mechanisms, such as using the package ID of the input data or the protection mechanism provided for similar platforms.
4). Check the revocation status of a certificate containing a public CAK of UVC or DC. Since AK is only interested in a very small number of revocation information in the certificate / key (ie current UVC or DC), the Online Certificate Status Protocol (OCSP) (described above) is used for revocation checking. Can be used. AK is not assumed to have a network connection, so the OCSP response is predicted as part of the input data from UVC and / or DC.
Optimized verification method

While asymmetric key operations are very expensive compared to symmetric key operations, further optimization can be realized in one embodiment. In such a case, the key registration message created by the UVC and / or DC sent to the AK includes a symmetric key SK (eg, instead 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). Good. Modified signature messages generated by UVC and / or DC and sent to AK are not asymmetrically signed using CAK, but instead are hash-based message authentication codes (HMAC) calculated by SK Be secured using. The AK verifies the HMAC using the symmetric key received as part of the key registration data message.
D. Location recognition authentication technology

  One embodiment of the present invention implements an authentication policy that allows an authentication mechanism to be selected based on the physical location of the client device used for authentication. For example, the client and / or server can make a determination of the physical location of the client device and provide that location to a policy engine that evaluates an ordered set of policy rules. In one embodiment, these rules specify the location and authentication mechanism or class of mechanisms that must be applied if the client's location matches the location definition in the rule.

  As shown in FIG. 17, one embodiment of the present invention includes a client device 1700 having an authentication policy engine 1710 for implementing the location-aware authentication policy described herein. In particular, this embodiment includes a position class determination module 1740 for using the current position of the client device 1700 provided by a position sensor 1741 (eg, a GPS device) to identify the current position “class”. As described in detail below, different location “classes” may be defined including known geographic points and / or regions. Location class data can be continuously updated and stored in a persistent location data store 1745 (eg, a flash store or other persistent store). The position class determination module 1740 can then compare the current position provided by the sensor 1741 against the defined “class” to determine the current position class for the client device 1700.

  In one embodiment, the trusted party 1750 specifies an authentication policy to be implemented by the authentication policy engine 1710 for each transaction (as indicated by the dotted line from the trusted party to the authentication policy engine). Hence, the authentication policy can be tailored to each trusted party's authentication requirements. Furthermore, the level of authentication required can be determined based on the current transaction (as defined by the authentication policy). For example, transactions that require a significant amount of gold transfer may require a relatively high authentication guarantee threshold, whereas non-financial transactions require a relatively low authentication guarantee threshold. be able to. Therefore, the location-aware authentication techniques described herein may be sufficient for certain transactions, but may be combined with stricter authentication techniques for other transactions.

  In one embodiment, the location class determination module 1740 provides the determined class to an authentication policy module 1711 that implements a set of rules for identifying the authentication technique 1712 to use for the determined class. By way of illustration and not limitation, FIG. 18 is an example of rules 1-5 that specify one or more authentication techniques 1-5 that can be used for each defined location class 1-5. A simple set is illustrated. Although shown as a table data structure in FIG. 18, the basic principles of the present invention are not limited to a particular type of data structure for implementing a rule set.

  When the authentication policy engine 1710 selects a set of authentication techniques 1712, the authentication policy engine 1710 may include one or more explicit user authentication devices 1720-1721 and / or non-invasive types for authenticating a user by a trusted party 1750. Techniques can be implemented using authentication techniques 1742-1743. By way of example and not limitation, explicit user authentication 1720-1721 requires the user to enter a secret code such as PIN, fingerprint authentication, voice or face recognition, and retinal scan. Can include.

  Non-invasive authentication techniques 1742-1743 may include a user behavior sensor 1742 that collects data relating to user behavior for authenticating the user. For example, a user's living gait uses an accelerometer or other type of sensor 1742 in combination with software and / or hardware designed to generate a walking “fingerprint” of the user's normal walking pattern. Can be measured. As described below, other sensors 1743 can be used to collect data used for authentication. For example, network data may be identified and collected for network / computing devices in the local vicinity of client device 1700 (eg, known peer computers, access points, cell towers, etc.).

  In one embodiment, secure storage device 1725 is a secure storage device used to store an authentication key associated with each of authentication devices 1720-1721. As described below, the authentication key can be used to establish a secure communication channel with the trusted party 1750 via the secure communication module 1713.

  Various different “classes” of positions can be defined consistent with the basic principles of the present invention. By way of example and not limitation, the following class of locations can be defined.

  Class 1: Client is within a specified radius at a specified location. In this class, the associated authentication policy is applied if the current client location is in a region surrounded by a circle of a predetermined radius centered on the specified latitude and longitude.

  Class 2: The client is within the specified border area. In this class, if the client is placed in an area enclosed by a polygon defined by an ordered set of latitude and longitude pairs (eg, a closed polygon), the associated authentication policy is applied. The

  Class 3: The client is outside the specified boundary. In this class, if the client is located outside the area enclosed by a polygon defined by an ordered set of latitude and longitude pairs (eg, a closed polygon), the associated authentication policy applies Is done.

  In one embodiment, the additional classes are defined using a Boolean combination of the above defined class and policy rules. For example, nesting of Boolean operations AND, OR, NOT, and Boolean operations enables the expression of complex conditions. Such a policy can be used, for example, to implement a policy that applies when the client is located in one of various facilities owned by the enterprise.

  A variety of different mechanisms can be used to determine the current physical position of the client (generally shown in FIG. 17 as position sensor 1741), including but not limited to:

  GPS: Embedded GPS sensors can directly provide client location details. The newly emerging standard seeks to add location authentication that is provided as a function to overcome this shortcoming in current GPS solutions.

  Geo-IP search: Reverse lookup of a client's IP address can be used to determine a rough approximation of the client's location. However, the location reliability obtained by this method requires the IP address to cross-check against a known compromised host blacklist that anonymizes the proxy provider or the host's source IP address. You need a similar solution designed to be obfuscated.

  Cell tower triangulation: Integration between the client, server and wireless carrier infrastructure allows the client and server to make high resolution determinations of physical locations using mobile signal strength triangulation.

  Wi-Fi access point triangulation: A high resolution method for determining physical location is to triangulate the signal strength of neighboring WiFi access points with known physical locations. This method is particularly effective when determining the position of the device in the facility.

  Position displacement estimation: The exact position of the device may not be known, but the statistical probability of the position can be used as an approximation for purposes of evaluating the policy. This can be calculated by noting the change in the relative position of the device relative to the starting point at a known location; the user's device may have a known starting point in the past, In the meantime, it moves a known or estimated distance and orientation that makes it possible to calculate an approximate position. Possible methods for calculating the displacement from the starting point are measurements collected from an accelerometer (ie using an accelerometer to measure how much the user has walked based on gait measurements) , Changes in signal strength from a known fixed set of signal sources, and estimated distance traveled using other methods.

  FIG. 19 illustrates one embodiment of a method for implementing a location-aware authentication policy. The method may be performed within the context of the system architecture shown in FIGS. 17-18, but is not limited to any particular system architecture.

  At 1901, the location of the client is determined using one or more available technologies (eg, GPS, triangulation, peer / network device detection, etc.). At 1902, one or more location classes (and potential Boolean combinations of classes) are identified for the current location based on an existing set of policy rules. At 1903, one or more authentication techniques are identified according to the location class. For example, if the client device is currently in a known location so that it is within a defined range of the user's home or office or other trusted location, minimal authentication may be required (or no need at all). Not) On the other hand, if the client device is currently in an unknown location and / or an unreliable known location, stricter authentication (eg, biometric authentication such as fingerprint scanning, PIN entry, etc.) may be required. If an authentication technique is employed at 1904 and it is determined at 1905 that authentication is successful, then a transaction requiring authentication is permitted at 1906.

  As described above, the level of authentication required can be determined based on the current transaction. For example, transactions that require a significant amount of gold transfer may require a relatively high authentication guarantee threshold, whereas non-financial transactions require a relatively low authentication guarantee threshold. be able to. Therefore, the location-aware authentication techniques described herein may be sufficient for certain transactions, but may be combined with stricter authentication techniques for other transactions.

  If authentication is not successful, the transaction is blocked at 1907. At this stage, the transaction may be completely blocked or may require an additional authentication step. For example, if the user enters an incorrect PIN, the user can request to re-enter the PIN and / or perform biometric authentication.

  The embodiments of the invention described herein provide many advantages for an authentication system. For example, the described embodiments efficiently block access from unauthorized locations and limit the locations that a user is allowed to attempt authentication (eg, as defined by a location class). Can be used to reduce unauthorized access. Furthermore, embodiments of the present invention may selectively require strong authentication to address location-specific risks. For example, while retaining the ability to require strong authentication when a user / client is connected from an unknown or unpredictable location, a trusted party can authenticate when the user is entering a transaction from a known location. Inconvenience can be minimized. Furthermore, embodiments of the present invention allow location-aware access to information. Alternatively, location-centric policies may be used by trusted parties to provide users with additional access to location-specific information. By way of example and not limitation, a user located in Wal-Mart can use Amazon.com on his mobile phone. com. When you log into your account, Amazon. com may be granted access to special offers.

  As described above, the location of client device 1700 can be determined using a variety of different techniques. In one particular embodiment, the definition of “location” is not tied to a set of physical coordinates (as in GPS), but instead exists in the presence of a peer device or other type of network device It is prescribed by. For example, in operation, client wireless network adapters (eg, WiFi adapters, Bluetooth adapters, LTE adapters, etc.) are consistent with peer network devices (eg, other computers, mobile phones, tablets, etc.) and network infrastructure devices on a consistent basis. A set of (e.g., WiFi access points, cell towers, etc.) can be "watched". Hence, the presence of these devices can be used for authentication by the user during operation. Other locations can be defined by the presence of the device in the same way as when the user is at home.

  For example, using the techniques described herein, a location can be defined as “with work colleagues” or “at work” and is known to be owned by the user's work colleagues. The presence of a set of peer devices can be used as a proxy for risks that need to be mitigated by an authentication policy. For example, if a user is surrounded by a set of known peer devices or other types of network devices, the user can be considered less risky than if no known devices are detected.

  FIG. 20 illustrates one embodiment where “location” is defined by a set of peer devices and other network devices. In the illustrated example, client device 1700 includes two different peer devices 2005-2006 (eg, client computer, mobile phone, tablet, etc.); two different wireless access points 2010-2011; two different cell towers 2020-2021. "View". As used herein, client device 1700 can “see” without formally establishing a connection with each of the other devices. For example, the client can see various peer devices connected to the working LAN and / or can see the radio signals generated by those devices regardless of whether the client connects to them. . Similarly, the client device 1700 can see a basic service set identification (BSSID) for a variety of different WiFi access points (eg, WiFi from nearby hotels, coffee shops, working WiFi access points). Client device 1700 can also see a variety of different cell towers 2020-2021 operated by potentially different cell carriers. The presence of these devices can be used to define a position “fingerprint” for the user's operating position.

  As shown, device proximity detection logic 2001 at client device 1700 can capture data associated with a visible device and compare the results against past device proximity data 2004. Past device proximity data 2004 may be generated over time and / or by a training process. For example, in one embodiment, the user can be designated at home or at another location when he / she is at work (when requested to do so manually or by client 1700). In response, the device proximity detection logic 2001 can detect nearby devices and continuously store the results as past device proximity data 2004. When the user subsequently returns to position, the device proximity detection logic 2001 can compare the device to “see” the device currently stored as past proximity data 2004 to generate a correlation between the two. . In general, if the correlation is strong, there is a high possibility that the client is at a position designated by the client. Over time, devices that are seen on a regular basis (for example, because these devices tend to provide a more accurate correlation with the user's operating position) are compared to other devices in past device proximity data 2004. Can be prioritized up.

  In one embodiment, the authentication policy engine 1710 can use the correlation results provided by the device proximity detection logic 2001 to determine the level of authentication required by the user for each trusted party 1750. . For example, if there is a high correlation (ie, above a specified threshold), the authentication policy engine does not require explicit authentication by the end user. In contrast, if there is a low correlation between the user's current location and past device proximity data 2004 (ie, below a specified threshold), the authentication policy engine 1710 may require more strict authentication (eg, Biometric authentication such as fingerprint scanning and / or PIN input request) may be required.

  In one embodiment, device proximity detection logic 2001 identifies a set of other devices in the vicinity of the authenticated client. For example, if some of the user's colleagues have already been successfully authenticated, the user may be able to obtain predetermined data by an unreliable authenticator simply because the user is operating in the presence of his / her peer. There may be a low risk associated to allow access. In this embodiment, peer-to-peer communication over a standard such as 802.11n can be used to collect authentication tokens from peers that can be used to prove that these peers have already been authenticated. it can.

  In other embodiments, the device proximity detection logic 2001 can also detect a previously authenticated device paired with the user's client (eg, the user's mobile phone or tablet). The presence of other authentication devices used by the same user trying to authenticate can be used as an input for an authentication decision, especially when accessing the same application.

In one embodiment, past device proximity data 2004 can be collected and shared among multiple devices and stored and maintained in an intermediate authentication service. For example, the history of peer and network device groups at each location can be tracked and stored in a central database accessible to each device's device proximity detection logic 2001. This database can be used as input to determine the risk of authentication being attempted from a particular location.
E. Embodiments for location verification using supplemental sensors and / or location data

  As described above, one embodiment of the present invention utilizes data from the additional sensor 1743 from the mobile device to provide supplementary input for the risk calculation used for authentication. These supplementary inputs can provide an additional level of assurance that can help to confirm or refute end-user device location claims.

  As shown in FIG. 21, additional sensors 1743 that provide supplemental assurance of the position of the device can include a temperature sensor 2101, a humidity sensor 2102, and a pressure sensor 2103 (eg, barometric pressure or altimeter pressure sensor). In one embodiment, the sensor correlates to known supplemental data 2110 for the position provided by position sensor 1741 (or a position derived using various other techniques described herein). To do so, it provides temperature, humidity and pressure measurements used respectively by the supplemental data correlation module 2140 of the authentication policy engine 1710. The correlation results are then used by the authentication policy module 1711 to select one or more authentication techniques 1712 for a particular transaction. As shown in FIG. 21, supplemental location data 2110 can be stored during an external source (eg, the Internet or other mobile device) and a local data source (eg, during which the device is known to be owned by a legitimate user). (Collected history data) may be included.

  Supplemental data correlation module 2140 can use the data provided by additional sensor 1743 in a variety of different ways to correlate to supplemental position data 2110. For example, in one embodiment, supplemental location data 2110 includes current local weather conditions at the location provided by location sensor 1741. By comparing the humidity, temperature, or pressure collected from the additional sensor 1743 to the real-time local weather data 2110, the supplemental data correlation module 2140 identifies when the sensor data is inconsistent with local conditions. For example, the supplemental data correlation module 2140 may generate a low correlation score if the client device's GPS measurements are outside the device and further indicate that temperature, humidity, or barometric pressure does not match local weather conditions. Yes, the location can be considered less reliable. As a result, the authentication policy module 1711 may require stricter authentication techniques 1712 (eg, fingerprint, PIN entry, etc.) to approve the transaction.

  As another example, by comparing the altitude provided by the altimeter pressure sensor 2103 against a known geographical or network topology of the claimed location (comprising supplemental location data 2110), the supplemental data correlation module 2140 A discrepancy can be identified that informs that the claimed location is not genuine. For example, if a reverse IP search of the location claimed by the user identifies them as being in the Andes, but the altimeter data from the device indicates that the device is at sea level, the supplemental data correlation module 2140 A score can be generated and the position can be considered less reliable. As a result of the low correlation score, the authentication policy module 1711 may attempt to mitigate high risk with strong authentication for transactions.

  In one embodiment, the supplemental data correlation module 2140 may identify a plurality of other end users in the immediate area to identify anomalies that indicate that the user is not operating at the same physical location as their known users. Compare the data collected from sensor 1743 in the user's device. For example, if a set of authenticated users identifies a person operating the same physical area, all of those users' devices have a local temperature in the area of 10 ° C. and the supplemental data correlation module Note that 2140 can generate a low correlation for the end user whose temperature sensor 2101 indicates that the local temperature is 20 degrees Celsius. As a result, the authentication policy 1711 may require a stricter authentication technique 1712.

  As yet another example, the supplemental data correlation module 2140 can compare current measurements against a particular user's historical data. For example, as described above, sensor data can be analyzed during a period in which the user is known to own device 1700 (eg, following an explicit authentication). The supplemental data correlation module 2140 can then look for local data discontinuities to identify suspicious behavior. For example, if the user's ambient temperature is usually floating between 10 ° C and 20 ° C and it is currently 30 ° C, this can indicate that the user is not in a typical position, thereby producing a low correlation This causes the authentication policy module 1711 to request an additional level of transaction review.

  The supplemental data correlation module 2140 can perform a variety of different types of correlation between sensor data and supplemental position data while still adhering to the basic principles of the present invention. For example, various known correlation mechanisms can be used to determine the statistical relationship between two data sets. In one embodiment, the correlation score provided to the authentication policy engine 1711 includes a normalized value (eg, between 0 and 1) that indicates the level of correlation. In one embodiment, various threshold levels can be set for differences detected between sensor 1743 and supplemental position data 2110. For example, if the temperature sensor 2101 measures a temperature that is more than 3 degrees away from the current temperature (collected from other devices or the Internet), the first threshold can be triggered (resulting in a decreased correlation score). ). And each additional temperature that is 3 degrees off the current temperature can result in a new threshold being met (resulting in a corresponding decrease in correlation score). However, it should be noted that these are merely examples of one embodiment of the present invention, and the basic principles of the present invention are not limited to any particular method of performing correlation.

  A method according to one embodiment of the present invention is illustrated in FIG. At 2201, the current location reported by the client device (eg, via a GPS module at the device) is read. At 2202, supplemental location data is collected for the reported location along with sensor data from the client device. As described above, supplemental location data can be collected locally or remotely (eg, from other clients and / or servers on the Internet), and the current temperature, pressure and / or for the reported location. Or data such as humidity can be included. The sensor data can be provided by a temperature sensor, barometric or altimeter pressure sensor and / or humidity sensor.

  At 2203, correlation is performed between the supplemental position data provided by the sensor of the device and the sensor data. In one embodiment, a relatively high correlation results in a relatively high correlation score at 2204, while a low correlation results in a relatively low correlation score. As described above, in one embodiment, the correlation score is a normalized value (for example, between 0 and 1) indicating the similarity between the sensor reading and the supplemental data.

  At 2205, one or more authentication techniques are selected (at least in part) based on the correlation score. For example, if a relatively low correlation score is provided, a stricter authentication technique can be selected, whereas if a relatively high correlation exists, fewer strict authentication techniques can be selected. (Potentially not requiring explicit authentication by the end user).

  If the user successfully authenticates using the selected technique determined at 2206, the transaction is allowed to proceed at 2207. Otherwise, the transaction is blocked at 2208.

Many advantages are realized in the above embodiment. For example, these embodiments provide an additional level of assurance for location data collected from other sources. Allows organizations to supplement location data collected from other sources (IP, GPS, etc.) to obtain additional assurance that the location is authentic. In addition, embodiments of the present invention can block transactions from unauthorized locations and reduce unauthorized access by limiting the locations from which a user can attempt further authentication. In addition, these embodiments can enforce stronger authentication to respond to location-specific risks (e.g., where a user / client is accessing from an unknown or unpredictable location or its authenticity location). When a user is accessing information from a known location while retaining the ability to require stronger authentication when the user cannot fully qualify using multiple inputs Authentication inconvenience can be minimized).
F. Adaptive application of authentication policy based on client authentication function

  As shown in FIG. 23, one embodiment of the present invention is suitable for a particular class of interaction where an organization—for example, a trusted party with secure transaction service 1750 (hereinafter simply “trusted party”) — is suitable. It includes an adaptive authentication policy engine 2345 that allows to specify the type of authentication being performed. As shown, the adaptive authentication policy engine 2345 can be implemented as a module within the authentication engine 2311 that is executed at the trusted party 1750. In this embodiment, the adaptive authentication policy engine 2345 executes in response to a policy database 2325 that includes data about an existing authentication device 2329, an authentication device class 2328, an interaction class 2327, and an authentication rule 2326.

  In one embodiment, authentication device data 2329 includes data associated with each of the explicit user authentication devices 1720-1721 known to be used by client 1700. For example, the policy database 2325 may indicate that the sensor is sensitive data (eg, EAL 3 certificate in cryptographically secure hardware) and others acceptance rate (indicates how a trusted sensor generates a user authentication result). An entry for the “validation model 123” fingerprint sensor can be included along with technical details related to this sensor, such as how to store the.

  In one embodiment, the authentication device class 2328 specifies a logical group of authentication devices 2329 based on the capabilities of those devices. For example, a particular authenticator class 2328 may include (1) fingerprint sensors, (2) storing sensitive data in EAL 3 certified cryptographically secure hardware, and (3) 1000 minutes It can be defined to use a biometric matching process with an acceptance rate of 1 or less. Other device classes 2328 are (1) face recognition device, (2) do not store confidential data in cryptographically secure hardware, and (3) biometric verification based on the acceptance rate of others less than 1/2000 Processing can be used. Therefore, fingerprint sensor and face recognition implementations that meet the above criteria are added to the appropriate authentication device class 2328.

  Various personal attributes include the authentication device class such as the type of authentication factor (eg, fingerprint, PIN, face), the level of hardware security assurance, the secret storage location, and the location where encryption operations are performed by the authenticator (eg, , Within a secure chip or secure enclosure), and various other attributes. Another set of attributes that can be used relates to the location on the client where the “match” operation is being performed. For example, the fingerprint sensor can implement fingerprint template capture and storage in the fingerprint sensor's own secure storage device, perform all verification on those templates within the fingerprint sensor hardware itself, and create a highly secure environment. Bring. Alternatively, the fingerprint sensor can simply capture a fingerprint image, but it can be a peripheral that uses software on the main CPU to perform all capture, store and compare operations, resulting in a less secure environment. Absent. Various other attributes related to the implementation of “verification” can also be used to define the authenticator class (eg, verification is a secure element, trusted execution environment (TEE) or other secure Whether (or not) in the form of an execution environment).

  Of course, these are merely examples for explaining the concept of the authentication device class. Furthermore, various additional authentication device classes can be specified while adhering to the basic principle. Further, it should be noted that a single authenticator may be classified into multiple device classes, depending on how the authenticator class is defined.

  In one embodiment, the policy database 2325 is for new authentication devices 2329 as they enter the market with new authentication device classes 2328 that potentially include new classes that can classify new authentication devices 2329. Can be updated periodically to include data. Updates are by a trusted party and / or by a third party responsible for providing updates for the trusted party (eg, a third party selling a secure transaction server platform used by the trusted party) Can be done.

  In one embodiment, interaction class 2327 is defined based on a particular transaction provided by trusted party 2325. For example, if the trusted party is a financial institution, the interaction can be classified according to the monetary value of the transaction. A “high value interaction” can be defined as involving an amount of $ 5000 or more (eg, transfer, withdrawal, etc.); an “intermediate value interaction” involves an amount of $ 500 to $ 4999 A “low value transaction” can be defined as involving an amount of $ 499 or less.

  In addition to the amount involved, interaction classes may be defined based on the sensitivity of the data involved. For example, transactions that disclose a user's confidential or private data can be categorized as "confidential disclosure interactions", whereas those that do not disclose such data are defined as "non-confidential disclosure interactions" can do. Various other types of interactions can be defined using different variables and various minimum, maximum and intermediate levels.

  Finally, the set of authentication rules 2326 may be defined to include an authentication device 2329, an authentication device class 2327, and / or an interaction class 2327. By way of illustration and not limitation, specific authentication rules are detected by EAL 3 certified cryptographically secure hardware for “high value transactions” (as specified by interaction class 2327). Specifying that only a fingerprint sensor that stores data is available and that biometric verification processing with an acceptance rate of less than 1/1000 (as specified as authentication device class 2328) is available. it can. If the fingerprint device is not available, the authentication rule can define other allowed authentication parameters. For example, a user may need to enter a PIN or password and answer a series of personal questions (eg, provided by the user to a trusted party previously). Any of the above personal attributes specified in the authentication device and / or authentication device class depends on the type of authentication factor (eg, fingerprint, PIN, face), hardware security assurance level, secret storage location, authentication unit It can be used to define rules such as the location where encryption operations are performed.

  Alternatively or additionally, a rule may specify that a particular attribute can take any value as long as other values are sufficient. For example, a trusted party can specify that a fingerprint authenticator that stores its seed in hardware and performs the calculation in hardware must be used, but (for those authenticators that meet these parameters Don't care about the level of hardware assurance (as defined by the authenticator class 2328 containing the list).

  Further, in one embodiment, the rule may simply specify that a particular authenticator 2329 can be used to authenticate a particular type of interaction. For example, the organization may specify that only “a fingerprint sensor of the verification model 123” is acceptable.

  Further, a rule or set of rules can be used to create a combination of authentication policies for ordered and ranked interactions. For example, rules can specify a combination of policies for individual authentication policies, allowing the creation of rich policies that accurately reflect the authentication preferences of trusted parties. This allows, for example, a trusted party to specify that a fingerprint sensor is preferred, but if none is available, either trusted platform module (TPM) based authentication or face recognition Likewise preferred as the best option (eg in order of priority).

  In one embodiment, the adaptive authentication policy engine 2345 relies on the interaction class 2327, the authenticator class 2328, and / or the authenticator data 2329 in determining whether to allow a transaction with the client 1700. An authentication rule 2326 is implemented. For example, in response to a user of client device 1700 attempting to enter a transaction with a trusted party website or other online service 2346, adaptive authentication policy engine 2345 may apply one or more applicable interaction classes 2327 and A set of associated authentication rules 2326 can be identified. These rules can then be applied via communication with the adaptive authentication policy module 2350 in the client device 1700 (shown in FIG. 23 as a component within the client authentication engine 2310). The adaptive authentication policy module 2350 can then identify a set of one or more authentication techniques 2312 to comply with the specified authentication policy. For example, if a priority set of authentication techniques is specified by the trusted party's adaptive authentication policy engine 2345, the adaptive authentication policy module 2350 selects the highest priority authentication technique available at the client 1700. Can do.

  The result of the authentication technique 2312 is provided to a guarantee calculation module 2340 that generates a guarantee level that the current user is a legitimate user. In one embodiment, if the assurance level is high enough, the client communicates the results of a successful authentication to the trusted party's authentication engine 2311 that allows the transaction.

  In one embodiment, data from client device sensors 1741-1743 can also be used by guarantee calculation module 2340 to generate a guarantee level. For example, a position sensor (eg, a GPS device) can indicate the current location of the client device 1700. If the client device is in an expected location (eg, home or work), the warranty calculation module 2340 can use this information to increase the level of assurance. In contrast, if the client device 1700 is in an unexpected location (eg, a foreign country that the user has not visited before), the warranty calculation module 2340 can use this information to lower the warranty level. (Thus, stricter explicit user authentication is required to reach an acceptable level of assurance). As mentioned above, various additional sensor data such as temperature, humidity, accelerometer data, etc. can be incorporated into the assurance level calculation.

  The system shown in FIG. 23 can operate differently based on the specificity of the client authentication function and other information being communicated to a trusted party. For example, in one embodiment, the specific model of each of the explicit user authentication devices 1720-1721 and the specific details of the security hardware / software and sensors 1741-1743 on the client device 1700 can be obtained from the trusted party 1750. Can communicate. Thus, in this embodiment, the adaptive authentication policy engine 2345 can specifically identify the desired mode of authentication based on authentication rules implemented for the current transaction and the risks associated with the client. . For example, the adaptive authentication policy module 2345 may request authentication via a “validation model 123” fingerprint sensor installed on the client for a specified transaction.

  In other embodiments, the only general description of the authentication functionality of the client device 1700 may be provided to protect user privacy. For example, the client device has a fingerprint sensor that stores sensitive data in cryptographically secure hardware certified by EAL 3 and / or uses a biometric verification process that has an acceptance rate of less than 1 / N Can communicate. Without disclosing specific models of these devices, similar general information related to the functions and specifications of other authentication devices can be specified. The adaptive authentication policy engine 2345 can then use this general information to classify the authentication devices into the corresponding authentication device class 2338 in the database 2325. In response to a request to execute a transaction, adaptive authentication policy module 2345 instructs client device 1700 to use a particular authentication device if its class is sufficient to complete the transaction. Can do.

  In still other embodiments, the client device 1700 does not communicate any data related to the authentication function to the trusted party. Rather, in this embodiment, the adaptive authentication policy module 2345 communicates the required level of authentication, and the adaptive authentication policy module 2350 at the client selects one or more authentication techniques that meet the level of authentication. For example, the adaptive authentication policy module 2345 may use only one specific class of authenticator to indicate that the current transaction is classified as a “high value transaction” (specified by interaction class 2327). You may communicate. As mentioned above, it can also communicate authentication classes in a prioritized manner. Based on this information, the adaptive authentication policy module 2350 at the client can select one or more authentication techniques 2312 needed for the current transaction.

  As shown in FIG. 23, client device 1700 may include its own policy database 2390 to store / cache policy data for each trusted party. Policy database 2390 may include a subset of the data stored in trusted party policy database 2325. In one embodiment, the different sets of policy data are stored in the database 2390 for each trusted party (reflecting the different authentication policies of each trusted party). In these embodiments, a simple indication of a particular category of transactions (eg, “high value transaction”, “low”, because rules associated with various transaction types are available in the local policy database 2390). Value transaction ”, etc.) may be sufficient information for the adaptive authentication policy module 2350 at the client device 1700 to select the required authentication technique 2312. As such, the adaptive authentication policy module 2345 simply indicates the interaction class of the current transaction that the adaptive authentication policy module 2350 uses to identify the authentication technique 2312 based on the rules associated with that interaction class. Can do.

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

  At 2401, the client attempts to perform a transaction with a trusted party. By way of example and not limitation, a client can enter payment information for online purchases or attempt to transfer funds between bank accounts. At 2402, the transaction is classified. For example, as described above, a transaction may be associated with a particular interaction class based on variables such as the amount involved or the confidentiality of the information involved.

  At 2403, one or more rules associated with the transaction category are identified. Referring to the above example, if a transaction is classified as a “high value transaction”, a rule associated with this transaction type may be selected. At 2404, the rules associated with the transaction type are executed, and as described above, information is sent to the client indicating the authentication request to complete the transaction. As described above, this identifies a particular authenticator, identifies the class of authenticator, or simply indicates a particular rule that needs to be enforced (eg, if the client maintains a local copy of the rule) You may include that.

  In any case, at 2405, a set of one or more authentication techniques is selected based on the requirements specified via the rules and client authentication functions. If it is determined at 2406 that the authentication was successful, the transaction is permitted at 2407. Otherwise, the transaction is blocked at 2408 (or additional authentication is required from the user).

  There are many advantages realized from the embodiments of the invention described herein. For example, these embodiments can reduce the amount of work required to integrate the authentication function into a trusted party. For example, instead of writing code to organize the authentication policy, rules can be set via a simple graphical user interface. What all trusted parties need to do to consolidate the policy is to define a policy for the interaction class (eg: “Big Money Transfer”) and determine the correct authentication mechanism to use Having integration code that uses that policy identifier when interacting with the engine.

  In addition, these embodiments simplify the management of authentication policies. By expressing the authentication policy from the code, this approach allows an organization to easily update its authentication policy without requiring code changes. Changes to reflect new interpretations of regulatory delegation or to respond to attacks on existing authentication mechanisms can be simple changes in policy and can be made quickly.

Finally, these embodiments allow for future improvements in authentication technology. As new authentication devices become available, organizations can assess their relevance to address new or emerging risks. Integrating a newly available authentication device only requires adding an authentication device to the policy, and no new code needs to be written to quickly deploy new functionality.
G. System and method for eye tracking during authentication

  In general, authentication techniques are robust against impersonation when (a) secret information is used for authentication or (b) it is difficult to generate fake input. Most systems today rely on password-based authentication. Passwords need to be kept secure because they are easy to reproduce. Thus, password attacks typically focus on gaining access to a user's password. Recent attacks have demonstrated server vulnerabilities where passwords are stored for verification.

  In contrast to password-based authentication, when biometric authentication is used for authentication, the biometric authentication information is usually made public. For example, fingerprints can be obtained from (almost) all objects touched by the user. Similarly, a user's face is usually not hidden, so it can be seen and captured by someone, and is often published on social networks.

  In the real world, we can rely on our own cognitive ability when looking at a person because it is difficult to “generate” another person with the same biometric characteristics. For example, it is difficult to “generate” another person with the same face and beard. This is because the government includes face photos in passports, ID cards, driver's licenses and other documents. However, in the virtual world, we don't have to “generate” another person with the same face to impersonate the system, but only generate something that the computer recognizes, such as a facial image. . In other words, “Morality means that biometric authentication works well only if the verifier can confirm the following two things: First, biometric authentication comes from a person at the time of verification Second, biometrics match master biometrics on the file "(see reference 1 from the list of references provided before the claims of this specification).

  In the past, research on automatic face recognition has focused on recognition of face reliability using still images and videos. For example, see Reference 2 below. There are several relatively robust face recognition techniques, and the system is commercially available today (see reference 3). However, little attention is paid to “survivability” detection, ie, “Biometric authentication matches master biometric authentication on file... Verification”. In some use cases, impersonation protection is not required or is further performed by humans (eg, for law enforcement applications).

  The universality of cameras in computing devices such as notebooks and smartphones on the one hand and the weakness of passwords as the most common authentication method on the other hand generally promote the adoption of biometric authentication methods, particularly face recognition. The first large-scale “trial” of face recognition as an authentication method was performed in Google's Android 4 (aka “Ice Cream Sandwich”) and was based on still image recognition. These techniques can be easily fooled by photography (see reference 4). Even with an improved method involving some sort of viability detection in Android 4.1 (aka “Jelly Bean”), one has an open eye on the computer display relative to the camera and It can be easily fooled by presenting two photos in a sequence of electronically modified ones with closed eyes (see reference 5).

  It can be argued that this weakness is due to mobile device resource constraints, but it is also not very mature yet available commercial software, even in PC and anti-spoofing detection research It is shown that. The assignee of this patent application performed the test using PC-based face recognition software to confirm this finding.

  The compelling BioTrust 3.00.4063 that runs on the Windows 7 (R) -based Samsung Series 5 (R) notebook is a viable test even if the security setting is set to "High". Do not execute at all. A simple facial image displayed on a regular computer monitor was sufficient to successfully disguise the system.

  KeyLemon 2.6.5 running on the Macbook Air® performs a simple blink test as a viability check. It can be successfully impersonated by displaying a sequence of three images: (1) a real image of the face (eg created by a webcam); (2) as if the eyes were closed Change of the recolored real image; (3) Real image again.

  Anti-spoofing detection is not part of standard tests such as the NIST biometric vendor test when comparing different algorithms. For example, see references 6-8. One of the first known public competitions organized by several researchers in 2011 (see reference 9) showed the early success of several algorithms, which were 320 x 240 pixels Was based on video with resolution. A typical computing device provides a front-facing camera resolution of at least 640 × 480 pixels.

  FIG. 25 illustrates an exemplary client 2520 having a biometric authentication device 2500 for performing face recognition. When operating normally, the biometric sensor 2502 (eg, camera) reads the raw biometric data from the user (eg, snaps a picture of the user), and the feature extraction module 2503 specifies the raw biometric data. For example, focus on specific facial features. The query module 2504 compares the features extracted with the biometric template data 2510 stored in the secure storage device in the client 2520 and scores and based on the similarity between the extracted features and the biometric template data 2510. Generate a / or yes / no response. The biometric authentication template data 2510 is typically the result of a registration process in which a user registers a face image or other biometric information with the device 2500. The application 2505 can then use the score or the yes / no result to determine whether the authentication was successful.

  There are several potential points of attack to disguise the face recognition system, identified in FIG. 25 as (1)-(8) (see references 10, 11). Ensure the integrity of the biometric template (6) (eg, using an electronic signature) and apply a combination of (eg, (a) white box encryption method, (b) code obfuscation and (c) device binding There are well-known protection mechanisms to protect the integrity of the feature extractor (3), feature vector (4), query unit (5) and its final result (8).

  The protection mechanism against replaying old capture data for the feature extractor (2) is covered by a (at least theoretically) reliable computing group approach and by a potential extension to the ARM TrustZone. Basically, this approach adds an encryption protection mechanism (eg, HMAC or electronic signature) to the sensor and encapsulates the sensor in a tamper-proof manner similar to the protection mechanism used in current smart card chips. That is. The feature extraction engine can confirm the integrity of the input data.

The embodiments of the present invention described below utilize eye tracking techniques to confirm a user's “survivability”, but in one embodiment, these techniques detect fake biometrics. In combination with one or more existing technologies (see reference 1). This is an area of ongoing research. Existing studies have identified four different classes of protection approaches for fake biometrics (see reference 12):
1. Data-driven characterization a. Still image i. Decrease in resolution is detected by rescanning images that analyze the two-dimensional Fourier spectrum (Reference 13)
ii. Take advantage of the different reflection characteristics of the actual face to the image print. This theory is based on Lambertian reflection characteristics (Ref. 14).
iii. Use different micro-textures of actual face and image print due to print defects (reference 15)
iv. Use quality degradation and noise addition in images printed in combination with other methods (Reference 16)
b. Video v. Each camera sensor has its own characteristics, and recapture of the video displayed on the monitor causes artifacts. This can be used to detect impersonation (Ref. 12).
vi. In the case of impersonation by an image, there is face background dependency (Reference Document 17).
vii. In the case of a spoofing attack, the face usually shows more rigid body movement (Ref. 18).
c. Combination of still images and moving images (reference document 12)
2. User behavior modeling (12)
3. User interaction needs (Ref. 12).
4). Additional equipment (reference 12)

The most effective non-invasive mechanism based solely on existing sensor technology appears to be based on a combination of motion, texture and viability detection. See reference 9.
Texture difference

  The effect of printing and rescanning the image can be detected. It is intuitively clear that printing and rescanning does not improve image quality. The study in reference 15 shows that differences can be detected algorithmically by analyzing microtextures: “If you look closely at the difference between an actual face and a face print, the photo is considered to be a plane rigid body While humans' faces are complex non-rigid 3D objects, it becomes clear that human faces and prints reflect light in a variety of ways. "

This algorithm has been tested against images contained in the NUAA photo counterfeit database. The performance is reported to average 16.5 ms for processing images on a 2.4 GHz Intel Core 2 Duo CPU with 3 GB RAM using unoptimized C ++ code.
Infrared instead of visible light

It is difficult to display an image or video in the infrared spectrum. As a result, the survivability detection based on capturing the thermal pattern of the face proposed in Reference 19 is more robust than capturing the visible light pattern. Unfortunately, infrared sensors are expensive and are not included in typical notebooks, tablets or smartphones.
Optical flow based method

  An actual face is a three-dimensional object. The face is typically moving in a normal conversation. It is expected that the two-dimensional movement of the central face part, that is, the part having a short distance from the camera is higher than the two-dimensional movement of the face area having a long distance from the camera (reference documents 20, 21). 22). For this type of detection, a sequence of at least three consecutive images is required.

The work of reference 21 is part of the SART-2 project, a biometric security system for mobile workstations.
Moving image instead of still image

  Reference 23 describes a method for detecting blink-based viability. This method appears to be quite robust against simple photo-based spoofing attacks. In addition to recognizing the face, the method places the eye and tests whether it is visible in the observed image sequence when the eye is closed. As can be seen from the large scale testing of Android 4.1, this method is clearly not very robust against "Photoshop" attacks. See reference 5.

  In general, in order to impersonate such a video-based system, an attacker must generate a small image sequence and present the sequence to the sensor. In a world with powerful image editors, free video editors and tablet PCs, this is achieved relatively easily.

  Such a method is characterized as “known interaction”. That is, the attacker knows the necessary interaction in advance and can prepare the query image sequence.

In reference 23, the context of the scene and blink of eyes is included in the analysis. The performance measured in Intel Core2 Duo 2.8 GHz, 2 GB RAM is approximately 50 ms (20 FPS) per video frame.
Challenge response method

In the context of biometric authentication, the challenge response is defined as follows:
This method is used to confirm the presence of a person by eliciting a response directly from the individual. The response can be spontaneous or involuntary. In a spontaneous response, the end user reacts consciously to what the system presents. In an involuntary response, the end user's body automatically responds to the stimulus. The challenge response can be used to protect the system from attacks.
(National Science & Technology Council's Subcommittee on Biometrics)
Multimodal system

  In order to improve the robustness of biometric authentication methods against spoofing attacks, noisy data, etc., multimodal systems have been proposed. See reference 25.

  The effect of a simulated spoofing attack on such a multimodal system is analyzed in reference 26. The main result is that not all fusion schemes improve the robustness against spoofing attacks, and in some fusion schemes, only a single biometric authentication method is impersonated to impersonate the entire multimodal system Means enough. Analysis of existing schemes with actual spoofing attacks yields similar results. See reference 27.

In general, there are three different classes of multimodal systems.
1) A system that successfully impersonates a single trait is sufficient to impersonate the entire system. Optimization of multimodal systems for small FRRs usually results in such a result.
2) The following system:
a) Multiple traits must be impersonated to successfully impersonate the entire system; and
b) Impersonating any one trait in this multimodal system is less complicated than impersonating the same trait in a single modal system.
3) The following system:
a) Multiple traits must be impersonated to successfully impersonate the entire system; and
b) Impersonating any trait in this multimodal system is more complicated than impersonating the same trait in a single modal system. The embodiments of the invention described below fall into this category.

  One embodiment of the present invention performs eye tracking as part of the authentication process to measure the response to changing the region of interest that is randomly placed and displayed on the screen. For example, random screen layout mixed text, empty areas, sequences of images and video clips can be presented to the user to induce non-invasive eye movements. At the same time, eye tracking techniques are used to confirm that the eye is responding to the screen layout in the expected manner. This information can then be combined with face recognition techniques to confirm that the expected face is still present. In addition, as noted above, eye tracking and face recognition techniques can be applied to other techniques (eg, location-based authentication, non-invasive type) to reach a level sufficient to ensure that a legitimate user owns the device. User presence detection, fingerprint scanning, etc.).

  Reading web pages and other content types is accompanied by a smooth sweep of the eye along the content, but without a series of short pauses (referred to as “staring”) and quick “impulses”. The result of a series of stares and impulses is referred to as a “scanpath”. The scan campus is useful for analyzing cognitive intentions, interests and characteristics (see the current Wikipedia article en.wikipedia.org/wiki/Eye_tracking on “eye tracking”). A “heat map” is a summary display that shows the areas of a group of people stared at when viewing a web page or email (Hartzell, “Crazy Egg Heat Map is where people click on your website). (Crazy Egg Heatmap Shows Where People Click on Your Website) "(November 30, 2012), currently www.michaerthartzell.com/Blog/bid/92970/Crazy-Egg-Heatmap-shows-where-people-click- on-your-website).

  As illustrated in FIG. 26, one embodiment of the present invention includes a face recognition module 2604 for performing the face recognition described herein and an eye tracking module 2605 for performing eye tracking operations. An authentication engine 2610 in the client device 2600 is provided. In one embodiment, face recognition module 2604 and eye tracking module 2605 analyze the sequence of video images 2603 captured by camera 2602 on the device performing the respective operations.

  To perform the face recognition operation, the face recognition module 2604 relies on the face recognition template stored in the secure face recognition database 2646. In particular, as described above, the query logic in the face recognition module 2604 compares the face template data stored in the face recognition database 2646 with the face features extracted from the video image 2603, and the extracted features and face template data. A “score” is generated based on the similarity to As described above, the face template data stored in the database 2646 can be generated by a registration process in which a user registers a face image or other biometric data in the device 2600. The score generated by the face recognition module 2604 can then be used to form an assurance level 2606 that represents an assurance that the legitimate user has begun the current transaction (eg, an eye tracking module 2605 described below, etc. Can be combined with scores from other authentication modules. In one embodiment, each score must reach a certain threshold in order to generate a sufficient level of assurance 2606 for the particular transaction. In one embodiment (assuming that a threshold has been reached), the scores can be added or combined together using other mathematical formulas (eg, scores can be weighted, averaged, added together or any other Can be combined in any way).

  To perform eye tracking analysis, eye tracking module 2605 relies on eye tracking templates stored in secure eye tracking database 2645. Although illustrated as separate databases, the eye tracking database and the face recognition database may actually be the same secure database. In one embodiment, the eye tracking template is a text, graphics, photo, video, and / or blank area that will be displayed to the user on the client device display 2601 (some examples of which are described below). As well as the order in which content is potentially displayed. In addition, the eye tracking template includes data that identifies the expected operating characteristics of the user's eyes according to the content displayed to the user (eg, in the form of a heat map, see below). The query logic in the eye tracking module 2605 predicts the actual motion (captured from the video image) and the user's eye to reach a “score” based on the similarity between the expected motion and the actual motion. Compare exercises to be performed. As described above, the score can then be combined with scores from other authentication modules (eg, face recognition module 2604) to form assurance levels 2606. The eye tracking template data stored in database 2646 uses recorded eye movements of other users and / or actual users of the device in response to the displayed web page or other displayed image, respectively. And can be compiled. For example, similar to a face recognition template, an eye tracking template can be generated as part of a registration process in which a user registers his / her eye movements on the device 2600.

  In one embodiment, the eye tracking module 2605 determines a correlation between the displayed image (which may include text, graphics, video, images, and / or blank areas) and the user's eye movements. For example, if a video is displayed in the lower right corner of the display, the majority of users will focus on this area. Therefore, if the eye tracking module 2605 detects that the user's eyes have moved to this area within a specified period (eg, 2 seconds), it detects a high correlation between the user's eyes and the template, Yields a relatively high score. In contrast, if the user's eye does not move to this region (or does not move at all), eye tracking module 2605 detects a low score corresponding to a low correlation.

  As shown in FIG. 26, various other explicit user authentication devices 2620-2621 and sensors 2643 can be configured on the client device 2600. These authentication devices and sensors may provide additional (if necessary) used by authentication engine 2610 when generating assurance level 2606 (ie, in addition to eye tracking and face recognition described herein). Authentication data can be provided. For example, the sensor can include a position sensor (eg, GPS) to determine the position of the client device 2600. If the client device is in the expected position, the authentication engine can use this data to increase the assurance level 2606. In contrast, if the client device is in an abnormal position (eg, another country), this can negatively affect the assurance level 2606. In this way, authentication data can be generated non-invasively (ie, using sensor data collected without explicit input from the end user).

  In addition, other non-invasive techniques include an authentication engine 2610 that monitors the time elapsed since the last explicit user authentication. For example, if the user has been authenticated using a fingerprint or other biometric device 2620-2621 or has recently entered a password (eg, within 10 minutes), it uses this information to increase the assurance level 2606. To do. In contrast, if the user has not been explicitly authenticated for several days, it can require stricter authentication by the face recognition module 2605 and eye tracking module 2605 (eg, Higher correlation with template data than usual to increase to an acceptable value for a given transaction).

  In one embodiment, secure storage device 2625 is associated with each of the authenticators and secure communication module 2613 to establish secure communication with a trusted party (eg, cloud service 2650 or other type of network service). A secure storage device that stores an authentication key provided for use by the device.

  An exemplary “heat map” generated for a web page is shown in FIG. The color code represents an area of the web page where the user's eyes are fixed while looking at the user. Red indicates the maximum fixed amount (meaning that the user tended to see these areas more often), yellow (indicating less fixation), blue (indicating less fixation), and (fixed) Colorless followed (none or fixed below threshold).

  In designing web pages, eye tracking and heat map analysis are performed as part of usability analysis. Studies (see, for example, references 29 and 30) have shown that web users spend 80% of their time looking at information on page folds. Users do not scroll, but they allocate only 20% of attention below the crease. Web users spend 69% of the time looking at the left half of the page and 30% looking at the right half. Therefore, the traditional layout makes the site more likely to be useful.

  A spoofing attack that presents a still image or video displayed on a monitor can be detected by the eye tracking module 205 as a scan path that would probably not correlate with the screen layout. Various types of eye tracking methods are available: software based on methods using high precision specialized devices and standard webcams (see reference 33).

  FIG. 28A illustrates an exemplary grouping of text 2805 and images and / or video 2801 displayed on the display 2601 of the client device. In one embodiment, the grouping is integrated into the web page. However, the basic principles of the present invention are not limited to web-based organizations. Grouping can also be part of a screen saver or other application. In one embodiment, text 2805 and image / video 2801 are displayed simultaneously. In other embodiments, the text is displayed first, followed by an image / video 2801. In either case, the expectation is that the user's eyes are directed to the lower right of the display 2601 (where the image / video 2801 is displayed).

  FIG. 28B illustrates another example that includes a text region 2805 and three image / video elements 2800-2802. In one embodiment, the image / video element 2800 is displayed first, followed by the image / video element 2801, followed by the image / video element 2802. In such a case, the user's eyes need to move from the upper right corner of the display to the lower right and then to the lower left.

  In one embodiment, specific image / video elements 2800-2802 and other content types are randomly selected by eye tracking module 2605, thereby making authentication and spoofing difficult. Further, different image / video elements 2800-2802 are randomly selected for a particular location. In such a case, the eye movement template can specify a specific mode of operation for displaying the content, but does not specify the actual content at the actual location. Selected by the eye tracking module 2605 that assumes that the user's eyes must be drawn toward the displayed content, and generates correlations and scores based on the degree to which this is detected.

  Further, rather than generating unique content, the eye tracking module 2605 can use existing content such as images stored locally on the existing web page or device of the trusted party 2650. For example, if the trusted party is a financial institution and the user is about to enter a financial transaction, a web page that is normally displayed during the transaction can be displayed. In such a case, the eye tracking module 2605 retrieves the heat map of the web page (as shown in FIG. 27) from the eye tracking database 2645 and does a correlation exist for the heat map and the location seen by the end user. Whether it can be determined.

  In summary, the embodiments described herein present a sequence of random screen layouts that mix text, free space, images and video clips, and continually keep the user's eyes generating a captured scan path. Can be tracked. A correlation is then performed between the captured scan path and the expected scan path. Furthermore, one embodiment of the present invention can then reconfirm that the face is further recognized.

  Not all people are equally attracted to the same image or image sequence. For example, some people are attracted to more techniques than animals, text, known or unknown human faces and bodies, mysterious symbols or mathematical formulas. With this in mind, one embodiment of the eye tracking module 2605 allows a person to learn the unique characteristics of eye movements induced by different types of images. The similarity of the characteristics measured from the video image 2603 and reference data (stored in the eye tracking database 2645) is then used to generate the assurance level 2606 (ie, the legitimate user's eyes are “challenge”). Certainty following images, video and other content displayed on display 2601).

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

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

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

  Although shown in FIG. 29 as parallel processing 2903/2905 and 2904/2906, a face recognition operation 2903/2905 may be performed first, after which the face recognition operation resulted in a high correlation / assurance level ( Alternatively, the eye tracking operation 2904/2906 may be performed.

At 2907, a determination is made as to whether the combined result of face recognition and eye tracking is sufficient to allow the current transaction to proceed. If so, the transaction is authorized at 2909. Otherwise, at 2908, the transaction is not permitted or additional authentication techniques are required to raise the level of assurance. For example, at this stage, the user can be asked to swipe their finger over the fingerprint sensor or enter the PIN associated with the user's account. If it is determined at 2910 that additional authentication techniques are sufficient, the transaction is allowed at 2909.
H. System and method for collecting and using client data for risk assessment during authentication

  Some types of authenticators are very reliable, others are not. Therefore, the assurance that a trusted party can have a particular type of authentication unit reading and client data that can be used for risk assessment (eg, to adjust its assurance up and down) There is a range. For example, if the remote authenticator has a secure element or a trusted execution environment (TEE), the authentication can be securely signed with a certification key. The certification key is inside the secure element and cannot be accessed by any external entity. The actual authentication operation is performed within the secure element. Using the certification key signature, the trusted party can reliably know that the remote authenticator is responsible for the authentication attempt.

  If the remote authenticator lacks a secure element, the certification signature must be done with software that opens the door for attack. One way to mitigate this is to store a software-protected “white box” certification key. The certification key cannot go out of the white box and cannot be signed in an authentication attempt. However, this uses a secure element or a trusted execution environment (TEE) because the authenticating code and the white box performing the certification signature are disconnected (and the white box is software based). More reliable than you do.

  Finally, lacking all of the above, the entire authentication operation can be performed entirely by software. This is the least secure because both the authentication code and the certification key itself can be compromised.

  In any of the above examples, to determine the specific method by which authentication is performed so that client risk can be evaluated at the time of authentication execution (eg, when generating a guarantee level as described below) It would be beneficial if a trusted party could collect client data.

  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 level of risk associated with the client can be used to specify the authentication technique that must be used to authenticate the user for a particular transaction. In order to assess risk, one embodiment of the present invention includes (1) a type of data useful for risk calculation, (2) a method for obtaining additional data that a web browser cannot provide securely, and ( 3) Determine how to do it in a way that does not infringe on user privacy.

  One of the biggest reasons viruses, worms and malware infect computers are because the operating system has not been updated recently to close potential vulnerabilities. These vulnerabilities in the operating system are very easy to be exploited by criminals once known to the public. The longer a system goes unupdated, the more likely it exists to exploit potential vulnerabilities and the greater the risk that a password may be compromised by malicious code. Web browsers do not allow a website to access the user's computer update history. If they do, the website can identify potential victims based on vulnerabilities known to be on the system. Accordingly, one embodiment of the present invention is implemented as a native application that collects client data and / or recently operating system updated methods to determine the current operating system version (rather than a browser plug-in). It operates as a secure agent.

  One defense against malicious code is anti-virus software (eg, Windows® Defender®) after it infects a user's computer. Despite malicious code already invading the system, antivirus software warns the user that at least something bad has happened and thereby limits the final damage done. The user can change the account password and verify recent transactions. However, if no anti-virus software is installed or if anti-virus software is installed but has not been run recently, the user is not aware that malicious code is present on the computer There is a high possibility. Transactions that occur on that computer will be at high risk of fraud. Web browsers do not reveal whether antivirus software is installed on the computer. Therefore, in one embodiment, the native agent application can configure the client settings to determine whether anti-virus software is installed, and if so, how it has been updated and / or recently executed. Arrange and collect data.

  Another defense, especially against worms, is a firewall. If a software firewall is installed and enabled on the user's device, the number of attack entry points is greatly reduced. An open port that serves any request that normally comes via wire from a random Internet host is castrated. Therefore, even if the service listening to the port has an unpatched security hole, the risk is eliminated because communications are not allowed to access it. On the other hand, a computer running without a software firewall has a much greater chance of being infected with a worm, especially if it has not been updated recently. Web browsers can indirectly detect the firewall with limited success via port scanning. Thus, in one embodiment, the native agent application deploys and collects firewall configuration data to determine whether a firewall is installed and, if so, how it was recently updated. .

  If a user's computer is physically stolen, a significant amount of information can be collected by criminals and used to commit fraud. If the user's device is protected with a password and preferably the entire hard drive is encrypted with that password, the risk of information leaked due to theft is reduced. Otherwise, a higher level of risk can be assessed. Therefore, in one embodiment, the native agent application determines whether the hard drive contents have been encrypted and uses this information as part of the client's risk assessment.

  Further, as described above, if the client is using a secure element or a trusted execution environment (TEE) to perform authentication, the trusted party is said that the authentication provided by the client is legitimate. You can have a high security. If the remote authenticator lacks a secure element, the software protection “white box” can be used to protect the certification data (eg, certification key). However, as described above, since the authenticating code and the white box performing the certification signature are separated (and the white box is software based), this is a secure element or a reliable execution environment. More reliable than using (TEE). Finally, lacking all of the above, the entire authentication operation (not the most secure method as described above) can be done entirely in software. One embodiment of the present invention collects the client data by a trusted party to determine the particular method in which authentication is taking place so that the client's risk can be assessed when performing the authentication. It is possible to do.

  As shown in FIG. 30, in one embodiment of the present invention, the client device 3000, the client risk assessment agent 3004, in one embodiment, collects various types of client configuration data 3050 in response. A client risk assessment agent 3004 that calculates the risk level of the client 3000 is included. 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. Thus, the client risk assessment agent 3004 is not subject to restrictions related to browser plug-ins or other types of program code that have limited ability to access client data for security reasons. In other words, the client risk assessment agent 3004 is authorized to collect data that is not allowed to be accessed by HTML and Javascript code running in the browser context. Therefore, even though the authentication engine 3010 can be implemented within the browser context, it has access to the additional risk analysis provided by the client risk assessment agent 3004 (the authentication engine 3010 further includes Note that it does not have to be implemented in the browser context while adhering to the basic principles).

  In one embodiment, the authentication engine 3010 includes an assurance level calculation module 3006 for calculating an assurance level corresponding to the likelihood that a legitimate user owns the client device 3000. This assurance level is then used to determine whether a pending transaction (eg, financial transaction, online purchase, access to sensitive information in a user's account, etc.) with a remote trusted party 3051 over the network has been completed. Can be used. In one embodiment, the trusted party 3051 can specify the level of assurance required for a given transaction. For example, for a financial transaction involving a significant amount of transfer, the trusted party 3051 may require a higher level of assurance than, for example, a transaction involving access to a user's email account. Although illustrated as a single entity, a “trusted party” includes a website or other online service with an independent secure transaction server for performing the basic authentication techniques described herein. be able to.

  In one embodiment, the assurance level calculation module 3006 is designated to the trusted party 3051 (eg, as a value, ratio, code, etc.) without disclosing the user sensitive information collected by the client risk assessment agent 3004. Send a guarantee level), thereby protecting the user's privacy. In other embodiments, the assurance level calculation module 3006 knows the assurance level required for the current transaction, determines whether the assurance level is high enough, and again relies on the trusted party 3051 for the user's personal information. Without disclosing, an indication is sent to the trusted party 3051 as to whether the transaction is allowed or denied.

  In one embodiment, communication between the client device 3000 and the trusted party 3051 uses the first key to encrypt outgoing communication and uses the second key to decrypt incoming communication. Can be secured via a secure communication module 3013. In the symmetric key encryption method, the first and second keys are the same. In the asymmetric key encryption method, the keys are different. However, the basic principles of the present invention are not limited to any particular type of encryption.

  In one embodiment, the assurance level calculation module 3006 determines the assurance level based on the current user authentication result 3005 in addition to the risk data provided by the client risk assessment agent 3004. In particular, the user authentication result 3005 can include a current or recent explicit user authentication result via one or more explicit user authentication devices 3020-3021. This includes, for example, fingerprint authentication via a fingerprint authentication device, face recognition authentication via camera and face recognition hardware / software, voice recognition via microphone and voice recognition hardware / software, camera and related hardware / It can include retinal scans using software, password / PIN entry by the end user via the keypad, and / or various other types of explicit user authentication devices and / or techniques.

  In one embodiment, secure storage device 3025 cryptographically protects biometric criteria data records for each user authentication device 3020-3021 (eg, using a symmetric key to secure storage device 3025). Data wrapping). Although the secure storage device 3025 is illustrated outside the secure perimeter of the authentication devices 3020-3021, in one embodiment, each authentication device 3020-3021 cryptographically protects biometric reference data records. May have their own integrated secure storage device.

  In addition to explicit user authentication, one embodiment of authentication engine 3010 collects data from sensor 3043 for use by warranty calculation module 3006 to generate a level of assurance. Illustratively, the sensor 3043 can include a position sensor, such as a GPS sensor, to indicate the current location of the user. If the client device 3000 is in an expected location such as the user's work or home, this increases the likelihood that the user is a legitimate user. In contrast, if the user is in an expected location, such as a foreign country that has not been visited before, this increases the likelihood that the user is not a legitimate user. Therefore, in one embodiment, the guarantee calculation module 3006 tends to increase the guarantee level when the user is in the expected position and decrease the guarantee level when the user is in the unexpected position.

  Various additional sensors 3043 such as temperature sensors, humidity sensors and accelerometers can be used to collect data related to user authentication. For example, the temperature / humidity sensor can provide a current temperature / humidity that can be compared to a known temperature / humidity for a location specified by the position sensor. If the values are significantly different, this can indicate that the client device 3000 is impersonated. The asserted location and temperature / humidity comparison may be performed at a remote server, such as secure transaction server 4632 described below with respect to FIGS. In other embodiments, an accelerometer in the device can be used to measure the user's gait and compare these measurements against the user's known gait. If the gait matches (within the specified threshold), this increases the likelihood that a legitimate user owns the client device 3000.

  As shown in FIG. 31, various client setting data related to risk determination can be collected and used including, for example, hardware data 3101, operating system data 3102, and application data 3103. By way of example and not limitation, the hardware data 3101 can include a client device model, a processor name / type, a boot ROM version, and a management controller version. The operating system data 3102 can include the current operating system version, the date the OS was updated, and the current boot mode (eg, booting from a hard drive). Application data 3103 includes instructions on whether the firewall is active, the type and version of the firewall, instructions on whether antivirus software is installed with updates to the current version and virus definitions file, and antivirus software is active (Eg, actively monitoring the client device at runtime), an indication of the last complete and / or partial virus scan, and the results of a recent virus scan. Further, the application data 3103 or OS data 3102 includes an indication as to whether the data is stored on the user's persistent storage device (eg, hard drive, flash memory, etc.) in an encrypted or secure manner. be able to.

  As described above, in one embodiment, the assurance level calculation module 3006 provides risk assessment data and user provided by the client risk assessment agent 3004 to reach the assurance level that the legitimate user is attempting the current transaction. Both authentication results 3005 are disassembled. 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 is more than a client that has these characteristics enabled. It can be reported to the guarantee calculation module 3006 that it represents a high risk. Similarly, if the virus detection software has not been updated or executed recently (eg, within a threshold time), the client risk assessment agent 3004 can report an increased risk to the assurance level calculation module 3006. The risk level can be specified in various ways while still adhering to the basic principles of the present invention. For example, the risk level can be a ratio (eg, 0% = minimum risk, 100% = maximum risk, and all intermediate numbers representing different levels of intermediate risk) or a numerical value on a scale (eg, 1 = minimum risk, 10 = maximum risk and all intermediate numbers representing different levels of intermediate risk).

  Regardless of how risk data is provided, in one embodiment, assurance level calculation module 3006 determines the level of authentication required based on the risk data provided by client risk assessment agent 3004. For example, if the client risk rating indicates a relatively high risk value (eg, 9 or 10 out of 10), the assurance level calculation module 3006 may enter a PIN / password and authenticate the user for the current transaction. More reliable and / or explicit user authentication such as fingerprint scanning may be required. In contrast, if the client risk assessment indicates a relatively low risk (eg, 1 or 2 out of 10), the assurance level calculation module 3006 may determine whether the location-based authentication and / or current transaction Non-invasive user authentication, such as reliance on explicit user authentication, can be required.

  Note that the data in FIG. 31 is arranged in tabular form for simplicity. The actual client configuration data 150 can be stored in a variety of different formats including, for example, binary files, hierarchical file system structures, linked lists, and OS registry formats. The basic principle of the present invention is not limited to any specific setting data format.

  As shown in FIG. 30, in one embodiment, the client risk assessment agent 3004 is via the OS (eg, by making an appropriate call to an application programming interface (API) exposed by the OS). Access to customer setting data 3050 is provided. In other embodiments, the client risk assessment agent 3004 accesses the client configuration data 3050 directly from the basic file system in which the data is stored. In one embodiment, the client risk assessment agent 3004 comprises secure access to preference data. Various security functions may be implemented to ensure the security of the configuration data 3050 such as the trusted technology chain and the secure enclave.

  One consideration that allows additional risk information to be provided to the website is that rationality is not ignored for reasons why the browser does not provide this information in the first place. . Certainly, malicious websites can make full use of this information, and web browser developers have good reasons to leave this information out of reach. Therefore, as described above, in one embodiment, basic client configuration data 3050 is not provided directly to trusted party 3051. Rather, in one embodiment, client risk data is assessed directly on the client device by a client risk assessment agent 3004, and the risk value is provided to the assurance level calculation. All trusted parties 3051 need to know whether the authentication was successful and / or the current level of assurance (if the level of assurance was specified in advance). In this way, the client setting data 3050 is protected from the present disclosure.

  One embodiment of a method for assessing client risk during authentication is shown in FIG. The method can be implemented on the architecture shown in FIGS. 30-31, but is not limited to any particular system architecture.

  At 3201, client configuration data related to client risk is obtained. This can include, for example, the presence and current status of firewall or virus detection software and / or the current version of the operating system (eg, the OS has been recently updated). At 3202, client configuration data is evaluated to determine a client's risk value (eg, a ratio, number, or other data that can identify a risk level). At 3203, the client risk assessment is used to determine the assurance level. In one embodiment, a high risk value requires a higher assurance level (eg, a risk value of 10 may require a 90% or higher assurance level). In other embodiments, the assurance level itself is calculated based on the assessed risk. For example, as described above, the risk value can be included as one of many variables to determine the current level of assurance (including previous or current user authentication).

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

At 3205, a determination is made as to whether authentication was successful. If so, the transaction is allowed at 3208. Otherwise, at 3206, one or more additional authentication techniques can be required or the transaction can be authorized. For example, if the current level of assurance is insufficient, the user may require the trusted party 3051 to enter previously provided confidential information or other / additional authentication. May be provided. If the additional authentication technique is determined to be sufficient at 3207, the transaction is permitted at 3208. Otherwise, the transaction is prohibited at 3206.
I. System and method for authenticating local transactions

  The embodiments of the invention described herein include techniques for authenticating a user to initiate a local transaction via a local secure transaction device. By way of example, a local transaction can be a withdrawal, transfer, or other user initiated operation, and a secure transaction device can be an ATM or other local device that can execute a financial transaction. Similarly, a local transaction can include completing payment to purchase goods or services at a retail store or other retail location with a local secure transaction device.

  As shown in FIG. 33, in one embodiment, a client device 3300 having a biometric authentication device and associated software can be trusted by a secure transaction service 3351 to perform a transaction on a local secure transaction device 3350. Authenticate over the network. In particular, if the user of client device 3300 wishes to perform a transaction locally using secure transaction device 3350, it initiates a series of authentication transactions with trusted party 3351, examples of which are described below. ) For example, the user may be required to swipe their finger over the fingerprint sensor at the client device 3300 and / or enter a PIN or other secret code via the client's keypad. The authentication result is then sent from the client device 3300 to the trusted party 3351 without sending the user's private data (eg, fingerprint data, PIN, or any other private user data). To protect user privacy.

  In response to a successful authentication, trusted party 3351 can send a signal to local secure transaction device 3350 to perform the operation. For example, if the local secure transaction device is an ATM, the signal can instruct the ATM to dispense a specified cash amount. If the local secure transaction device 3350 is a retail checkout device, an indication of successful payment can be sent and the user's account can be withdrawn.

  Further, as shown in FIG. 33, a local secure communication channel can be established between the client device 3300 and the local secure transaction device 3350 to supplement the user authentication process. The local secure channel may be on client device 3300 and local secure transaction device 3350 using various wireless communication technologies such as near field communication (NFC), Bluetooth or WiFi (eg, 802.11x channel), for example. Can be established using a wireless communication interface. For example, when in the vicinity of the location secure transaction device 3350, the client device 3300 may use a near field communication (NFC) hand over a wireless interface with the wireless interface of the local secure transaction device 3350 to exchange data during authentication. A shake can be performed to establish a local secure channel.

  Since establishing the current location of the client device 3300, the mere presence of the local secure channel includes authentication data. This information can therefore be used by the trusted party 3351 as proof of the current location of the client device 3300 during the authentication process. In one embodiment, the trusted party 3351 provided by the local secure transaction device 3350 using the current GPS location reported by the client device 3300 to confirm that the two location values match. The positions to be compared can be compared.

  Further, the trusted party 3351 can send a secret code or other authentication data to the client device 3300, and the client device 3300 can connect locally via a secure local channel to authenticate the client device. It can be relayed to the secure transaction device 3350. For example, in one embodiment, trusted party 3351 sends a barcode to client device 3300 and a corresponding code to the local secure transaction device. The local secure transaction device 3350 can then read the barcode (eg, from the display of the client device 3300) using a barcode scanner or camera to perform authentication (ie, the code read from the barcode). And the code received from a trusted party). Alternatively, the local secure transaction device 3350 can send the code read from the bar code to a trusted party that subsequently verifies that the code matches. Conversely, the trusted party 3351 can send a secret code or other authentication data to the local secure transaction device 3350 that subsequently relays the data to the client device 3300 for authentication. Therefore, the local secure channel can be used to exchange data for various authentication technologies.

  As described above, in one specific embodiment, the local secure transaction device 3350 is an ATM device. ATM devices are vulnerable because their input / output controls (eg, card reader, keyboard, screen, camera, etc.) are exposed for the “outside” and are readily available for tampering. Device. For example, debit card records and pins can be easily stolen by low-tech devices such as hidden magnetic stripe readers, mirrors and video cameras. In one embodiment, remote authentication technology with communication between client 3300 and trusted party 3351 is used to provide significantly improved authentication for ATM devices. When integrated with this remote authentication, the ATM itself does not need to have legacy input / output controls such as a card reader, touch screen or keyboard. All it needs is a slot for distributing network connections and cash. The authentication itself can be performed on the customer's client device 3300 with a biometric authentication device.

  In one embodiment, for cash withdrawal, the user enters the perimeter of the ATM device to authenticate to the trusted party 3351 and initiates a remote authentication application. The user then enters an amount for the withdrawal and swipes his finger (or any other type of user authentication as described below) using a fingerprint sensor on the mobile device. If the user's presence and authentication is confirmed by the trusted party 3351, the specified amount is dispensed from the ATM slot.

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

  Additional architectural details of one embodiment of the present invention are shown in FIG. As shown, the client device 3300 of this embodiment is a local authentication application that communicates with both the local secure transaction device 3350 and the trusted party 3351 to coordinate the various local authentication techniques described herein. 3304 is included. In one embodiment, the local authentication application 3304 establishes a local secure channel with the local secure transaction device 3350 and the authentication engine 3310 can be trusted to verify that the legitimate user owns the client device 3300. Perform remote authentication by the party.

  In one embodiment, the authentication engine 3310 performs authentication by entering a series of transactions with a trusted party's secure transaction server as described in the above-mentioned co-pending patent application. For example, these transactions can include a registration process in which a user registers with a client biometric device to generate biometric template data (eg, by finger swiping, image snapping, voice recording, etc.). Registration can be under the direction of a trusted party's secure transaction server or can be done autonomously by the user. The user can then register the biometric authentication device on the secure transaction server via the network and then authenticate with these servers using the data exchanged during the registration process (eg, on the biometric authentication device). Provisioned encryption key).

  In one embodiment, the authentication engine 3310 includes a guarantee level calculation module 3306 for calculating a guarantee level corresponding to the likelihood that a legitimate user owns the client device 3300. Then, to determine if the trusted party 3351 needs to authorize local transactions (eg, financial transactions, retail purchases, access to sensitive information in the user's account, etc.) at the local secure transaction device 3350, This assurance level can be used. In one embodiment, the trusted party 3351 can specify the level of assurance required for a particular transaction. For example, for a financial transaction involving a significant amount of transfer, the trusted party 3351 may require a relatively higher level of assurance than, for example, a transaction involving access to the user's account.

  In one embodiment, the assurance level calculation module 3006 sends the assurance level (e.g., specified as a value, ratio, code, etc.) to the trusted party 3351 without disclosing the user's confidential information, Thereby protecting user privacy. In other embodiments, the assurance level calculation module 3306 knows the assurance level required for the current transaction, determines whether the assurance level is high enough, and again relies on the trusted party 3351 to identify the user's personal information. Without disclosing, an indication is sent to the trusted party 3351 whether the transaction is allowed or denied.

  In one embodiment, communication between client device 3300 and trusted party 3351 uses a first key to encrypt outgoing communication and uses a second key to decrypt incoming communication. Can be secured via secure communication module 3313. In the symmetric key encryption method, the first and second keys are the same. In the asymmetric key encryption method, the keys are different. However, the basic principles of the present invention are not limited to any particular type of encryption.

  In one embodiment, the assurance level calculation module 3306 may include a current or recent explicit user authentication result 3305 that may include one or more explicit user authentication devices 3320-3321. Determining a guarantee level based at least in part on This includes, for example, fingerprint authentication via a fingerprint authentication device, face recognition authentication via camera and face recognition hardware / software, voice recognition via microphone and voice recognition hardware / software, camera and related hardware / It can include retinal scans using software, password / PIN entry by the end user via the keypad, and / or various other types of explicit user authentication devices and / or techniques.

  In one embodiment, secure storage device 3325 cryptographically protects biometric reference data records for each user authentication device 3320-3321 (eg, using a symmetric key to secure storage device 3325). Data wrapping). The secure storage device 3325 is illustrated outside the secure perimeter of the authentication devices 3320-3321, but in one embodiment, each authentication device 3320-3321 is for cryptographically protecting biometric reference data records. May have their own integrated secure storage device.

  In addition to explicit user authentication, one embodiment of authentication engine 3310 collects data from sensor 3343 for use by warranty calculation module 3306 to generate a level of assurance. Illustratively, sensor 3343 can include a position sensor, such as a GPS sensor, to indicate the current location of the user. If the client device 3300 is in an expected location, such as a known neighborhood of the local secure transaction device 3350, this increases the likelihood that the user is a legitimate user. In contrast, if the GPS reading indicates that the user is not near the local secure transaction device 3350, this indicates that the user initiating the transaction is not a legitimate user. Therefore, in one embodiment, the guarantee calculation module 3306 tends to increase the guarantee level when the user is in the expected position and decrease the guarantee level when the user is in the unexpected position.

  Various additional sensors 3343 such as temperature sensors, humidity sensors, and accelerometers can be used to collect data related to user authentication. For example, the temperature / humidity sensor can provide a current temperature / humidity that can be compared to a known temperature / humidity for a location specified by the position sensor. If the values are significantly different, this can indicate that the client device 3300 is impersonated. The asserted location and temperature / humidity comparison can be performed at a remote server, such as a secure transaction server used by a trusted party 3351. In other embodiments, an accelerometer in the device can be used to measure the user's gait and compare these measurements against the user's known gait. If the gait matches (within the specified threshold), this increases the likelihood that the legitimate user owns the client device 3300.

  The local authentication application 3304 can also be implemented in various ways while adhering to the basic principles of the present invention. For example, in one embodiment, the local authentication application 3304 is specifically designed for the trusted party 3351. For example, if the trusted party is a financial institution (eg, Wells Fargo®), the local authentication application 3304 can be an application specifically designed for / by the bank. In other embodiments, the same local authentication application 3304 can be shared among various trusted parties, for example, as a universal local authentication application. Further, although illustrated in FIG. 34 as a separate logical element, the authentication engine 3310 in FIG. 34 can be integrated within the local authentication application 3304. In other embodiments, the local authentication application 3304 can be a web browser or application that runs within a web browser context (eg, whether the user enters the vicinity of the local secure transaction device 3350 to initiate a transaction). Or when connecting to the web page of a trusted party).

  The local authentication application 3304 can perform various local functions depending on the implementation required by the trusted party. For example, in one embodiment, the local authentication application 3304 receives a secret code (or other authentication data) provided by the trusted party 3351 and receives (eg, via a barcode or other The secret code is securely transmitted to the local secure transaction device 3350 for authentication (using communication technology). Alternatively, in one embodiment, the user can manually enter a secret code into the local secure transaction device 3350. Similarly, authentication data such as a secret code received by the local secure transaction device 3350 can be relayed to the local authentication application 3304, followed by relaying the authentication data to the authentication engine 3310 and / or (eg, client Rely on a trusted party 3351 (as proof of the location of the device 3300).

  One embodiment of a method for authenticating a client device is shown in FIG. The method can be implemented on the architecture shown in FIGS. 33-34, but is not limited to any particular system architecture.

  At 3501, the client enters the vicinity of a local secure transaction device (eg, ATM), and at 3502, a secure connection is established with the local secure transaction device via a local channel. As described above, local channels can be implemented using near field communication, Bluetooth, WiFi, or other types of protocols supported by both client devices and local secure transaction devices. Operation 3502 may not be required in some embodiments. For example, if the client device can be authenticated by a trusted party with a high level of assurance that the legitimate user owns the client device, and the client device's current location relative to the trusted party The local channel may not be necessary.

  At 3503, the client device authenticates a trusted party over the network. Any available technique can be used for this operation to generate a level of assurance that a legitimate user owns the device. For example, a user can perform explicit authentication by swiping a finger on a biometric fingerprint authentication device, capturing a face image for face recognition, and / or entering a secret code. Alternatively, non-invasive authentication techniques can determine whether a user has been explicitly authenticated to a client device recently (eg, within a specified period of time) and / or position data, temperature / pressure data and This can be done using sensor data such as accelerometer data.

  Regardless of how the assurance level is generated, the result of the authentication is a party that can be trusted over the network in a manner that protects the user's privacy (eg, without providing data that specifically identifies the client device). Can be provided. For example, as described above, the assurance level itself and / or an indication of authentication success or failure can be provided to a trusted party without disclosing sensitive user information.

  If it is determined at 3504 that the authentication was successful, then at 3507 the local transaction is permitted. In one embodiment, this includes a trusted party that sends a signal indicating a local secure transaction device to perform one or more operations. For example, if the local secure transaction device is ATM, the operation may include a user-specified cash amount distribution. If the local secure transaction device is a debit device (eg, a retail store or other location where the user is making a purchase), a signal sent by a trusted party can confirm payment for the transaction (accordingly) Debit user account). It should be noted that these are merely examples. Furthermore, various alternative applications can be used while adhering to the basic principles of the present invention.

If authentication at 3504 fails (eg, because an acceptable assurance level has not been reached), at 3505 the transaction is rejected 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 (eg, secret code entry if the initial authentication is a fingerprint). If the additional technology is determined to be sufficient at 3506, the transaction is allowed at 3507. Otherwise, the transaction is rejected again and / or additional authentication techniques are attempted.
J. et al. User confirmation for online transactions

  There are various scenarios where completing a transaction with a trusted party requires approval from one or more other users. By way of illustration and not limitation, a parent may wish to approve a financial transaction initiated by a child, and a commander may need to approve a transaction initiated by a soldier, May need to approve a business transaction initiated by an employee and the encryption key management system requires multiple users to approve a particular transaction before it can be delegated Sometimes.

  One embodiment of the present invention uses the techniques described herein to provide strong authentication of users over a network to enable multi-user verification applications. An example of such a client device having a remote authentication function 3600 controlled by a user attempting to initiate a transaction with a trusted party having secure transaction service 3650 (hereinafter simply “trusted party”) is shown in FIG. It is shown. In one embodiment, the user of the client device 3600 may use one or more of the remote authentication techniques described herein (eg, biometric input, such as swiping a finger on a fingerprint sensor, PIN or password input, etc.). Authenticate by trusted party 3650 using

  In the illustrated embodiment, the other client devices 3601-3602 have users registered with a trusted party as the “approver” for the user of the client device 3600. Therefore, for certain types of transactions (eg, financial transactions that include an amount that exceeds a specified threshold), a trusted party may require approval from the user of client devices 3601-3602. As will be explained below, the remote authentication techniques described herein are used as part of the authorization process.

  In one embodiment, in response to successful authentication by the user of client device 3600, the notification generation logic at trusted party 3650 is an “approver” indicating that the user of client device 3600 is about to complete the transaction. Notification of the registered user is transmitted to the other client apparatuses 3601 to 3602. Notifications can be sent in various ways based on the basic principles of the present invention. For example, when the client devices 3601 to 3602 are mobile devices, push notifications can be transmitted to the client devices 3601 to 3602. Alternatively or additionally, the notification may be sent via email, text message (eg, SMS), instant message, or any other technique that can deliver the message to client devices 3601-3602. Good.

  In one embodiment, the notification includes details of the transaction attempted by the user of client device 3600. For example, if the transaction is a financial transaction, the notification can include the specific amount processed and the type of financial transaction that was performed (eg, 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 the client device 3601-3602 to an authorization service at a trusted party. Depending on the link selection, the client device users 3601-3602 may provide transaction details (eg, in a web page or other useful format for providing information).

  In one embodiment, the user of client device 3601-3602 can be trusted (eg, using the multi-factor authentication techniques described herein) in reviewing transaction details in response to the notification. The request can be confirmed by performing remote authentication with the party and indicating approval of the transaction.

  Additional architectural details of client devices 3600-3602 used in one embodiment of the invention are shown in FIG. In particular, the client devices 3600-3602 of this embodiment include a secure transaction application 3704 for communicating with a trusted party 3650 to coordinate the transaction authorization techniques described herein. Secure transaction application 3704 may be a stand-alone application that interfaces with authentication 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.

  In addition to coordinating the user confirmation process described herein, in one embodiment, the secure transaction application 3704 ensures that the text displayed to each user is the actual text associated with the transaction. To do. For example, the application 3704 can display text in a secure window and ask the user to provide authentication to confirm the transaction. The application may start a timer and periodically check the contents of the current window displayed to the user (eg, by generating a content signature). The verification period can be selected randomly. Therefore, the application continually ensures that each user sees the details of a valid transaction in the window (thus ensuring that the transaction text has not been altered by a “man in the middle” attack). If the application detects that the content has been tampered with, it prevents a transaction confirmation from being generated.

  In one embodiment, after the user provides valid authentication (eg, swiping a finger over a fingerprint sensor), the client device identifies the user, details of the transaction (eg, displayed text) and is trusted. Generate a token (encrypted signature) with a random challenge provided by the parties (eg, the token can be signed across transaction details and nonces). This allows a trusted party 3650 to confirm that transaction details have not changed between the server and the client. In one embodiment, the application 3704 sends the generated token and username to a trusted party that subsequently identifies the user by username and validates the token. If the verification is successful, a confirmation message is sent to the client and the transaction is processed.

The above technique may be implemented for both request / confirmation of both transactions originating from the client device 3600 and approval transactions originating from the users of the client devices 3601-3602.
Referring to FIG. 37, in one embodiment, authentication is via an authentication engine 3710 in client devices 3600-3602 that is designed to perform a series of transactions by a trusted party 3650 to remotely authenticate each user. Can be done. For example, as described in co-pending applications, the authentication framework and associated authentication techniques allow the user to generate biometric template data (eg, by swiping a finger, snapping an image, recording audio, etc.). To create one or more trusted parties 3650 (e.g., websites or secure transactions as described in co-pending applications) over the network, using the client's biometric device 3720-3721 to generate Register biometric devices with other trusted parties with services), and then use those data exchanged during the registration process (eg, encryption keys set on biometric devices) to trust them Authenticating by party 3650 can be used. In one embodiment, “registration” by a trusted party exchanges a symmetric or asymmetric key with the trusted party for each user authenticator 3720-3721, and in secure storage 3725 associated with each authenticator 3720-3721. Including storing the key. A secure key provisioning protocol, such as Dynamic Symmetric Key Provisioning Protocol (DSKPP), can be used to share keys with clients over a secure communication channel (see, eg, Request for Comments (RFC) 6063). However, the basic principles of the present invention are not limited to any particular key provisioning protocol.

  During the authentication phase, for example, the key is used to generate a signature, verify the signature, and / or encrypt communication between the clients 3600-3602 and the trusted party 3650. Once authenticated, the user is allowed to perform one or more online transactions. Further, in one embodiment, sensitive information such as fingerprint data and other data that can uniquely identify the user is used to protect the user's privacy, such as the user's client device (e.g., smartphone, notebook computer, etc.). ) Can be held locally on.

  In one embodiment, the authentication engine 110 includes an assurance level calculation module 3706 for calculating an assurance level corresponding to the likelihood that a legitimate user owns the client device 100. It can then use this assurance level to determine whether the trusted party 3650 needs to approve the current transaction. In one embodiment, the trusted party 3650 can specify the level of assurance required for a particular transaction. For example, for a financial transaction involving a significant amount of transfer, a trusted party 3650 may require a relatively higher level of assurance than, for example, a transaction that does not involve exchanging gold or simply accessing user information.

  In one embodiment, the assurance level calculation module 106 sends the assurance level (e.g., specified as a value, ratio, code, etc.) to the trusted party 3650 without disclosing the user's confidential information, Thereby protecting user privacy. In other embodiments, the assurance level calculation module 3706 knows the assurance level required for the current transaction, determines whether the assurance level is sufficiently high, and provides the user's personal information to the trusted party 3650. Without disclosing, an indication is sent to the trusted party 3650 whether the transaction is allowed or denied.

  In one embodiment, communication between client devices 3600-3602 and trusted party 3650 uses the first key to encrypt outgoing communication and uses the second key to communicate incoming communication. It is secured via a secure communication module 3713 that can be decrypted. In the symmetric key encryption method, the first and second keys are the same. In the asymmetric key encryption method, the keys are different. However, the basic principles of the present invention are not limited to any particular type of encryption.

  In one embodiment, the assurance level calculation module 3706 may include current or recent explicit user authentication results 3705 that may include current or recent explicit user authentication results via one or more explicit user authentication devices 3720-3721. Determining a guarantee level based at least in part on This includes, for example, fingerprint authentication via a fingerprint authentication device, face recognition authentication via camera and face recognition hardware / software, voice recognition via microphone and voice recognition hardware / software, camera and related hardware / It can include retinal scans using software, password / PIN entry by the end user via the keypad, and / or various other types of explicit user authentication devices and / or techniques.

  In one embodiment, secure storage device 3725 cryptographically protects biometric reference data records for each user authentication device 3720-3721 (eg, using a symmetric key to secure storage device 3725). Data wrapping). Although secure storage device 3725 is illustrated outside the secure perimeter of authentication devices 3720-3721, in one embodiment, each authentication device 3720-3721 cryptographically protects biometric reference data records. May have their own integrated secure storage device.

  In addition to explicit user authentication, one embodiment of the authentication engine 3710 performs non-invasive authentication by collecting data from a sensor 3743 that is used by the guarantee calculation module 3706 to generate a guarantee level. Illustratively, the sensor 3743 can include a position sensor, such as a GPS sensor, to indicate the current location of the user. If the client devices 3600-3602 are in an expected location such as a known neighborhood (eg, “home” or “office” location), this increases the likelihood that the user is a legitimate user. In contrast, if the GPS reading indicates that the user is not in the expected position, this indicates that the user initiating the transaction is not a legitimate user. Therefore, in one embodiment, the guarantee calculation module 3706 increases the guarantee level when the user is in the expected position and decreases the guarantee level when the user is in the unexpected position.

  Various additional sensors 3743 such as temperature sensors, humidity sensors, and accelerometers can be used to collect data related to user authentication. For example, the temperature / humidity sensor can provide a current temperature / humidity that can be compared to a known temperature / humidity for a location specified by the position sensor. If the values are significantly different, this can indicate that the client devices 3600-3602 are impersonated. The asserted location and temperature / humidity comparison can be performed at a remote server, such as a secure transaction server used by the trusted party 3650. In other embodiments, an accelerometer in the device can be used to measure the user's gait and compare these measurements against the user's known gait. If the walking matches (within the specified threshold), this increases the likelihood that the legitimate user owns the client devices 3600-3602.

  Other non-invasive authentication techniques include measuring the amount of time that has elapsed since the last successful user authentication. For example, if the user has performed explicit user authentication very recently (eg, swiping a finger on the fingerprint sensor just a few minutes ago), this may indicate that the legitimate user still owns the client device. Tend to show (thus resulting in a high standard assurance level). In contrast, if the last explicit authentication was hours or days ago, a new explicit user authentication can be required to reach an acceptable level of assurance. .

  A method according to one embodiment of the present invention is illustrated in FIG. At 3801, the client user triggers a transaction that requires confirmation by N other users. For example, the trusted party's user account may indicate that a particular type of transaction (or all transactions) initiated by the user requires confirmation by one or more other users. For example, the user's account can identify the user as a minor that requires authentication by one or more parents or guardians. The user is also authenticated at 3801 by implementing one or more of the authentication techniques described herein.

  At 3802, the server selects N other users who need to confirm the user triggered transaction. For example, upon detecting the start of a transaction by a user, a trusted party can query its user database to determine that the transaction requires confirmation and identification of a user who can confirm the transaction. . In one embodiment, all subsets of users who can confirm the transaction can actually confirm the transaction. For example, if the user is a minor with two parents, in one embodiment, a notification may be sent to both parents, but confirmation by either parent will cause the transaction to proceed. Make it possible. Similarly, there may be 10 authenticated users to confirm a business transaction, but only two confirmations are required to allow the transaction to proceed.

  In one embodiment, a push notification can be sent to those users' client devices that can confirm the transaction (eg, if the user has a client device that can receive push notifications). . Alternatively or additionally, the notification may be sent via email, text message (eg, SMS), instant message or any other technique that can deliver the message to the client device. In one embodiment, the user can be registered with the server to receive confirmation messages via more than one communication channel. For example, the user can receive both a push notification and an email containing a confirmation request.

  Regardless of how the confirmation request is sent, at 3803, all or a subset of the N users authenticate with the server as part of the confirmation process. Any remote authentication technique can be used to authenticate the user and confirm the transaction. For example, a user can confirm a transaction by providing biometric data to a biometric device at a client previously registered with a trusted party (eg, swipe a finger on a fingerprint scanner). As mentioned above, details related to the transaction can be provided to the user via a secure transaction application that can securely display text and other information (ie, if the user confirms the transaction, he / Ensuring she saw the actual immutable text explaining the transaction).

If it is determined at 3804 that the minimum specified number of users has confirmed the request, the transaction is permitted at 3807. One embodiment of the method starts a confirmation timer to measure the elapsed time since the confirmation request was sent. If it is determined at 3805 that the confirmation timer has reached a threshold (eg, several hours, days, etc.), the transaction is prohibited at 3806. The method waits at 3804 for the minimum specified number of users to confirm the request until the timer threshold is reached.
K. System and method for delegating trust

  Existing authentication systems do not allow a new authenticator to be validated using an authenticator registered with a trusted client. For example, if a user has a fingerprint sensor on a mobile phone that installs a phone voice authentication system after being registered on many websites, she will be able to hear her voice on every website she used with the fingerprint sensor. There is no way to automatically register the authentication part. Rather, in this case, the user must step through the same registration and registration process to register the voice authenticator with a trusted party. Similarly, when a user purchases a new device using a new set of authentication units, the user needs to re-register and re-register all of the new authentication units with the server.

  The embodiments of the present invention described below facilitate a user to authenticate a new client device using a trusted client device that has already been validated and registered with one or more trusted parties. Allows registration as valid. In particular, these embodiments can be used to enable a new authenticator, enable a new client device, and maintain registration among multiple client devices synchronously.

  FIG. 39 provides an overview of high level trust delegation according to one embodiment of the present invention. A trusted device 3902, ie, a device having an authenticator registered with one or more trusted parties 3950, establishes a secure connection with the user's new client device 3900. The particular method by which a secure connection is established is not related to the basic principle of the present invention. Various technologies such as near field communication (NFC), Bluetooth, direct WiFi, etc. that establish a HTTPS connection using a quick response (QR) code can be used. In one embodiment, the device can exchange large random tokens (LRT) required for secure connections, and can establish a connection by providing captured LRT to an online service; Secure communication can be bootstrapped through the service.

  In one embodiment, once a secure connection is established between a trusted client device 3902 and a new client device 3900, a secure protocol is used to transfer and integrate registration data from the trusted device to the new device. Implemented (details will be described later). Once the registration is transferred, another secure protocol is implemented between the new client device 3900 and the trusted party 3950 to verify the registration (eg, HTTPS in one embodiment).

  Although the embodiments described herein focus on the transfer of authentication data used for authentication transactions with a trusted party 3950, the trusted party is required to comply with the basic principles of the present invention. It may not be. For example, the trusted device 3902 can connect the new client device 3900 without any trusted party involved in the system (eg, to provide authentication data for local authentication using the new client device 3900). A secure connection can be established to provide authentication data to the server.

  As shown in FIG. 40, the trust delegation modules 4000-4001 each establish a secure connection, exchange registrations, and verify each registration with the secure transaction service 4004 at each trusted party 3950, respectively. It can run on 3900 and trusted device 3902. As used herein, a “trusted authenticator” is an authenticator that a user has already registered with one or more trusted parties. A new “new authenticator” would like to allow registration of all trusted parties that the user is currently using with an authenticator that is trusted. Therefore, the authentication engine 3711 is considered a trusted authenticator if it has previously registered one or more user authentication devices 3720-3721 with a trusted party. The purpose of one embodiment is to enable the authentication engine 3710 of the new device 3900 from a new authenticator to a trusted authenticator. The “trusted device” has a reliable authentication unit, and the “new device” has a new authentication unit.

  Trust delegation refers to the process of enabling a new authenticator using a trusted authenticator. Therefore, the preconditions for trust delegation are as follows: the user has a trusted device; the user has a new device; the user wants to delegate trust from a trusted device to the new device I believe.

  Referring to FIG. 40, in one embodiment, a user initiates a trust delegation application 4000 on a new client device 3900 and a trust delegation application 4001 on a trusted client device to establish an initial secure connection. In one embodiment, the trust delegation application may be a mobile device application specifically designed to perform the trust delegation operations described herein. In other embodiments, the trust delegation application allows he / she to perform delegation of trust (eg, via a web page containing embedded JavaScript or other applet or executable program code). It can be a browser plug-in that is executed in response to a user indicating that he wants to. Further, trust delegation applications 4000-4001 can be software modules within a larger application, such as an authentication application designed to manage authentication with a trusted party. However, it should be noted that the basic principles of the present invention are not limited to any particular implementation of trust delegation applications 4000-4001.

  In one embodiment, to authorize a trust delegation operation on the trusted device 3902, the user authenticates locally with the trusted device's authentication engine 3711 (eg, biometric input to the user authenticators 3722-3723). I will provide a). Similarly, in one embodiment, the user can authenticate locally using the authentication engine 3710 in the new client device 3900. These two authentication steps can provide authentication of the trust delegation application 4000-4001 to perform the delegation process.

  As described above, the trust delegation application 4000 to 4001 can use any of the communication interfaces available in the respective client devices 3900 and 3902 (for example, Bluetooth interface for Bluetooth connection, NFC connection for establishing a secure connection). NFC interface etc.) can be used.

  When a secure connection is established, in one embodiment, the trusted delegation application 4001 of the trusted client 3902 provides data indicating the number of keys (N) in the trusted client registered with the trusted party. In response, in one embodiment, the trust delegation application 4000 includes N new device key pairs (ND_Uauth) that include one private key (ND_Uauth.priv) and one public key (ND_Uauth.pub). ) And send N new device public keys to the trusted delegation application 4001 of the trusted device 3902.

  In one embodiment, the trust delegation application 4001 then creates its corresponding trusted device private key (TD_Uauth.sig) to generate a signature (TD_Uauth.sig) associated with each of the N new device public keys. Sign each of the N new device public keys by TD_Uauth.priv). In one embodiment, the “corresponding” secret key is a secret key associated with a particular registration corresponding to a trusted party. The trust delegation application 4001 can also insert a timestamp into a generated signature that can subsequently be used by a trusted party to verify correctly when trust delegation occurs. In one embodiment, the trusted delegation application 4001 of the trusted client 3902 sends each of the generated signatures along with other registration data associated with each trusted party to the new client 3900's trust delegation application 4000. To do. The data for each trusted party includes one or more trusted party ID codes (eg, application ID codes that identify services at the trusted party), user names registered for users of the trusted party, upon authentication It may include a key ID code used by a trusted party to find the appropriate key and other data related to the authentication process.

  In one embodiment, once the trust delegation application 4000 receives a signature or other registration data, when a new client device 3900 connects to the trusted party 3950, it can be used subsequently. It integrates this data into the local secure storage 3725.

  In one embodiment, after the registration database is stored in the local secure storage device 3725, a series of bootstrap operations are performed by a trusted party (eg, website, service, etc.) previously registered with the trusted client device 3902. Can be executed by the trust delegation application 4000 to utilize the registration delegated in the new client device 3900. Alternatively, the described bootstrap operation can be performed by the authentication engine 3710 itself (via direct communication with the secure transaction service 4004 as shown in FIG. 40). The basic principles of the present invention remain the same regardless of which particular software component in the new client device 3900 performs the operation.

  In particular, in one embodiment, the secure transaction service 4004 of the trusted party 3950 has a registration on the new client device 3900 using a remote authentication protocol supported by the secure transaction service 4002 and the trust delegation application 4000. Is detected. In one embodiment, the user may be initially asked by the secure transaction service 4004 to perform biometric authentication or other forms of authentication (eg, entering a secure code) from the new client device 3900. Further, at this stage, the secure transaction service 4004 can verify the time stamp inserted in the signature and confirm that the time stamp is not older than the threshold amount of time.

Assuming that 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 credentials:
1. Proof over a new device public key associated with a trusted party (ND_Uauth.pub). In one embodiment, the proof includes a signature generated over the public key (eg, using a trusted party's public key).
2. Proof using a new device private key associated with the trusted party (ND_Uauth.priv). In one embodiment, to generate a proof, the private key is used by a trusted party (eg, a random challenge sent from the trusted party) to generate a signature over known content. Since the trusted party has the public key (in step 1), the content can be decrypted, thereby confirming that the private key has been used to encrypt the content.
3. Previously generated and trusted by a trusted client device to locate the public key (eg, so that the key ID can be used to query its secure transaction database 4025 to obtain the public key) A signature (TD_Uauth.sig) associated with the new device public key for this particular trusted party along with the key ID (TD_Uauth.keyid) used by the party.

  In one embodiment, all of the data is sent to the trusted party's secure transaction service 4004 in a remote authentication response.

In one embodiment, after receiving the proof, the secure transaction service 4004 may perform the following verification:
1. Place the trusted device public key (TD_Uauth.pub) using the key ID.
2. The signature (TD_Uauth.sig) generated by the trusted device is verified using the trusted device's public key (TD_Uauth.pub).
3. The new device's public key (ND_Uauth.pub) is used to verify the signature (ND_Uauth.sig) generated by the new device's private key.
4). Validate the certificate over the new device public key (ND_Uauth.pub) associated with the trusted party. In one embodiment, this verification is performed using the trusted party's private key.

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

  Referring first to FIG. 41, at 4101 a new device establishes a secure communication channel with a trusted device and determines the number (N) of key pairs to generate. As mentioned above, this can be the number of key pairs registered by a trusted party and trusted means.

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

  Referring now to FIG. 42, at 4201, the new client (who has already performed the delegation operation from FIG. 41) establishes a secure connection with the trusted party. At 4202, the trusted party detects that there is an existing registration delegated to the new device. In response, at 4203, the trusted party makes an authentication request to the new device. The user can then authenticate using one or more biometric or other authentication techniques. As described above, at 4204, the new device is certified over the new device public key, a signature generated with the new device private key (eg, over the challenge), and the trusted device private key and associated. A response including a signature generated using the key ID to be prepared is prepared. At 4205, all data in the response is sent to the trusted party, and at 4206, the trusted party verifies the data contained in the response (see above for details of one embodiment). If verification is successful, at 4207, a transaction attempted by the user is allowed.

  The techniques described herein can be used to delegate trust between two authenticators on different devices (as described above). Further, in one embodiment, these techniques can be used to delegate trust between two authenticators on the same device. In this case, it is not necessary to establish a secure connection between the two devices, but all other operations may be performed between the two authenticators in the device.

Furthermore, it should be noted that some of the related operations can be performed in various ways. For example, a secure protocol for delegating trust can be initiated by a trusted device rather than a new device. In any case, the new device (or more specifically, the authenticator in the new device) can generate a new number of key pairs (ND_Uauth), and the authenticator in the trusted device can You can sign the public key of your key pair.
L. System and method for privacy enhanced data synchronization

  Current systems exist to synchronize data among multiple client devices using cloud services. When a user creates a new document on the device (eg, snaps a picture, creates a word processing document, etc.) or modifies an existing document, the cloud service in which the user is participating is usually “new in the cloud” Memorize a copy of the document that has been modified / corrected. If the user accesses the cloud service from a second device (eg, a work computer or other device used by other family members), the cloud service can be configured to synchronize the device.

  One problem that exists is that data is frequently stored in cloud services in an unencrypted form, weakening the data against various types of cyber attacks and queries by federal agencies.

  The embodiments of the present invention described below provide a set of protocols and techniques that allow data to be synchronized between devices in a privacy-enhancing method. Using these protocols and techniques, cloud services do not need to access data in clear text (eg, unencrypted form), thereby protecting user privacy.

  As a first matter, it should be noted that the techniques described below do not rely on the advanced authentication techniques described herein to synchronize data between devices. For example, these synchronization techniques can be used outside the context of a system for remote user authentication, as described for other embodiments of the invention. However, these synchronization techniques can be used to perform synchronization of these remote user authentication embodiments. For example, in one embodiment, registration data for each website or other online service visited by a user can be synchronized between multiple devices using these synchronization techniques.

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

  One embodiment of the present invention includes protocols and related techniques to allow new user equipment to (a) join a circle and (b) subsequently synchronize with the circle. These embodiments include privacy synchronization applications 4311-4313 for implementing the protocols and techniques described herein, respectively, and secure data storage devices 4321-4332 for storing data used for participation and synchronization, respectively. 43, each showing three client devices 4301-4303 having In this specification, device 4301 is sometimes referred to as device d1, device 4302 is sometimes referred to as device d2, and device 4303 is sometimes referred to as device d3.

In one embodiment, participation and synchronization is performed via a plurality of circle clouds 4350 including a plurality of storage device servers. The trust chain 4360 within the circle cloud 4350 maintains a data-defined trust relationship between the devices 4301-4303 as will be described below. Circle channel 4370 comprises a secure communication channel provided by a circle cloud that is used by two or more devices to exchange and synchronize data.
a. Join a circle

  Device 4302 (d2) joins an existing network of devices 4301 (d1) and 4303 (d3) belonging to a user (ie, a “circle” of trusted devices). A device 4302 can join an existing circle only if another device 4301 that is already part of that circle allows it.

  One embodiment of a method for authenticating a new device 4302 using the trusted device 4301 is shown in FIG. At 4401, the user authenticates the new device 4302 with the existing trusted device 4301. For example, in one embodiment, the user can start its privacy synchronization application 4311 on the trusted device 4301 and the privacy synchronization application 4312 on the new client device 4302.

  At 4402, in one embodiment, privacy synchronization applications 4311 to 4312 cause devices 4301 to 4302 to establish a secure connection. In order to establish a secure connection, various techniques such as near field communication (NFC), Bluetooth, direct WiFi, etc. can be used to establish an HTTPS connection using a quick response (QR) code.

  At 4403, device 4301 transmits 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}. Here, d1. pub is the public key of the device 4301, and sk. “sym” is a randomly generated session key generated by the device 4301, and “circle-id” is a unique identification code for identifying a circle in which the device 4302 is participating.

At 4404, device 4302 reads join1_data and prepares a response that can include:
HMAC (sk.sym, d2.pub | T) | d2. pub | T, where T is a time stamp.
Trust-block1 = S (d2.priv, d1.pub) | d1. pub | d2. pub.
Note that HMAC stands for hash-based message authentication code. In the above embodiment, the HMAC concatenates the time stamp and the public key of the device 4302, and uses sk. Generated by protecting the integrity of the result by sym. Further, trust-block 1 includes a signature generated with the private key of device 4302 across the public key of device 4301. In one embodiment, the trust-block1 entry also includes a time stamp (T).

  Referring to FIG. 44, at 4405, device 4302 securely connects to circle cloud 4350 and sends a response including HMAC and trust-block1. The circle cloud 4350 stores the data received by the device 4301 and waits for the device 4301 to connect.

  At 4406, device 4301 uses circle-id to connect to the circle cloud, verifies the integrity of the data contained in device 4302's response from operation 4405, and generates trust-block2. In particular, in one embodiment, device 4301 includes sk. Using sym d2. Read pub and T to verify integrity (eg, use sk.sym to decode d2.pub and T). Then, the device 4301 has its own secret key d1. using priv d2. sign the pub, d1. by priv d2. trust-block2 = S (d1.priv, d2.pub) | d2 including the signature generated over pub. pub | d1. pub is generated. In one embodiment, trust-block 2 also includes a time stamp (T). Then, the device 4301 transmits the data including trust-block 2 to the circle cloud 4350.

At 4407, the circle cloud 4350 adds both trust blocks to the trust chain 4360. In one embodiment, after the above operation, device 4302 joins the circle associated with the circle-id. All devices 4301, 4303 in this circle trust device 4302, and device 4302 trusts all of these devices. Note that any trusted device can authenticate the new device using the techniques described herein.
b. Sync with circles

  During this process, devices 4301-4303 belonging to the same circle synchronize data between them. There can be different application specific sub-protocols implemented on top of this process. For example, an online cloud storage device application may want to keep the user's data synchronized on all devices, and may want to keep an encrypted copy on the circle cloud. Other applications can propagate messages to devices in the circle. For example, in one embodiment, registration data used by one device to authenticate a remote trusted party can be synchronized between all devices in the circle. Furthermore, various other applications and sub-protocols can be implemented while adhering to the basic principles of the present invention. All such sub-protocols can use the basic processing blocks described below.

  Trust chain

  As revealed in the “Circle Join” process (FIG. 44), what enters the trust chain 4360 is proof that the device 2 is trusted by the device 1. Therefore, trust chain 4360 is a chain of respective authentication blocks that assert a trust relationship between the two devices. In one embodiment, the trust chain is interchangeable, meaning that if device 4301 trusts device 4302, device 4302 trusts device 4301. Trust chain 4360 is considered broken if there is a block that device 4301 claims to trust device 4302 and no block that device 4302 claims to trust device 4301. In one embodiment, trust chain 4360 is also transient, meaning that device 4301 trusts device 4303 if device 4301 trusts device 4302 and device 4302 trusts device 4303. In one embodiment, the trust chain is cycle-id specific and does not contain any sensitive information about the device.

  In one embodiment, trust chain 4360 includes a plurality of trust blocks, each block including the following data: {di. pub, dj. pub, S (di.priv, dj.pub), S (dj.priv, di.pub)} — that is, generated using each device's public key and each device's private key across each device's public key Signature.

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

  In one embodiment, to determine whether device di is in the same circle as device dj, the following operations are performed: (a) Each node is a device in the trust chain, and each arrow is Build a directed graph corresponding to the blocks in the trust chain and (b) determine if there is a direct path connecting di and dj.

  Circle channel

  In one embodiment, the process shown in FIG. 45 is performed to synchronize data with other devices in the same circle. In the illustrated example, the device 4301 (d1) is a device that has new data and wants to send it to another device. At 4501, device 4301 downloads trust chain 4360 associated with the circle-id, identifies other devices in the same circle from the trust chain (eg, devices 4302-4303), and uses the trust chain. Obtain public keys of other devices in the same circle.

  At 4502, device 4301 generates a random encryption key (REK) (eg, using known techniques for random number generation). At 4503, device 4301 derives a mutual session key (SK) for each of the other devices in the circle. In one embodiment, device 4301 derives an SK using a Diffie-Hellman key exchange algorithm for each of the other devices. Diffie-Hellman is a well-known algorithm that allows two parties that do not have prior knowledge of each other to jointly establish a shared secret key. In this case, for example, when the first device has a key pair and provides the public key to the second device, the second device is independent using the private key and the public key of the first device. A new key (SK in this patent application) can be automatically derived (and vice versa). In one embodiment, device 4301 uses these techniques to generate a different SK for each other device 4302, 4303.

At 4504, device 4301 encrypts the REK with the SK derived for each device and combines them with the appropriate public key. For example, for device d1 that generates SKi and SKj for devices di and dj, respectively, it uses the session key to encrypt the REK as follows:
{D1. pub, di. pub, E (SKi, REK)} (about apparatus di)
{D1. pub, dj. pub, E (SKj, REK)} (for apparatus dj)
At the end of the process, each of the devices di and dj can decrypt the REK using their respective session keys (derived independently by each device using Diffie-Hellman as described above). .

  At 4505, device 4301 encrypts the data to synchronize by REK-ie E (REK, data to be synchronized). As described above, any data may be synchronized, such as, for example, multimedia files, productivity documents, and / or client configuration data (eg, trusted party registration data as described above). it can.

At 4507, device 4301 provides the circle channel with the REK encrypted with each SK and the synchronized data encrypted with REK:
[{D1. pub, di. pub, E (SKi, REK)}, {d1. pub, dj. pub, E (SKj, REK)}, ...]
E (REK, synchronized data)

  After the data is provided to the circle channel, at 4506 individual devices within the same circle correspond to their public keys (eg, {d1.pub, di.pub, E (SKi, REK)} for device di). Download records, derive the same SK (eg, SKi), decrypt the REK, and use the REK to decrypt the synchronized data.

  In one embodiment, a “join circle” operation as described above may require user authentication on both device 1 and device 2. If this protocol is implemented using the remote authentication techniques described herein, the user may, for example, use his finger to authenticate both devices to initiate and complete a “join circle” process. You may need to “swipe”. In contrast, in one embodiment, synchronization data between devices as described does not require user authentication.

  The protocols and related techniques described herein allow a network of devices that trust each other to be built. Importantly, all data transmitted to and stored in the cloud from the cloud is encrypted. Thus, the data can be synchronized between multiple devices without storing any sensitive data on the cloud, resulting in improved user privacy protection.

The embodiments of the present invention described above provide a private synchronization protocol for device synchronization where the participating cloud storage devices cannot display any of the user's data in plain text (ie, the data is encrypted in the cloud). Implement. These embodiments include, but are not limited to, a variety of new and useful features including:
A system and method for implementing a device synchronization protocol with a public key and a private key for the device to authenticate other devices.
A system and method for implementing a trust chain to show trust relationships between devices in the same circle.
A system and method for the device to use Diffie-Hellman or similar key exchange algorithms to generate encrypted data with the mutual session keys and these keys.
A system and method in which the hash of the circle-id is stored in the circle cloud instead of the device itself.
A system and method that uses a challenge response protocol to authenticate a device before allowing the circle cloud to place data in the circle channel of the circle.
A system and method in which a persistent circle group key is used to encrypt synchronization data.
An application that stores an encrypted backup of data on the cloud using the private synchronization protocol described to share user data (documents, files, photos, etc.) between multiple devices.
A system and method in which the device's private key (d.priv) and all operations that use this key are implemented in the authenticator to remotely authenticate the user over the network.
An application that uses the private synchronization protocol described in combination with embodiments of the present invention to perform user-controlled trust delegation for new devices to share authentication unit registration between user devices.
-Every time a new registration is delegated to another device, the user does not need to authenticate by the authentication unit, in order to perform a user-controlled trust delegation to the new device in order to share the new registration between the user's devices An application that uses the private synchronization protocol described in combination with an embodiment of the present invention.
・ These authenticators belong to the same user who uses the above private synchronization protocol to synchronize the authentication key pair to share the registration of a single authenticator by other authenticators belonging to the same circle. A set of authentication units that form a circle.
M.M. Example system architecture

  The term “trusted party” refers not only to the entity attempting to perform a user transaction (eg, a website or online service performing a user transaction), but also to the underlying authentication techniques described herein. It should be noted that it is used herein to refer to a secure transaction server that is implemented on behalf of that entity that can execute. The secure transaction server may be under the control of an owned and / or trusted party, or under the control of a third party that provides secure transaction services to a trusted party as part of the business structure. There may be. These distinctions are that a “trusted party” can include not only the website 4631 and other network services 4651, but also secure transaction servers 4632-4633 for performing authentication techniques on behalf of the website or network. 46A-B, described below, which indicates

  In particular, FIGS. 46A-B illustrate two embodiments of a system architecture that includes client-side and server-side components for authenticating a user. The embodiment shown in FIG. 46A uses a browser plug-in based architecture for communicating with a website, while the embodiment shown in FIG. 46B does not require a browser. The various advanced authentication techniques and associated applications described herein can be implemented in any of these system architectures. For example, the authentication engine (eg, 230) in the client device described above can be implemented as part of a secure transaction service 4601 that includes an interface 4602. However, it should be noted that the embodiments described above may be implemented using hardware and software logic configurations other than those shown in FIGS.

  Referring to FIG. 46A, the illustrated embodiment includes a client 4600 with one or more authentication devices 4610-4612 for registering and authenticating end users. As described above, the authentication devices 4610-4612 can include fingerprint sensors, voice recognition hardware / software (eg, a microphone and associated software for recognizing the user's voice), face recognition hardware / software (eg, user's A biometric device such as a camera for recognizing a face and associated software) and an optical recognition function (an optical scanner and associated software for scanning the user's retina), and a trusted platform module (TPM) and Non-biometric authentication devices such as smart cards can be included. A user can register with the biometric device by providing biometric data (eg, swiping a finger on the fingerprint authenticator), and the secure transaction service 4601 (via the interface 4602) is a secure storage device 4620. Can store biometric authentication template data.

  The secure storage device 4620 is shown outside the secure peripherals of the authentication devices 4610-4612, but in one embodiment, each authentication device 4610-4612 may have its own integrated secure storage device. Good. Further, each authenticator 4610-4612 can cryptographically protect biometric reference data records (eg, wrap them using a symmetric key to secure storage device 4620).

  Authentication devices 4610-4612 are communicatively connected to the client via an interface 4602 (eg, an application programming interface or API) exposed by secure transaction service 4601. Secure transaction service 4601 is a secure and application for communicating with one or more secure transaction servers 4632-4633 over the network and interfacing with secure transaction plug-in 4605 running within the context of web browser 4604. . As shown, the interface 4602 also provides information and information related to each of the authentication devices 4610-4612, such as a device identification code, user identification code, user registration data (eg, scanned fingerprint or other biometric data). Secure access to secure storage device 4620 at client 4600 that stores the keys used to perform the secure authentication techniques described herein may be provided. For example, as will be described in detail below, a unique key is stored in each of the authentication devices and can be used when communicating with the server 4630 via a network such as the Internet.

  In addition to device registration, the secure transaction service 4601 then registers the biometric device with the secure transaction servers 4632-4633 over the network and then uses those data exchanged during the registration process to these servers. (For example, an encryption key provisioned in the biometric authentication device). The authentication process may include any of the authentication techniques described herein (e.g., generating an assurance level at client 4600 based on an explicit or non-invasive authentication technique to secure transaction server 4632- The result is transmitted to 4633).

  As described below, certain types of network transactions are supported by secure transaction plug-ins 4605, such as HTTP or HTTPS transactions with a website 4631 or other server. In one embodiment, the secure transaction plug-in was inserted into the HTML code of the web page by a secure enterprise or web server 4631 within the web destination 4630 (hereinafter sometimes referred to simply as “server 4630”). Started in response to a specific HTML tag. In response to detecting such a tag, the secure transaction plug-in 4605 can forward the transaction to the secure transaction service 4601 for processing. Further, for certain types of transactions (such as secure key exchange), the secure transaction service 4601 communicates directly with the on-premises transaction server 4632 (ie, co-located with the website) or off-premises transaction server 4633. You can open the channel.

  Secure transaction servers 4632-4633 are coupled to secure transaction database 4640 for storing user data, authentication device data, keys, and other secure information necessary to support secure authentication transactions described below. However, it should be noted that the basic principles of the present invention do not require separation of logical components within the secure enterprise or web destination 4630 shown in FIG. 46A. For example, website 4631 and secure transaction servers 4632-4633 may be implemented in a single physical server or other physical servers. Further, the website 4631 and transaction servers 4632-4633 may be implemented in an integrated software module that is executed on one or more servers to perform the functions described below.

  As described above, the basic principles of the present invention are not limited to the browser-based architecture shown in FIG. 46A. FIG. 46B illustrates an alternative embodiment in which the standalone application 4654 utilizes the functionality provided by the secure transaction service 4601 to authenticate a user over the network. In one embodiment, application 4654 may establish a communication session with one or more network services 4651 that rely on secure transaction servers 4632-4633 to perform the user / client authentication techniques described in detail below. Designed to.

  In any of the embodiments shown in FIGS. 46A-B, the secure transaction servers 4632-4633 can then be securely transmitted to the secure transaction service 4601 and stored in the authentication device in the secure storage device 4620. Can be generated. Further, the secure transaction servers 4632 to 4633 manage a secure transaction database 4640 on the server side.

  An exemplary series of transactions for the authentication device to detect, register, register and authenticate is shown in FIGS. Some aspects of these transactions are used in the OSTP protocol described above (see OSTP Framework (March 23, 2011) for additional details incorporated herein). Understanding the basic operation of these transactions provides a context in which embodiments of the present invention can be implemented.

  The operations described below are: authentication device detection (FIG. 47); user registration by authentication device (FIG. 48); authentication device registration (FIG. 49); user authentication by registered authentication device (FIG. 50); And the implementation of a secure transaction following authentication (FIG. 51).

  FIG. 47 illustrates a series of transactions for detecting an authentication device on a client device. Upon successful completion of device detection, server 4730 has comprehensive information about the authentication device connected to the client and evaluates the device that is most appropriate to use the enhanced security infrastructure. Will be able to. Only server 4730 filters the list of authentication devices. The user can provide this list and select one (or combination) of authentication devices to use for further authentication and secure transaction implementation.

  In operation, a user authenticates with a username and password in a browser and logs into a website. This is the only time required for the user to provide a username and password. Server 4730 determines that the user is not currently using enhanced security (eg, by querying secure transaction database 4720) and provides the user with a suggestion to change to enhanced security.

  In one embodiment, server 4730 includes a “device query” tag in the HTML page that secure transaction plug-in 4705 detects. In response to the tag detection, the secure transaction plug-in 4705 then resends the request to the secure transaction service 4701 that creates comprehensive information about all authenticators attached to the system, including the security characteristics of the device. Route. In one embodiment, the information is packaged in XML format prior to transmission using a pre-specified data schema.

  Secure transaction plug-in 4705 receives this information from secure transaction service 4701 and, in one embodiment, passes the information to JavaScript on the web page via a registered callback. It then selects a method for displaying information on the browser 4704. The list filtered by the website can be presented to the user, who can select one or a combination of authentication devices.

  FIG. 48 illustrates a series of transactions for registering a user by the authentication device. In one embodiment, registration is a prerequisite for using the enhanced security provided by the embodiments of the invention described herein. Registration includes taking a user's biometric reading (eg, fingerprint, voice sample, etc.) so that the same authenticator can be used to authenticate the user during subsequent transactions. The registration operation can be performed alone on the client without interaction with the server 4730. The user interface provided for registration can be displayed in an extension of the browser or can be displayed in a separate application or mobile device application.

  The registration operation may begin as soon as the device is detected. The user can use one or a group of detected devices to enhance security. In operation, a user can select a device from a device list displayed in a browser, application or mobile device application. For the browser-based implementation shown in FIG. 48, secure transaction plug-in 4705 displays a device specific registration graphical user interface (GUI). The secure transaction plug-in 4705 transmits a device identifier and a registration request to the transaction service 4701 and waits for completion. If the user is already registered with the client's authentication device, the user may only need to verify his identity (ie they do not need to register again). If the user is not currently registered, secure transaction service 101 initiates the registration process by activating the physical authentication device (eg, via device interface 4702). The user then interacts with the secure transaction plug-in 4705 GUI and follows a designated registration step (eg, swipes a finger, speaks into a microphone, snaps an image, etc.). When completed, the user is registered with the authentication device. Importantly, once a user is registered with the device, they can use this registration to register or authenticate to any website or network service described herein. .

  FIG. 49 illustrates a series of transactions for authentication device registration. Upon registration, the key is shared between the authentication device and one of the secure transaction servers 4732-4733. The key is stored in a secure transaction database 4720 used by secure storage 4720 and secure transaction servers 4732-4733 of client 4700. In one embodiment, the key is a symmetric key generated by any of the secure transaction servers 4732-4733. However, in other embodiments described below, asymmetric keys can be used. In this embodiment, the public key can be stored by the secure transaction servers 4732-4733 and the second associated secret key can be stored in the client's secure storage 4720. Further, in one embodiment (also described below), a key can be generated on the client 4700 (eg, by an authentication device or an authentication device interface rather than a secure transaction server 4732-4733).

  A secure key provisioning protocol, such as Dynamic Symmetric Key Provisioning Protocol (DSKPP), can be used to share keys with clients over a secure communication channel (see, eg, Request for Comments (RFC) 6063). However, the basic principles of the present invention are not limited to any particular key provisioning protocol.

  Referring to the specific details shown in FIG. 49, upon completion of user registration and user authentication, the server 4730 generates a randomly generated challenge (eg, an encrypted nonce) that must be presented by the client during device registration. Random challenges are 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 with server 4730 (eg, an out-of-band transaction) and communicates with server 4730 using a key provisioning protocol. Server 4730 locates users by username, verifies a random challenge, verifies the device's authentication code if one is sent, and creates a new entry in secure transaction database 4720 for the user. It can also generate a key, write the key to database 4720, and send the key back to secure transaction service 4701 using a key provisioning protocol. When complete, the authentication device and server 4730 share the same key if a symmetric key is used, and share a different key if an asymmetric key is used.

  FIG. 50 illustrates a series of transactions for user authentication by a registered authentication device. When device registration is complete, server 4730 accepts the token generated by the local authenticator as a valid authentication token.

  Referring to the specific details shown in FIG. 50 showing a browser-based implementation, the user enters the uniform resource locator (URL) of server 4730 in browser 4704. In implementations that use stand-alone applications or mobile device applications (rather than browsers), the user can enter a network address for the network service or application, and the application will automatically connect to the network service at the network address. It can be.

  For browser-based implementations, the website embeds queries for devices registered in the HTML page. This can be done in many ways other than embedding a query in an HTML page, such as through JavaScript or using an HTTP header. The secure transaction plug-in 4705 receives the URL, searches the secure storage device 4720 (including the authentication device and user information database as described above), and determines whether there is a user registered in this URL. Send it to the secure transaction service 4701 to be determined. If so, the secure transaction service 4701 sends a list of provided devices associated with this URL to the secure transaction plug-in 4705. Then, the secure transaction plug-in calls the registered JavaScript API and passes this information to the server 4730 (for example, a website). Server 4730 selects an appropriate device from the transmitted device list, generates a random challenge, sends device information, and asserts back to the client. The website displays the corresponding user interface and requests authentication from the user. The user then provides the requested authentication means (eg, finger swipe on a fingerprint reader, speech for speech recognition, etc.). The secure transaction service 4701 identifies the user (this step can be omitted for devices that do not support user storage), obtains the username from the database, and generates an authentication token using the key And send this information to the website via a secure transaction plug-in. Server 4730 identifies the user from secure transaction database 4720 and validates the token by generating the same token at server 4730 (eg, using a copy of that key). If verified, the authentication process is complete.

  FIG. 51 illustrates a secure transaction following authentication for a browser-based implementation. Secure transactions are designed to provide strong security for certain types of transactions (eg, financial transactions). In the illustrated embodiment, the user confirms each transaction before delegating the transaction. Using the illustrated technique, the user knows exactly what he / she wants to delegate and delegates exactly what he / she sees what is displayed on the GUI. In other words, this embodiment ensures that the transaction text is not changed by the “middleman” to delegate a transaction that the user did not confirm.

  In one embodiment, secure transaction plug-in 4705 displays window 5101 in the browser context to show transaction details. Secure transaction server 4701 periodically (eg, at random intervals) verifies that the text displayed in the window has not been tampered with by someone.

  The following example serves to highlight the operation of this embodiment. The user selects an item to purchase from the merchant's site and selects “Checkout”. The merchant site sends the transaction to a service provider (eg, PayPal) having secure transaction servers 4732-4733 that implement one or more embodiments of the invention described herein. The merchant site authenticates the user and completes the transaction.

  The secure transaction servers 4732-4733 receive the transaction details (TD), place a “secure transaction” request in the HTML page, and send it to the client 4700. The secure transaction request includes transaction details and a random challenge (eg, random nonce). The secure transaction plug-in 4705 detects a request for a transaction confirmation message and transfers all data to the secure transaction service 4701. In embodiments that do 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.

  For browser-based implementations, the secure transaction plug-in 4705 displays (within the browser context) a window 5101 with transaction details to the user and requests the user to provide authentication 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 displayed to the user. The verification period can be selected randomly. Secure transaction service 4701 ensures that the user sees transaction details valid in window 5101. If it is detected that the content has been tampered with, a confirmation token is prevented from being generated.

After the user provides valid authentication (eg, finger swipe on the fingerprint sensor), the device identifies the user and generates a token (encrypted signature) with transaction details and random challenges (ie, the token is Calculated over transaction details and nonce). This allows the secure transaction servers 4732-4733 to confirm that the transaction details have not changed between the server and the client. The secure transaction service 4701 transmits the generated token and user name to the secure transaction plug-in 4705 that transfers the token to the secure transaction servers 4732 to 4733. The secure transaction servers 4732 to 4733 identify the user by the user name and verify the token. If the verification is successful, a confirmation message is sent to the client and the transaction is processed.
System and method for secure queries Policy for determining client authentication capabilities

  As described above, one embodiment of the present invention implements a query policy in which a secure transaction server sends a server policy to a client that indicates an authentication function accepted by the server. The client then analyzes the server policy to identify a subset of authentication functions that it has supported and / or indicated the desire to use by the user. The client then registers and / or authenticates the user using a subset of the authentication token that matches the provided policy. Thus, the client does not need to send exhaustive information about the authentication function (eg, all of its authenticators) or other information that may be used to uniquely identify the client. , Has a low impact on client privacy.

  By way of example and not limitation, clients may include many such as fingerprint sensors, voice recognition functions, face recognition functions, eye / optical recognition functions, trusted platform modules (TPMs) and smart cards, to name a few. Authentication functions can be included. However, for privacy reasons, the user may not want to reveal all the details of the function to the requesting server. Therefore, using the techniques described herein, a secure transaction server can send a server policy to a client indicating that it supports, for example, fingerprint, optical or smart card authentication. The client can then compare server policies against unique authentication functions and select one or more available authentication options.

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

  The particular implementation shown in FIG. 52 includes a secure transaction plug-in 4705 for establishing communication with a secure enterprise or web destination 4730 (sometimes referred to simply as “server 4730”) using the techniques described above. For example, the secure transaction plug-in can identify a specific HTML tag inserted by the web server 4731 into the HTML code. Therefore, in this embodiment, the server policy is provided to a secure transaction plug-in 4705 that forwards it to a secure transaction service 4701 that implements the policy filter 5201.

  The policy filter 5201 can determine the client authentication function by reading the function from the secure storage area 5220 of the client. As described above, the secure storage device 5220 can include a repository of all client authentication functions (eg, all identification codes of the authentication device). If the user has already registered the user with the authentication device, the user registration data is stored in the secure storage device 5220. If the client has already registered an authentication device with server 4730, the secure storage device can also store an encrypted private key associated with each authentication device.

  Using the authentication data extracted from the secure storage device 5220 and the policy provided by the server, the policy filter 5201 can then identify a subset of authentication functions to be used. Depending on the configuration, the policy filter 5201 can identify a complete list of authentication features supported by both the client and the server, or can identify a subset of the complete 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, the policy filter 5201 includes the entire general authentication function for the server. Can be identified: A, B and C. Alternatively, as shown by user preference 5230 in FIG. 52, if a higher level of privacy is desired, a more limited subset of authentication functions can be identified to the server. For example, the user can indicate that a single common authentication function should only be identified to the server (eg, any of A, B, or C). In one embodiment, the user can establish a prioritization scheme for all of the authentication functions of the client 4700, and the policy filter is the highest priority authentication function common to both the server and the client (or N A set of priorities of individual authentication functions).

  Depending on what action is initiated by the server 4730 (registration or authentication), the secure transaction service 4730 performs that action on the filtered subset of authenticators (4710-4712), as shown in FIG. Then, an operation response is returned to the server 4730 via the secure transaction plug-in 4705. Alternatively, in embodiments that do not rely on the web browser plug-in 4705 component, the information may be sent directly from the secure transaction service 4701 to the server 4730.

  FIG. 53 shows a transaction diagram showing additional details for an exemplary series of registrations with query policy transactions. In the illustrated embodiment, the user has not previously registered the device with the server 4730. Accordingly, at 5301, the user can enter a user name and password as the first one-time authentication step transferred to the server 4730 via the client browser 4704 at 5302. However, it should be noted that a username and password are not required to comply with the basic principles of the present invention.

  Since the user has not previously registered with enhanced security as determined at 5303, server 4730 sends the server policy to the client at 5304. As described above, the server policy can include an indication of an authentication function supported by the server 4730. In the illustrated example, the server policy is passed to secure transaction service 4701 via transaction 5306.

  In transaction 5307, the secure transaction service 4701 may use the client function (and potentially other information such as device priority scheme and / or user preferences as described above) to reach a filtered list of authentication functions. ) And server policy. The filtered list of devices (4702) then generates the keys (5308 and 5309) and then sends these keys to the secure transaction service 4701 which returns them in that order to the server 4730 as registration responses. Provides the public part of. The server authenticates the authentication device and stores the public key in the secure transaction database. The token proof used here is a process of verifying the authentication device identifier during registration. It allows the server to cryptographically verify that the device reported by the client is what was actually claimed.

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

  The above-described technique for filtering server policies at the client can be implemented at various stages of the above-described series of transactions (eg, during device discovery, device registration, device provisioning, user authentication, etc.). That is, the basic principle of the present invention is not limited to the specific set of transactions and the specific transaction order described in FIG.

Furthermore, as mentioned above, a browser plug-in architecture is not required to comply with the basic principles of the present invention. For architectures with browsers or browser plug-ins (eg, stand-alone applications or mobile device applications, etc.), the transaction diagram shown in FIG. 53 (and the rest of the transaction diagram disclosed herein) has browser 4704 deleted. The secure transaction service 4701 can be simplified to communicate directly with the server 4730.
Efficient registration, registration, and registration by multiple authentication devices
And method for authentication and authentication

  One embodiment of the present invention can register, register and authenticate multiple devices simultaneously, thereby improving efficiency and user experience. For example, instead of requiring registration and authentication for a single device at a time, a list of devices can be sent to the client. A symmetric or asymmetric key can then be registered with 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 particular transaction.

  FIG. 54 illustrates one embodiment of a client-server architecture for implementing these techniques. As shown, the secure transaction service 4701 implemented in the client 4700 allows multiple devices at once without requiring continuous round-trip communication with the server 4730 when each device is registered / registered. Includes multi-device processing logic 5401 for performing designated operations such as registration and registration. Similarly, server 4730 includes multiple device processing logic for issuing commands to multiple authentication devices. In one embodiment, multi-device processing logic 5401 is implemented as a software module that executes within the context of secure transaction service 4701. However, the multi-device processing logic 5401 may be implemented in any manner while still complying with the basic principles of the present invention and may include software, hardware or firmware components or any combination thereof. Should be noted.

  As with the embodiments described above, the particular implementation shown in FIG. 54 is for establishing communications with a server 4730 (which may include a web server 4731 and secure transaction servers 4732-4733 as described above). A secure transaction plug-in 4705 is included. Therefore, server 4730 communicates with secure transaction server 4701 via secure transaction plug-in 4705. As mentioned above, however, browser-based plug-in architectures need not adhere to the basic principles of the present invention.

  Multiple device processing logic 5402 at server 4730 can communicate commands executed by multiple device processing logic 5401 at client 4700 executing operations at multiple authentication devices 4710-4712. By way of illustration, the multiple device processing logic 5402 can generate N keys for registration with each of N authentication devices, and then multiple device processing with a command to register the N devices. It can be securely transmitted to the logic 5401. The multiple device processing logic 5401 can then register for all N devices (eg, for authentication devices 4710-4712) simultaneously or in a series of sequential operations without further interaction with the server. A single response can then be sent to server 4730 to indicate registration completion for all N devices.

  An exemplary series of device transactions is shown in FIGS. FIG. 55A illustrates a multi-device registration process that can be performed without any interaction with the server 4730 (eg, registering a user with an authentication device is under the control of the secure transaction service 4701 at the client). Can be done). In an alternative embodiment, the server 4730 can send a request to a client (not shown) to register the user with N devices. FIGS. 55B-C illustrate two different embodiments for registering multiple devices with the server 4730.

  Referring to the registration process in FIG. 55A, at 5501 the user indicates a willingness to register with N authentication devices at the client (representing all or a subset of the available authentication devices). In response, the secure transaction plug-in is invoked at 5502 and at 5503 a device specific graphical user interface (GUI) is generated for the user to walk by processing or registering with authentication device # 1. During the registration process, the user interacts with the secure transaction plug-in as shown (eg by placing a finger on the fingerprint sensor, speaking into the microphone, snapping a photo with the camera, etc.) To do. In one embodiment, at 5504, registration is performed for each of the N devices until registration is completed for the Nth device. Different device-specific scripts and / or user interfaces can be presented to the user to register the user with the individual authentication device. As described above, as a user registers with each device, user registration data can be stored in secure storage device 720 at client 4700 and can only be accessed via secure transaction service 4701. be able to. When registration of all N devices is complete, a notification can be sent to server 4730 via transactions 5504-5505.

  Regardless of how registration is done, upon completion, the transaction diagram shown in FIG. 55B can be used to register N devices with server 4730. At 5510, the server 4730 generates a user-specific random challenge that can be valid only for a time-limited window and can include a randomly generated code, such as an encryption nonce, as described above. . At 5511, a random challenge is sent with a command to register N authentication devices with server 4730. At 5512, secure transaction service 4701 forms a secure connection with server 4730 and sends identification data for N devices along with a random challenge. In one embodiment, the secure connection is an HTTPS connection. However, the basic principle of the present invention is not limited to any particular secure connection type.

  At 5513, server 4730 verifies N devices, generates a key for each of the N devices, and returns the N keys to the secure transaction service over a secure connection. In one embodiment, Dynamic Symmetric Key Provisioning Protocol (DSKPP) is used to exchange keys with clients over a secure connection. However, the basic principles of the present invention are not limited to any particular key provisioning technology. Alternatively, in embodiments that do not rely on the DSKPP protocol, the key may be generated at each authenticator and sent to the server 4730.

  In 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 described above, each key can be stored in the client's secure storage device 720 and associated with that device. When registration is complete for each authenticator, at 5516, a notification is sent to the server over the secure connection.

  In one embodiment, the key registered in each authentication device is a symmetric key. Therefore, the same copy of each key is stored in secure storage 720 at the client and secure transaction database 4720 at server 4730. In an alternative implementation, an asymmetric key pair may be generated, one of which is maintained as a public key in the secure transaction database 4720 at the server and a secret key stored in the client's secure storage 720. However, it should be noted that the basic principles of the present invention are not limited to any particular type of encryption key.

An alternative implementation in which keys are generated at the client rather than the server 4730 is shown in FIG. 55C. In this implementation, after receiving a request to register a device 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 key is registered with each of the N devices at 5513-5514, and the registration is stored in the secure storage device 720 as described above. Once all keys are registered, secure transaction service 4701 provides a notification to the server at 5515 with a random challenge (to verify the client's identity). Server 4730 can then store the registration in secure transaction database 4720 as described above.
System and method for handling random challenges within an authentication framework

  One embodiment of the present invention improves the way in which random challenges are generated and processed by the server. In one embodiment, the random challenge includes a randomly generated code as an encryption nonce. In the current system, after the server sends a random challenge to the client, if the client does not respond within the specified timeout period, the random challenge is no longer valid and the client responds to subsequent authentication attempts. An error is received (eg, the user is rejected by swiping their finger over the fingerprint reader).

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

  FIG. 56A illustrates one such embodiment used within the context of the registration process, and FIG. 56B illustrates an embodiment used within the context of the authentication process. However, it should be noted that the basic principles of the present invention may be used in contexts other than those shown in FIGS. For example, the techniques described herein can be used in any process in which time sensitive code is communicated from a server to a client.

  Referring initially to FIG. 56A, at 5601, server 4730 generates an indication of a random challenge and timeout period. In one embodiment, the timeout period includes a period during which a random challenge is considered valid. After the timeout period elapses, the random challenge is no longer considered valid by the server 4730. In one embodiment, the timeout period is simply specified as the point at which the random challenge is no longer valid. When this point is reached, the random challenge is invalid. In other embodiments, the timeout period is specified using the current timestamp (ie, the time that the random challenge was generated by server 4730) and duration. The secure transaction service 4701 can then calculate a timeout period by adding a duration value to the timestamp to calculate when the random challenge becomes invalid. However, it should be noted that the basic principles of the present invention are not limited to any particular technique for calculating the timeout period.

  Regardless of how the timeout period is specified or calculated, at 5602, a random challenge and timeout indication is sent to the secure transaction service 4701 (via the browser 4704 and secure transaction plug-in 4705 in the illustrated example). The At 5603, the secure transaction service 4701 detects that the random challenge has timed out and is no longer valid based on the time-out indication sent from the server 4730. Illustratively, the user can turn off his / her client device or close the lid of his / her notebook computer before completing a series of transactions. If the transaction requires user interaction, the user can simply walk away or ignore the message displayed in the GUI.

  Upon detecting at 5604 that the random challenge is no longer valid, secure transaction service 4701 requests server 4730 to request a new random challenge (via secure transaction plug-in 4705 and browser 4704 in the illustrated example). Send. At 5605, server 4730 generates a new random challenge and a new timeout period indication. In one embodiment, the timeout period can be the same as or changed from operation 5601. For example, the server 4730 can increase the duration of the timeout period to reduce time to reduce data traffic by the client or to increase the level of security provided by a random challenge. At 5606, a new random challenge and timeout indication is sent to the secure transaction service 4701.

  The rest of the transaction occurs as described above. For example, the secure transaction service opens a secure connection directly to the server at 5607 to perform device registration and key exchange as described above with respect to FIG. 49, FIG. 55B or FIG. 55C. At 5608, the server 4730 identifies the user (eg, by username or other ID), proves the authentication device, and generates a key for the device. As described above, the key can be a symmetric key or an asymmetric key. At 5609, the key is transmitted to the secure transaction service 4701 via the secure connection, and at 5610, the secure transaction service 4701 registers the key with the authentication device. At 5611, a notification that registration is complete is sent to server 4730.

  Therefore, in the embodiment shown in FIG. 56A, the key used for device registration is generated at server 4730 as in the embodiment shown in FIG. 55B. However, the basic principles of the present invention can also be used in embodiments where keys are generated by a secure transaction service 4701 at client 4700, as described above with respect to FIG. 55C.

  FIG. 56B illustrates one embodiment of the present invention implemented in the context of an authentication process. At 5651, the user enters the URL of a particular website in browser 4704 and is directed to web server 4731 in enterprise / web destination server 4730 including secure transaction servers 4732-4733. At 5562, the query is sent back to the secure transaction service (via a browser and plug-in) to determine the device registered in the website URL. Secure transaction service 4701 queries secure storage device 720 at client 4700 to identify a list of devices that are returned to server 4730 at 5653. At 5654, server 5654 selects the device to use for authentication, generates a random challenge and timeout indication, and returns the information to secure transaction service 4701 at 5655.

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

The rest of the transaction diagram shown in FIG. 56B operates substantially similar to the method described above (see, eg, FIG. 50). For example, at 5660, an authentication user interface is displayed (eg, guiding the user to swipe a finger over the fingerprint sensor), and at 5661, the user provides authentication (eg, swiping a finger over the fingerprint scanner). ). At 5562, the secure transaction service verifies the user's identity (eg, compares the authentication data collected from the user with what is stored in the secure storage device 720) and authenticates the authenticator to encrypt the random challenge. Use the associated key. At 5663, the username (or other ID code) and encrypted random challenge are sent to server 4730. Finally, at 5664, server 4730 uses the username (or other ID code) to identify the user in secure transaction database 4720 and is stored in secure transaction database 4720 to complete the authentication process. Decrypt / verify random challenge using key.
System and method for implementing a privacy class in an authentication framework

  In one embodiment, multiple classes of privacy protection can be predefined, selected and / or changed by the end user. A privacy class can be defined based on the probability that a client can be identified using leaked information. In privacy classes that have a relatively high privacy level, relatively little information about the client device is published to implement the authentication techniques described herein. In one embodiment, the user can choose to disclose the minimum amount of information possible when communicating with different servers (ie, have the lowest acceptable privacy that affects each website or network service) Transaction can be selected).

  FIG. 57 illustrates a high level architecture for implementing privacy classes. As shown in the figure, the secure transaction service 4701 of the present embodiment analyzes a query received from the server 4730 for client information such as information related to the authentication device, and executes a privacy policy in response to such a query. Privacy management logic 5701 for generating a response including client information collected based on the particular privacy class in use. In one embodiment, privacy management module 5701 is implemented as a software module that runs within the context of secure transaction service 4701. However, it should be noted that while still complying with the basic principles of the present invention, the privacy management module 5701 may be implemented in any manner and may include software, hardware, firmware, or any combination thereof. It is.

  The privacy class utilized by the privacy management logic 5701 can be pre-specified and stored at the client 4700 (eg, stored in the secure storage device 5720). In one embodiment, three privacy classes are defined: high privacy impact, intermediate privacy impact and low privacy impact. Each privacy class can be defined based on the probability that leaked information could be used to uniquely identify the user / client. For example, leaked information about a low privacy impact transaction can result in a 10% probability of a user or device uniquely identified on the Internet, and an intermediate privacy impact transaction may result in 50% of uniquely identified users or devices. A high privacy impact transaction can result in a 100% probability of a uniquely identified user or device. In addition, various other classes of privacy levels can be defined while adhering to the basic principles of the present invention.

  In one embodiment, each trusted party (eg, each website 4731 or service 4751) can specify a required privacy class or other privacy threshold. For example, websites and services that require an increased level of security can only be allowed to communicate according to a high privacy impact class, whereas other websites / services Interaction can be allowed using an intermediate privacy impact or low privacy impact class. In one embodiment, the client information query sent from the server 4730 includes an attribute that specifies the privacy class of information to be obtained (ie, low, medium, high). Therefore, the privacy management logic 5701 stores the highest approved privacy class information for each trusted party. In one embodiment, each time a trusted party requests information belonging to a higher privacy class than one already approved, the user permanently approves this new privacy class for this trusted party (or You will be asked to refuse. In response to the user's approval, the privacy management logic can store a new association between the trusted party (e.g., identified via a URL) and the new privacy class.

  Note that user preferences 5730 have been applied directly to the privacy management logic in FIG. 57 for simplicity, but the user can specify preferences via a browser-based graphical user interface (not shown). Should. In such cases, the user enters privacy settings via the browser window. The secure transaction plug-in 4705 then stores the new settings for the privacy management logic 5701 or for the settings data file accessible by the privacy management logic 5701. In short, the basic principles of the present invention are not limited to a particular mechanism for constructing privacy management logic.

  Various types of client data include, for example, device model identifiers, client software information, client functions, and various levels of information associated with each authentication device configured on the client device (eg, device ID code, vendor ID code, It can be specified at various privacy class levels including device class ID). Different combinations of this information may be collected to determine specific percentages in defining different privacy classes.

FIG. 58 illustrates a series of transactions for providing information to a requester using a defined privacy class. At 5801, the server 4730 generates a notification that includes a query for client device information. At 5802, the query is sent to the client and finally received by secure transaction service 4701. At 5803, the privacy management logic of the secure transaction service determines the privacy class for the response and collects the necessary information. As described above, N different privacy class levels can be defined, and the secure transaction service 4701 can select the one that meets the requirements of the requester while simultaneously leaking as little information about the client as possible. . At 5804, the collected information is sent to server 4730, where the server uses the information for one or more subsequent transactions by the client.
System and method for executing an authentication framework using transaction signatures

  One embodiment of the present invention uses a transaction signature at the secure transaction server so that no transaction state needs to be maintained at the server to maintain a session with the client. In particular, transaction details such as transaction text can be sent to the client signed by the server. The server can then verify that the signed transaction response received by the client is valid by verifying the signature. The server does not need to persistently store transaction content, consumes a significant amount of storage space for many clients, and opens the possibility of denying service type attacks on the server.

  One embodiment of the present invention showing a website or other network service (5901) initiating a transaction with a client 4700 is shown in FIG. For example, the user may have selected an item for purchase on a website and is ready to check out and pay. In the illustrated example, the website or service 5901 includes a signature processing logic 5903 for generating and verifying a signature (described herein) and a client (eg, using the authentication techniques described above). The transaction is handed off to a secure transaction server 5902 including authentication logic for executing authentication 5904.

  In one embodiment, the authentication request sent from the secure transaction server 5902 to the client 4700 is presented with a random challenge such as an encryption nonce (as described above) and transaction details (eg, to complete the transaction). Specific signature) and a signature generated by the signature processing logic 5903 via a random challenge and transaction details using a secret key (known only by the secure transaction server).

  When the information is received by the client, the user can receive an indication that authentication is required to complete the transaction. In response, the user can, for example, swipe a finger across the fingerprint scanner, snap an image, speak to a microphone, or perform other types of authentication allowed for a given transaction. In one embodiment, if the user is successfully authenticated to client 4700, the client returns the following to the server: (1) Random challenge and transaction text (both previously provided to the client by the server) (2) authentication data proving that the user has successfully completed authentication, and (3) a signature.

The authentication module 5904 in the secure transaction server 5902 can then confirm that the user has been correctly authenticated, and the signature processing logic 5903 regenerates the signature over the random challenge and transaction text using the private key. . If the signature matches that sent from the client, the server can verify that the text of the transaction is the same as it was received from the website or service 5901. Because the secure transaction server 5902 is not required to persistently store transaction text (or other transaction data) in the secure transaction database 4720, storage and processing resources are preserved.
Exemplary data processing apparatus

  FIG. 60 is a block diagram illustrating an exemplary client and server that may be used in some embodiments of the present invention. Although FIG. 60 illustrates various components of a computer system, such details are not relevant to the present invention and are intended to represent any particular architecture or method of interconnecting components. It should be understood that this is not the case. It will be appreciated that other computer systems having fewer components or multiple components may also be used with the present invention.

  As shown in FIG. 60, a computer system 6000 in the form of a data processing system includes a bus 6050 coupled to the processing system 6020, a power supply 6025, memory 6030, and non-volatile memory 6040 (eg, hard drive, Flash memory, phase change memory (PCM), etc.). The buses 6050 can be connected to each other through various bridges, controllers and / or adapters as is well known in the art. The processing system 6020 can obtain instructions from the memory 6030 and / or the non-volatile memory 6040 and can execute instructions for performing operations as described above. The bus 6050 interconnects the above components together, and also includes an optional dock 6060, display controller and display device 6070, input / output device 6080 (eg, NIC (network interface card), cursor control (eg, mouse, The components are interconnected to a touch screen, touchpad, etc.), keyboard, etc.) and any wireless transceiver 6090 (eg, Bluetooth, WiFi, infrared, etc.).

  FIG. 61 is a block diagram illustrating an exemplary data processing system that may be used in some embodiments of the present invention. For example, the data processing system 6100 can include a handheld computer, personal digital assistant (PDA), mobile phone, portable game system, portable media player, tablet, or handheld computer that can include a mobile phone, media player and / or game system. It can be used as a storage device. As another example, data processing system 6100 may be an embedded processing device within a network computer or other device.

  According to one embodiment of the present invention, the exemplary architecture of data processing system 6100 can be used for the mobile devices described above. Data processing system 6100 includes a processing system 6120 that can include one or more microprocessors and / or systems on an integrated circuit. Processing system 6120 is coupled to memory 6110, power supply 6125 (including one or more batteries), audio input / output 6140, display controller and display device 6160, optional input / output 6150, input device 6170, and wireless transceiver 6130. Has been. Additional components not shown in FIG. 61 may also be part of data processing system 6100 in certain embodiments of the present invention, than shown in FIG. 61 in certain embodiments of the present invention. It will be appreciated that fewer components can be used. Further, it will be appreciated that one or more buses not shown in FIG. 61 can be used to interconnect various components as is well known in the art.

  Memory 6110 stores data and / or programs for execution by data processing system 6100. Audio input / output 6140 can include, for example, a microphone and / or speaker to play music and / or provide telephone functionality via the speaker and microphone. The display controller and display device 6160 may include a graphical user interface (GUI). A wireless (eg, RF) transceiver 6130 (eg, a WiFi transceiver, an infrared transceiver, a Bluetooth transceiver, a wireless cell phone transceiver, etc.) can be used to communicate with other data processing systems. One or more input devices 6170 allow a user to provide input to the system. These input devices can be keypads, keyboards, touch panels, multi-touch panels, and the like. Any other input / output 6150 may be a docking connector.

  As described above, embodiments of the present invention may include various steps. A step may be embodied in machine-executable instructions that cause a general purpose or special purpose processor to perform a certain step. Alternatively, these steps can be performed by specific hardware components including hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

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

  Throughout the foregoing description, for the purposes of explanation, numerous specific details have been set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without some of these specific details. For example, it will be readily apparent to those skilled in the art that the functional modules and methods described herein may be implemented as software, hardware, or any combination thereof. Furthermore, although some embodiments of the invention are described herein in the context of a mobile computing environment, the basic principles of the invention are not limited to mobile computing implementations. Virtually any type of client or peer data processing device can be used in some embodiments including, for example, a desktop or workstation computer. Accordingly, the scope and spirit of the invention should be determined in terms of the following claims.

  As described above, embodiments of the present invention may include various steps. A step may be embodied in machine-executable instructions that cause a general purpose or special purpose processor to perform a certain step. Alternatively, these steps can be performed by specific hardware components including hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

Claims (12)

A device,
An authentication unit for authenticating a trusted party and a user of the device, the authentication unit including a plurality of authentication factors;
An apparatus comprising: a model for one or more of the other authentication factors and / or factor authentication logic for proving the integrity of at least one authentication factor before allowing to form the authenticator. A method,
Entering a valid user state at the client device for a period following explicit authentication by the end user;
Recording reference data relating to user behavior while in the legitimate user state;
Measuring user behavior outside the legitimate user state and reaching an authentication assurance level based on a distance between the measured user behavior and the recorded reference data;
Providing an authentication assurance level sufficient to authenticate a user to a trusted party at an authentication assurance level at or exceeding a defined threshold in response to an authentication request within the legitimate user state; ,
Providing an authentication assurance level based on a distance between the measured user behavior and the recorded reference data in response to an authentication request outside the legitimate user state. A method,
Receiving a client request to perform a transaction requiring authentication;
Analyzing first data associated with the client to determine a risk value associated with the client;
Determining the level of assurance necessary to allow the client to complete the transaction;
Determining a guarantee level gain necessary to reach the guarantee level based on the risk value;
Selecting one or more authentication techniques based at least in part on the indication of the assurance level gain. A location recognition method for user authentication,
Determining the current location of the mobile device;
Identifying a location class corresponding to the current location;
Define a set of one or more authentication techniques to provide a sufficient level of user authentication for the current transaction based on the identified location class, an authentication policy associated with a particular trusted party Receiving an authentication policy to
Selecting from the set of one or more authentication techniques to authenticate a user for the current transaction based on the identified location class. A method for authenticating a user, comprising:
Collecting environmental sensor data from one or more sensors of the client device;
Using the geographic location reported by the device to collect location supplemental data;
Comparing the supplemental data and the environmental sensor data to reach a correlation score;
Responsively selecting one or more authentication techniques for authenticating a user of the client device based on a correlation score based on an authentication policy associated with a trusted party. A method,
Receiving a request to authenticate the user;
Presenting one or more screen layouts to the user;
Capturing a sequence of images including the user's eyes when the one or more screen layouts are displayed;
(A) Correlation between the user's eye movement when the one or more screen layouts are presented and the predicted user eye movement when the one or more screen layouts are presented Eye movement detection over the sequence of images to identify and / or (b) the eye to identify the correlation between the effective light intensity of the screen and the effect on the pupil size of the user's eye Measuring the pupil size. A method,
Evaluating client configuration data to determine a risk level associated with the client device;
Authenticating a particular transaction in response to the risk level. A method,
Receiving a request from a client device to execute a transaction at a local transaction device;
Performing one or more authentication transactions including receiving biometric input from a user at the client device to generate an authentication result;
Sending the authentication result to the remote secure transaction service;
A remote secure transaction service sending a signal to a local transaction device to perform one or more operations if the authentication result is sufficient to complete the transaction. A method for user authentication comprising:
Detecting a user of a client attempting to perform a current interaction with a trusted party,
A set of one or more authentication rules associated with the first interaction class, responsively identifying a first interaction class for the current interaction based on a variable associated with the current interaction; Implementing the method. A method for user authentication comprising:
One or more authentication techniques for detecting a transaction triggered by a first user over a network at a trusted party and authenticating the first user to the trusted party over the network Running,
One or more other users registered with the trusted party that are required to confirm the transaction before allowing the transaction to be executed Identifying
Sending a notification to the subset indicating that the one or more other users or their transactions were triggered by the first user;
The one or more other users or subsets confirming the transaction by performing remote authentication to the trusted party over the network. A method for delegating trust,
A series of trust delegations to transfer registration data associated with one or more trusted authenticators in a trusted client device to one or more new authenticators in a new client device or trusted client device Performing the operation. A method for establishing trust between two or more devices, comprising:
Transmitting first data including at least one key and an identification code identifying a trust circle including the first device from the first device to the second device via a secure communication channel;
A second device generates second data using at least a portion of the first data including the identification code, and transmits the second data over a network to a service;
A first device uses the identification code to identify the second data, connects to the service, verifies the integrity of the second data, and generates third data in response. And
And wherein the service comprises storing at least a portion of the second data and the third data to establish a trust relationship between the first device and the second device.

Images