HK1236663B - System and method for performing authentication using data analytics - Google Patents

Description

Systems and methods for performing validation using data analysis

Background Art

Technical Field

The present invention generally relates to the field of data processing systems. More particularly, the present invention relates to systems and methods for performing validation using data analytics such as machine learning.

Description of related fields

Systems that use biometric sensors to provide secure user authentication over a network have also been designed. In such systems, a score and/or other authentication data generated by an authenticator can be sent over the network to authenticate the user to a remote server. For example, Patent Application No. 2011/0082801 (“the '801 Application”) describes a framework for user registration and authentication over a network that provides strong authentication (e.g., protection against identity theft and phishing), secure transactions (e.g., protection against “in-browser malware” and “man-in-the-middle” attacks during transactions), and registration/management of client authentication tokens (e.g., fingerprint readers, facial recognition devices, smart cards, trusted platform modules, etc.).

The assignee of the present application has developed various improvements to the authentication framework described in the '801 application. Some of these improvements are described in the following group of U.S. patent applications, all of which are assigned to the present assignee: Serial No. 13/730,761, entitled “Query System and Method to Determine Authentication Capabilities”; Serial No. 13/730,776, entitled “System and Method for Efficiently Enrolling, Registering, and Authenticating With Multiple Authentication Devices”; Serial No. 13/730,780, entitled “System and Method for Processing Random Challenges Within an Authentication Framework”; Serial No. 13/730,791, entitled “System and Method for Implementing Privacy Classes Within an Authentication Framework”; Serial No. 13/730,795, entitled “System and Method for Implementing Transaction Signaling Within an Authentication Framework” (Systems and Methods for Implementing Transaction Signaling within an Authentication Framework); and Serial No. 14/218,504, entitled “Advanced Authentication Techniques and Applications” (hereinafter referred to as the “‘504 Application”). These applications are sometimes referred to herein as (the “Co-Pending Applications”).

In short, in the authentication technology described in these co-pending applications, a user registers with an authentication device (or authenticator), such as a biometric device (e.g., a fingerprint sensor), on a client device. When a user registers with the biometric device, biometric reference data is captured (e.g., by swiping a finger, taking a photo, recording a voice, etc.). The user can then register/pre-install the authentication device with one or more servers (e.g., websites or other relying parties equipped with secure transaction services, as described in the co-pending applications) via a network; and then authenticate with those servers using the data exchanged during the registration process (e.g., a key pre-installed in the authentication device). Once authenticated, the user is permitted to perform one or more online transactions with the website or other relying party. In the framework described in the co-pending applications, sensitive information (such as fingerprint data and other data that can be used to uniquely identify the user) can be stored locally on the user's authentication device to protect the user's privacy.

The '504 application describes a variety of additional techniques, including the following: designing composite authenticators, intelligently generating authentication assurance levels, using non-intrusive user verification, transmitting authentication data to new authentication devices, augmenting authentication data with client risk data, adaptively applying authentication policies, and creating circles of trust, among other techniques.

BRIEF DESCRIPTION OF THE DRAWINGS

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

1A-1B illustrate two different embodiments of a security verification system architecture;

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

FIG3 shows a transaction diagram illustrating remote authentication;

4A-4B illustrate various embodiments of systems for performing verification using machine learning techniques;

FIG5 illustrates one embodiment of a method for performing verification using machine learning techniques;

FIG6 illustrates another embodiment of a method for performing verification using machine learning techniques;

FIG7 illustrates one embodiment of a computer architecture for a server and/or client; and

FIG8 illustrates one embodiment of a computer architecture for a server and/or client.

DETAILED DESCRIPTION

The following describes embodiments of devices, methods, and machine-readable media for implementing advanced authentication techniques and associated applications. Throughout the description, for purposes of explanation, numerous specific details are set forth herein to provide a thorough understanding of the present invention. However, those skilled in the art will readily appreciate that the present invention can be practiced without some of these specific details. In other instances, well-known structures and devices are not shown or are shown in block diagram form to avoid obscuring the underlying principles of the present invention.

The embodiments of the present invention discussed below relate to authentication devices with user verification capabilities (such as biometric forms or PIN entry). These devices are sometimes referred to herein as "tokens," "authentication devices," or "authenticators." Although some embodiments focus on facial recognition hardware/software (e.g., a camera and associated software for recognizing a user's face and tracking the user's eye movements), some embodiments may utilize additional biometric devices, including, for example, fingerprint sensors, voice recognition hardware/software (e.g., a microphone and associated software for recognizing a user's voice), and optical recognition capabilities (e.g., an optical scanner and associated software for scanning a user's retina). User authentication capabilities may also include non-biometric forms, such as PIN entry. Authenticators may use devices such as Trusted Platform Modules (TPMs), smart cards, and secure elements to perform cryptographic operations and key storage.

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

As used herein, the term "local" refers to the fact that a user is conducting a transaction in person at a specific location, such as at an automated teller machine (ATM) or a point-of-sale (POS) retail checkout. However, as discussed below, the authentication techniques used to authenticate a user may involve non-location components, such as communication with a remote server and/or other data processing device via a network. Furthermore, while specific embodiments (such as ATMs and retail points of sale) are described herein, it should be noted that the underlying principles of the present invention may be implemented in the context of any system in which a transaction is initiated locally by an end user.

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

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

Exemplary System Architecture and Transactions

Figures 1A to 1B show two embodiments of a system architecture including client-side components and server-side components for registering an authentication device (sometimes also referred to as "pre-set") and authenticating a user. The embodiment shown in Figure 1A uses a web browser plug-in-based architecture to communicate with a website, while the embodiment shown in Figure 1B does not require a web browser. The various techniques described herein, such as registering a user with an authentication device, registering an authentication device with a secure server, and verifying a user, can be implemented on any of these system architectures. Therefore, although the architecture shown in Figure 1A is used to demonstrate the operation of several of the embodiments described below, the same basic principles can be easily implemented on the system shown in Figure 1B (for example, by removing the secure transaction plug-in 105, which acts as an intermediary for communicating between a secure enterprise or web destination 130 and the secure transaction service 101 on the client).

Turning first to FIG1A , the illustrated embodiment includes a client 100 equipped with one or more authentication devices 110 to 112 (these authentication devices are sometimes referred to in the art as authentication “tokens” or “authenticators”) for enrolling and verifying end users. As described above, the authentication devices 110 to 112 may include biometric devices such as fingerprint sensors, voice recognition hardware/software (e.g., a microphone and associated software for recognizing a user's voice), facial recognition hardware/software (e.g., a camera and associated software for recognizing a user's face), and optical recognition capabilities (e.g., an optical scanner and associated software for scanning a user's retina), and support non-biometric modalities (such as PIN verification). The authentication device may use a trusted platform module (TPM), a smart card, or a secure element for cryptographic operations and key storage.

Authentication devices 110 to 112 are communicatively coupled to the client via an interface 102 (e.g., an application programming interface or API) exposed by a secure transaction service 101. The secure transaction service 101 is a secure application for communicating with one or more secure transaction servers 132 to 133 via a network and for interfacing with a secure transaction plug-in 105 executed within the environment of a web browser 104. As shown, the interface 102 may also provide secure access to a secure storage device 120 on the client 100, which stores information related to each authentication device 110 to 112, such as a device identification code, a user identification code, user registration data protected by the authentication device (e.g., a scanned fingerprint or other biometric data), and a key encapsulated by the authentication device for performing the secure authentication techniques described herein. For example, as discussed in detail below, a unique key may be stored in each authentication device and used when communicating with a secure enterprise or web destination 130 via a network (such as the Internet).

As discussed below, the secure transaction plugin 105 supports certain types of network transactions, such as HTTP or HTTPS transactions with a website 131 or other server. In one embodiment, the secure transaction plugin is activated in response to a specific HTML tag inserted into the HTML code of a web page of a website 131 within a secure enterprise or web destination 130. In response to detecting such a tag, the secure transaction plugin 105 may forward the transaction to the secure transaction service 101 for processing. In addition, for certain types of transactions (e.g., such as secure key exchanges), the secure transaction service 101 may open a direct communication channel with a local transaction server 132 (i.e., co-located with the website) or an off-site transaction server 133.

Secure transaction servers 132-133 are coupled to secure transaction database 121, which is used to store user data, authentication device data, cryptographic keys, and other security information required to support secure authentication transactions as described below. However, it should be noted that the underlying principles of the present invention do not require the separation of logical components within the secure enterprise or web destination 130 shown in FIG1A . For example, website 131 and secure transaction servers 132-133 may be implemented within a single physical server or multiple separate physical servers. Furthermore, website 131 and transaction servers 132-133 may be implemented within integrated software modules executed on one or more servers for performing the functions described below.

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

In either embodiment shown in Figures 1A and 1B, the secure transaction servers 132-133 may generate keys that are then securely transmitted to the secure transaction service 101 and stored in a verification device within the secure storage device 120. In addition, the secure transaction servers 132-133 manage the secure transaction database 121 on the server side.

Certain basic principles associated with remote registration of an authentication device and authentication with a relying party will be described in conjunction with Figures 2-3, followed by a detailed description of an embodiment of the present invention for performing authentication using machine learning techniques.

FIG2 illustrates a series of transactions for registering an authentication device on a client, such as devices 110 to 112 on client 100 in FIG1A to FIG1B (sometimes referred to as a “pre-installed” authentication device). In simplified terms, secure transaction service 101 and interface 102 are collectively referred to as authentication client 201, and secure enterprise or web destination 130, including secure transaction servers 132 to 133, is represented as relying party 202.

During registration of an authenticator (e.g., a fingerprint authenticator, a voice authenticator, etc.), a key associated with the authenticator is shared between the authenticating client 201 and the relying party 202. Referring again to Figures 1A-1B, the key may be stored in the secure storage 120 of the client 100 and in the secure transaction database 121 used by the secure transaction servers 132-133. In one embodiment, the key is a symmetric key generated by one of the secure transaction servers 132-133. However, in another embodiment discussed below, an asymmetric key is used. In this embodiment, a public/private key pair may be generated by the secure transaction server 132-133. The public key may then be stored by the secure transaction server 132-133, and the associated private key may be stored in the secure storage 120 on the client. In an alternative embodiment, the key may be generated on the client 100 (e.g., by the authenticating device or authenticating device interface rather than by the secure transaction server 132-133). The underlying principles of the present invention are not limited to any particular type of key or method of generating the key.

In one embodiment, a secure key provisioning protocol is employed to share a key with the client via a secure communication channel. An example of a key provisioning protocol is the Dynamic Symmetric Key Provisioning Protocol (DSKPP) (e.g., see Request for Comments (RFC) 6063). However, the underlying principles of the present invention are not limited to any particular key provisioning protocol. In a specific embodiment, the client generates a public/private key pair and sends the public key to the server, which can be authenticated using a authentication key.

Turning to the specific details shown in Figure 2, to initiate the registration process, relying party 202 generates a randomly generated challenge (e.g., a cryptographic random number), which verification client 201 must present during device registration. This random challenge may be valid for a limited time period. In response, verification client 201 initiates an out-of-band secure connection (e.g., an out-of-band transaction) with relying party 202 and communicates with relying party 202 using a key provisioning protocol (e.g., the DSKPP protocol mentioned above). To initiate the secure connection, verification client 201 may provide the random challenge back to relying party 202 (possibly along with a signature generated on the random challenge). In addition, verification client 201 may transmit the identity of the user (e.g., a user ID or other code) and the identity of the verification device to be provisioned (e.g., using an authentication authentication ID (AAID) that uniquely identifies the type of verification device being provisioned).

The relying party locates the user using the username or ID code (e.g., in a user account database), verifies the random challenge (e.g., using a signature or simply comparing the random challenge to the random challenge sent), verifies the verification code of the authentication device if one has already been sent (e.g., AAID), and creates a new entry for the user and authentication device in a secure transaction database (e.g., database 121 in Figures 1A to 1B). In one embodiment, the relying party maintains a database of authentication devices that it accepts for authentication. It can query this database using the AAID (or other authentication device code) to determine whether the authentication device being provisioned is acceptable for authentication. If so, it will continue with the registration process.

In one embodiment, relying party 202 generates a verification key for each verification device being preset. It writes the key into a secure database and uses a key pre-setting protocol to send the key back to verification client 201. Once completed, the verification device and relying party 202 share the same key when using a symmetric key, or share different keys when using an asymmetric key. For example, if an asymmetric key is used, relying party 202 can store a public key and provide a private key to verification client 201. After receiving the private key from relying party 202, verification client 201 presets the key into the verification device (storing it in a secure storage device associated with the verification device). It can then use the key during the user's verification (as described below). In an alternative embodiment, a key is generated by verification client 201 and a key pre-setting protocol is used to provide the key to relying party 202. In either case, once the pre-setting is completed, verification client 201 and relying party 202 each have a key, and verification client 201 notifies the relying party of the completion.

Figure 3 shows a series of transactions for verifying a user to a preset verification device. Once device registration is complete (as described in Figure 2), relying party 202 will accept the verification response (sometimes referred to as a "token") generated by the local verification device on the client as a valid verification response.

Turning to the specific details shown in Figure 3, in response to a user initiating a transaction with a relying party 202 that requires verification (e.g., initiating a payment from a relying party's website, accessing private user account data, etc.), the relying party 202 generates a verification request including a random challenge (e.g., a cryptographic random number). In one embodiment, the random challenge has a time limit associated with it (e.g., it is valid for a specified time period). The relying party can also identify the authenticator to be used for verification by the verification client 201. As described above, the relying party can preset each verification device available on the client and store the public key for each preset authenticator. Therefore, it can use the public key of the authenticator or can use the authenticator ID (e.g., AAID) to identify the authenticator to be used. Alternatively, it can provide the client with a list of verification options from which the user can choose.

In response to receiving the verification request, a graphical user interface (GUI) requesting verification may be presented to the user (e.g., in the form of a web page or verification application/application's GUI). The user then performs verification (e.g., swiping a finger across a fingerprint reader, etc.). In response, the verification client 201 generates a verification response containing a signature over the random challenge and a private key associated with the authenticator. It may also include other relevant data in the verification response, such as a user ID code.

After receiving the verification response, the relying party can verify the signature above the random challenge (e.g., using the public key associated with the authenticator) and confirm the user's identity. Once verification is complete, the user is allowed to enter into a secure transaction with the relying party, as shown in the figure.

A secure communication protocol such as Transport Layer Security (TLS) or Secure Sockets Layer (SSL) may be used to establish a secure connection between relying party 202 and verification client 201 for any or all of the transactions shown in Figures 2-3.

Systems and methods for performing validation using data analysis

Embodiments of the present invention include techniques for detecting distinct behavioral patterns of users and devices by examining authentication-related data at a larger scale, and using these patterns to adjust the authentication risk of transactions. Traditional authentication systems analyze a single data signal from a user or device, such as a password or encrypted response, and make final authentication decisions based on this signal. In contrast, the embodiments of the present invention described below perform larger-scale analysis based on a variety of different signals and data associated with user authentication, thereby identifying patterns of interest related to the current transaction that cannot be detected by traditional systems.

As mentioned, traditional authentication systems are based on a single source of authentication data, such as a user password and an authentication key. The server typically stores the user's authentication data in the user's record and expects to receive the appropriate authentication data during each authentication event. The server performs a binary check—that is, if the authentication data is verified successfully, the user is authenticated; if it fails, the user is not authenticated. Thousands of websites today employ this approach.

Even in next-generation authentication protocols that allow users to authenticate to a server using a biometric authenticator on a client device, the underlying authentication method is based on a binary verification—that is, verification of a cryptographic signature provided by the authenticator. While the client device can provide multiple cryptographic signatures, the server simply verifies these and makes a binary decision of success or failure.

A drawback of these systems is their vulnerability to advanced attacks. As long as the verification data provided passes server-side validation, verification is considered successful. However, if the client-side authenticator is compromised and an attacker is able to generate valid verification data, these systems can be compromised. Without more advanced analysis by viewing the data at a larger scale, it is difficult to detect such attacks and respond appropriately.

The system used by the client-side authenticator to authenticate the user to the authentication server (such as described above in conjunction with Figures 1A to 1B, Figures 2 and 3) has access to data points of interest that can be further analyzed to determine patterns of interest. The more data such a system collects, the richer the analysis will be. The analysis can be performed before, during and/or after authentication. For example, in one embodiment, the authentication server can review all previous authentication attempts for a particular user and determine whether the current authentication operation fits into a larger pattern that is typical for that user. If it deviates from that typical pattern, the current operation is less typical and therefore less trusted/risky. Conversely, if the current authentication operation fits into a previous pattern, the system can decide not to cover the user and not require additional authentication or to utilize less invasive authentication techniques.

Figure 4A illustrates one embodiment of the present invention, wherein logic for performing data analysis based on current parameters to determine a risk level and select an authentication technique is executed on an authentication server 450. Figure 4B illustrates another embodiment, wherein the logic is implemented on a client device 400. Regardless of whether the analysis is performed on the server or client side, the underlying principles of the present invention remain the same.

4A , an exemplary client device 400 includes an authentication client 410 for authenticating a user using one or more explicit user authentication devices 420-421 and/or non-intrusive authentication techniques 405. Explicit user authentication devices 420-421 represent any form of authentication requiring explicit user input, such as a fingerprint authenticator, voice or facial recognition, a retinal scan, or a keyboard (virtual or physical) on which a user can enter an encrypted password such as a PIN.

Non-intrusive authentication techniques 405 may be used to collect relevant data for determining the likelihood that a legitimate user is in possession of client device 400. By way of example and not limitation, non-intrusive authentication techniques 405 may include determining the user's current location (e.g., via GPS or other positioning mechanisms) and comparing the current location to locations known to be visited by the end user (e.g., the user's "home" and "work" locations). For example, if the current location of client device 400 is the user's workplace, this may be used by authentication client 410 in determining whether explicit user authentication (e.g., via one of authentication devices 420-421) is required and/or the level of explicit user authentication.

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

Other non-invasive authentication techniques 405 may include collecting data from sensors on the client device 400, such as accelerometers. For example, a user's biometric gait may be measured using an accelerometer or other type of sensor and software and/or hardware designed to generate a gait "fingerprint" of the user's normal walking pattern. In addition, current temperature, humidity, pressure, and other environmental data may be collected and compared with known environmental data for the claimed current location of the client device 400 (e.g., to determine whether the current environmental reading matches the current claimed location). Additionally, non-invasive authentication techniques may include measuring the time since the last successful explicit authentication using the devices 420 to 421. The shorter the time, the more likely the current user is the legitimate user of the client device. These and other types of data may be collected and analyzed to determine the likelihood that the current user is the legitimate user of the client device 400 (and thus the extent to which explicit user authentication is required).

As described above, secure storage 425 may be used to store verification keys associated with each of verification devices 420 through 421. The verification keys may be used to sign and encrypt communications with relying party 450 via a secure communication channel.

In one embodiment, current parameters 406 are collected from client device 400 by a risk analysis module 411 executed on a relying party verification server 450. A number of exemplary parameters are shown below. Risk analysis module 411 may then compare current parameters 406 with historical parameters and thresholds 430 maintained in a storage device on verification server 450 to determine a risk level 407 for the current transaction. In one embodiment, risk level 407 represents the degree to which current parameters 406 deviate from historical parameters 430 collected during a previous successful verification (e.g., the "distance" between the current parameters and the historical parameters) and/or the degree to which current parameters 406 correlate with historical parameters 430 collected during a previous unsuccessful verification attempt or a fraudulent verification attempt (which would tend to indicate a greater risk). As discussed in detail below, in one embodiment, risk level 407 is determined using an anomaly detection algorithm that uses a distance function to specify the distance between current parameters 406 and historical parameters 430 (discussed in detail below).

In one embodiment, based on the detected risk level 407, the verification server 450 selects the verification technology 408 required to verify the user. Generally speaking, the greater the risk level 407 (e.g., the greater the distance from the parameters indicating "normal" behavior), the more stringent the verification. For example, in one embodiment, if the risk level is above a specified threshold, the verification server 450 may require verification using one or more explicit user verification devices 420 to 421. Conversely, for risk levels below the specified threshold, non-intrusive verification technology 405 may be sufficient. As described above, the verification request sent from the relying party may include other forms of security-related data, such as a cryptographic random number.

In response to the verification request sent from the relying party, the verification client 410 prompts the user to perform verification using one or more designated verification devices 420 to 421 (if explicit verification is required). If the user successfully verifies (for example, swipes a registered finger on a fingerprint verifier), the verification client 410 sends back a verification response indicating successful verification. The verification client 410 may send other security-related data along with the verification response, such as a cryptographic random number and/or a signature generated using the authenticator's encryption key. The verification server 450 may then verify the verification response (for example, verifying the cryptographic random number and verifying the signature using the corresponding authenticator key). If the verification is successful, the user will be allowed to perform the desired transaction. For example, in one embodiment, the verification server 450 may send an indication of successful verification to the relying party web server to allow the user to complete the transaction.

In one embodiment, the results analysis and update module 412 analyzes parameters associated with successful or unsuccessful authentication attempts to generate updates 409 to historical parameters and thresholds. For example, if authentication is successful, the current parameters 406 may be added as historical parameters 430 associated with successful authentication (thereby reducing the "riskiness" associated with those parameters). Conversely, if authentication is unsuccessful and/or if fraud is detected, the updates generated by the results analysis and update module 412 may associate one or more of the current parameters 406 with the unsuccessful authentication attempt (e.g., so that the presence of those parameters in future authentication attempts indicates a higher risk). For example, if the current parameters 406 indicate that the user is located in a previously unobserved location and authentication is unsuccessful, the results analysis and update module 412 may update the thresholds and/or weights associated with this location to increase the risk associated with this location. The resulting data is then integrated with the historical authentication parameter and threshold database 430. The results analysis and update module 412 may use a variety of different types of algorithms, including machine learning algorithms (described below), to provide updates to the historical data.

In this way, the results analysis and update module 412 continuously analyzes and generates correlations for new authentication events (successful and unsuccessful) and responsively updates the existing historical data 430. The risk analysis module 411 can then use the updated historical data 430 for subsequent authentication attempts. Although shown as separate modules in Figures 4A and 4B, the risk analysis module 411 and the results analysis and update module 412 can be implemented as a single integrated machine learning module to continuously evaluate parameters related to user activity and update the historical database 430.

In one embodiment, historical parameters and thresholds 430 are set solely based on the user's "normal" pattern. That is, rather than incorporating data related to unsuccessful authentication events or fraudulent activity, historical parameters 430 can be updated to include data related only to successful authentication events. Thus, in this embodiment, risk analysis module 411 will attempt to measure deviations from this normal user profile and generate a risk level 407 based on the amount of deviation from normal user behavior (e.g., based on whether one or more thresholds have been crossed, as discussed below).

FIG4B illustrates an embodiment in which the risk analysis module 411 and the results analysis and update module 412 are implemented within the verification client 410 rather than on the verification server 450 (or in addition to being implemented on the verification server). As in the server-side embodiment shown in FIG4A , in this embodiment, the risk analysis module 411 evaluates the correlation between the current parameters 406 and the historical parameters 430 to determine the risk level 407 associated with the current transaction. Based on the risk level 407, the verification client selects one or more verification techniques 408 and provides the verification results to the results analysis and update module 412, which then updates the historical parameters and thresholds based on the current parameters 406 and the verification results. Various specific parameters and verification results that may be evaluated are provided below.

In one embodiment, the parameters collected and evaluated to determine the risk level 407 may include: the identity of each user and various data associated with the authenticators 420-421 registered at the authentication server, including, for example, an authentication attestation ID (AAID), which uniquely identifies the type of authenticator being registered; a key ID associated with a key exchanged during authenticator registration (and stored in secure storage 425 on the client and the authentication server); cryptographic key data used to verify cryptographic signatures generated with the key; a signature counter indicating the number of times a signature has been generated with the key; and an authenticator version indicating the version of each authenticator. Additionally, the parameters used to determine the risk level may include metadata associated with each authenticator, such as the AAID (mentioned above), the authenticator vendor, the authenticator type (e.g., indicating whether the authenticator is internal or external to the client), authentication factors (e.g., fingerprint, voiceprint, presence, etc.), and key protection methods (e.g., trusted execution environment, secure element, etc.).

To perform a more detailed analysis, one embodiment of the present invention collects and analyzes one or more of the following different parameters:

1. Parameters related to encryption key usage data

○ Timestamp of the operation

○Key ID of the key used

○Verification operations performed

○Indication of success or failure of signature verification

○The transaction ID associated with the operation

○The transaction risk score associated with this operation

○ Final transaction verification status (success or failure)

2. Parameters related to key state transition

○ Transition timestamp

○Key ID of the transformation key

○ Validator version for transition validator

○ Transitional states (e.g., healthy, attacked, deregistered, replicated, compromised)

3. Parameters related to post-verification fraud reporting

○ Timestamp of fraud

○ The transaction ID of the transaction that has been reported as fraudulent

4. Parameters related to the historical security strength of the key

○Sampling timestamp

○Key ID of the encryption key

○ Security strength at the time of sampling

5. Parameters related to the historical security strength of the validator

○Sampling timestamp

○ The AAID of the authenticator

○ Security strength at the time of sampling

6. Additional parameters collected from alternative data sources

○ GPS location of user device

○ WiFi information around the user's device

○Digital fingerprint of the user’s device

○ Biometric score collected from the user's biometric device

7. User activity parameters

○ User registration timestamp

○The timestamp of the last successful login

○The last local verification method and its timestamp

In one embodiment, the risk analysis module 411 determines the current risk level 407 by evaluating these parameters in the manner specified below. These evaluations may be based on (1) parameters related to the AAID and key on the client device; (2) parameters related to the time of user authentication; (3) parameters related to the location of the client device; (4) parameters related to the network connectivity of the client device; and (5) parameters related to a biometric score generated by the authentication client (e.g., in response to a user authentication attempt).

1. AAID and key

In one embodiment, the number of times an encryption key or AAID has been successfully used in the past will reduce the risk associated with the use of that encryption key or AAID. Conversely, the number of times an encryption key or AAID has been associated with unsuccessful authentication attempts or fraud attempts will increase the risk associated with that encryption key or AAID. In one embodiment, the number of successful authentication attempts can be compared to authentication attempts using other encryption keys or AAIDs. If this key/AAID is used significantly less frequently than other keys/AAIDs, this can increase the risk level associated with its use.

Other variables that may be evaluated include the last time the encryption key was used and the last time this user used any authenticator. For example, if the user has not used this authenticator (or any authenticator) for an extended period of time (e.g., exceeding a threshold), this may increase the risk associated with the authenticator. Additionally, whether the encryption key has been copied and/or how frequently the key for this AAID is being copied may be considered to determine risk (e.g., more copies indicate more risk).

Additional variables that may be assessed include how often the encryption key's status is changed to "compromised" (thereby indicating a greater risk), how many times the user has deleted an authenticator from their account, how many times the user has registered/deregistered a particular AAID, how often the user has deregistered that AAID, how long the user used that AAID before they chose to deregister it; the number of times any authenticator from this vendor has been compromised; the number of times this authenticator version has been compromised; the number of times the user has attempted to register the authenticator within different specified time periods (e.g., the last 20 seconds, 5 minutes, 60 minutes, 1 day, 7 days); and the number of times the user has attempted to authenticate using the authenticator within the last specified time period (e.g., 20 seconds, 5 minutes, 60 minutes, 1 day, 7 days).

2. Verification time

In one embodiment, the time of day during which users typically request authentication, and the number of times per day/week/month that users typically request authentication, can be evaluated to determine risk. For example, if the current authentication request is not at a typical time and/or day, and/or if the number of authentication requests per day/week/month is out of range, this may indicate fraudulent activity. Another variable that can be evaluated is an indication of whether this is an appropriate time to authenticate using this particular authenticator.

3. Location

In one embodiment, the location variables evaluated to determine risk include the number of times the authenticator has been seen near the current location, the last time the authenticator has been seen near a given location, the amount of fraud seen near this location in the past, the amount of fraud seen in this location using this AAID, the distance of this location from the user's usual location, the distance of this location from the location where the user last authenticated, and the overall risk associated with this location/country.

4. Network connectivity

In one embodiment, the network variables evaluated to determine risk include the number of times this user/key has been seen in the vicinity of a given WiFi (or other network); the number of times the device has been involved in fraudulent activity while in range of a given WiFi (or other network); and the likelihood that a given WiFi is readily available in the current declared location.

5. Biometric score

In one embodiment, the biometric scores generated by the client's authenticators 420-421 can be used to determine risk. For example, a statistical average of the biometric scores can be determined for this AAID. If the current score is a specified distance from the average, this can indicate a higher risk. Additionally, the average biometric score for this particular user can be compared to the current score. Again, if the current score is a specified distance from the average, this can indicate a higher risk.

In one embodiment of the present invention, machine learning techniques are employed to identify specific parameters (such as those described above) that indicate fraudulent activity and/or legitimate activity. FIG5 illustrates one embodiment of a method for determining and evaluating parameters to assess risk. The method may be implemented within the context of the system architecture illustrated in FIG4A-4B , but is not limited to any particular system architecture.

At 501, a number of parameters that may be correlated with fraudulent activity are selected. In one embodiment, an initial set of parameters is selected using a training process in which these parameters and validation results are provided as input to a machine learning algorithm that identifies correlations between these parameters and fraudulent and/or legitimate activity. The end result is the identification of certain parameters that are highly correlated with legitimate and/or fraudulent activity.

At 502, one or more thresholds (T) are selected based on the evaluation of these parameters. In one embodiment, the selected thresholds define the boundaries between "fraudulent," "suspicious," and/or "normal" activity. For example, thresholds may be set for time ranges during which authentication attempts are considered "normal." Times outside these ranges may be considered suspicious or fraudulent, and the risk level may be increased accordingly. Various other thresholds may be determined using any or all of the parameters discussed above. In one embodiment, the thresholds may be automatically set by a machine learning algorithm that, as mentioned, identifies correlations between fraudulent/legitimate activity and various parameters.

Once the initial parameters and thresholds are determined, the distance between the parameters for the current transaction and existing historical parameters is compared at 503. In one embodiment, this is accomplished using mathematical methods using machine learning or other algorithms that can determine correlations between data sets. Generally speaking, the greater the distance from "normal" parameters, the higher the risk associated with the current transaction.

After the evaluation, at 504, it is determined whether the final values of these parameters are within the selected thresholds when compared to the historical data set. If not, at 505, this is determined to be unusual activity (e.g., suspicious or fraudulent), and the user may be required to authenticate using a more stringent authentication technique (e.g., explicit biometric authentication). In the embodiment shown in FIG4 , the risk level 407 may be increased, requiring more stringent authentication. If these parameters are within the selected thresholds, at 506, the interaction is considered normal activity and less stringent (or no) authentication may be used (e.g., non-intrusive authentication such as described above).

In either case, at 506, the historical data is updated to reflect the most recent verification result. In this way, historical data used to detect suspicious or fraudulent activity can be continually updated to reflect new data points and thresholds. For example, if a user enters a transaction from an uncharacteristic location or at an unusual time, this can be identified as unusual activity at 505. However, if the user successfully verifies, the historical data can be updated at 506 to reflect the fact that a legitimate user has verified at this particular location and time. Thus, this particular location and/or time can no longer be considered "unusual," or more accurately, the "riskiness" associated with this location and/or time can be reduced.

Various mathematical methods can be used to determine the "distance" between the parameters of the current transaction and the historical parameters (e.g., operation 503 in FIG5 ). One particular method is known as anomaly detection, which can be based on a Gaussian distribution. Although the following discussion will focus on anomaly detection, various other machine learning algorithms can also be applied.

FIG6 illustrates an anomaly detection algorithm employed in one embodiment of the present invention. At 601, a set of initial parameters (P ₁ ...P _m ) that may be indicative of fraudulent activity is selected. Ideally, these parameters are selected to have the strongest correlation with fraudulent and/or legitimate activity. As mentioned above, these initial parameters can be selected using a training process that utilizes existing validation data collected over a period of time.

At 602, for each parameter (P _i ), the existing data set history (hi ₁ ... _hm ) is used, which is normalized if not Gaussian enough. Once normalized, the mean (μ) and variance (σ) parameters of the Gaussian distribution are determined based on the data set history (hi ₁ ... _hm ). In one embodiment, this is done using the following equations:

i.

ii.

At 603, for each new transaction with parameters (x ₁ ...x _m ), a Gaussian distribution for each new parameter is calculated based on the history. In one embodiment, this is done using the following equation:

i.

At 604, p(x) is calculated for the sum of all parameters. In one embodiment, this is done according to the following equation:

|

If it is determined at 605 that p(x) < T (a selected threshold), then this is determined to be unusual behavior at 606. Thus, one or more strict authentication techniques (e.g., explicit biometric authentication) may be requested. However, if p(x) ≥ T, then at 607, the interaction is identified as normal activity and may require less stringent authentication (e.g., non-intrusive authentication as described above) or no authentication may be required.

In either case, the data set history is updated with the new parameters (P ₁ ...P _m ) and associated validation results at 608. For example, if validation was successful at 606, the data set history may be updated to reflect the successful validation associated with those parameters.

Exemplary data processing apparatus

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

As shown in Figure 7, computer system 700, which is a form of data processing system, includes a bus 750, which is coupled to a processing system 720, a power supply 725, a memory 730, and a non-volatile memory 740 (e.g., a hard drive, flash memory, phase change memory (PCM), etc.). The bus 750 can be connected to each other through various bridges, controllers, and/or adapters as are well known in the art. The processing system 720 can retrieve instructions from the memory 730 and/or the non-volatile memory 740 and execute these instructions to perform the operations described above. The bus 750 interconnects the above components together and also interconnects those components to an optional base 760, a display controller and display device 770, an input/output device 780 (e.g., a NIC (network interface card), a cursor control (e.g., a mouse, a touch screen, a touchpad, etc.), a keyboard, etc.), and an optional wireless interface 790 (e.g., Bluetooth, WiFi, infrared, etc.).

Figure 8 is a block diagram illustrating an exemplary data processing system that may be used in some embodiments of the present invention. For example, data processing system 800 may be a handheld computer, a personal digital assistant (PDA), a mobile phone, a portable gaming system, a portable media player, a tablet computer, or a handheld computing device (which may include a mobile phone, a media player, and/or a gaming system). For another example, data processing system 800 may be a network computer or an embedded processing device within another device.

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

The memory 810 can store data and/or programs for execution by the data processing system 800. The audio input/output 840 can include a microphone and/or a speaker to (for example) play music, and/or provide telephone functionality through the speaker and microphone. The display controller and display device 860 can include a graphical user interface (GUI). A wireless (e.g., RF) transceiver 830 (e.g., a WiFi transceiver, an infrared transceiver, a Bluetooth transceiver, a wireless cellular phone transceiver, etc.) can be used to communicate with other data processing systems. The one or more input devices 870 allow a user to provide input to the system. These input devices can be a keypad, a keyboard, a touch panel, a multi-touch panel, etc. Optional other input/output 850 can be a connector for the base.

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

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

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

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

Claims (22)

1. A method implemented within a verification system, comprising: Select a set of parameters related to user activity on the client device; Receive a request to verify the user's information for the current transaction; Responsive calculation of the distance between parameters associated with the current transaction and historical parameters from the existing dataset; The risk level associated with the current transaction is determined based on the calculated distance between the parameters associated with the current transaction and the historical parameters. Based on the risk level, select one or more verification technologies required to verify the user; Perform one or more of the aforementioned verification techniques to attempt to verify the user and generate a verification result; Update the historical parameters using the parameters associated with the current transaction and the verification result; and Machine learning is employed to select the set of parameters by examining the correlation between the results of each parameter and the results of previous validation events. 2. The method of claim 1, wherein the parameters include parameters associated with a validator identifier or key used to perform the verification, parameters associated with the verification time, parameters associated with the verification location, parameters associated with network connectivity, and/or parameters associated with a biometric score generated by the client device validator. 3. The method of claim 1, wherein if the distance between one or more of the parameters associated with the current transaction and the corresponding historical parameter is less than a specified threshold, the risk level is set to a first level representing normal user behavior. 4. The method of claim 3, wherein if the distance between one or more of the parameters associated with the current transaction and the corresponding historical parameter is higher than a specified threshold, the risk level is set to a second level indicating suspicious user behavior. 5. The method of claim 1, wherein the selection includes: For risk levels above a first threshold, a first subset of verification techniques is selected, and for risk levels below the first threshold, a second subset of verification techniques is selected, or no verification techniques are selected. 6. The method of claim 5, wherein the first subset of the verification techniques includes explicit biometric user verification. 7. The method of claim 6, wherein the second subset of verification techniques includes non-invasive verification techniques. 8. The method of claim 1, wherein parameters that are highly correlated with successful verification events and/or unsuccessful verification events are selected to be included in the set of parameters. 9. The method of claim 1, wherein calculating the distance between the parameters associated with the current transaction and historical parameters includes performing anomaly detection using a Gaussian distribution of the parameters. 10. A non-transitory machine-readable medium storing program code, said program code, when executed by a machine, causing the machine to perform the following operations: Select a set of parameters related to user activity on the client device; Receive a request to verify the user's information for the current transaction; Responsive calculation of the distance between parameters associated with the current transaction and historical parameters from the existing dataset; The risk level associated with the current transaction is determined based on the calculated distance between the parameters associated with the current transaction and the historical parameters. Based on the risk level, select one or more verification technologies required to verify the user; Perform one or more of the aforementioned verification techniques to attempt to verify the user and generate a verification result; Update the historical parameters using the parameters associated with the current transaction and the verification result; and Machine learning is employed to select the set of parameters by examining the correlation between the results of each parameter and the results of previous validation events. 11. The machine-readable medium of claim 10, wherein the parameters include parameters associated with a validator identifier or key used to perform the verification, parameters associated with the verification time, parameters associated with the verification location, parameters associated with network connectivity, and/or parameters associated with a biometric score generated by a validator on a client device. 12. The machine-readable medium of claim 10, wherein if the distance between one or more of the parameters associated with the current transaction and the corresponding historical parameter is less than a specified threshold, the risk level is set to a first level representing normal user behavior. 13. The machine-readable medium of claim 12, wherein if the distance between one or more of the parameters associated with the current transaction and the corresponding historical parameter is greater than a specified threshold, the risk level is set to a second level indicating suspicious user behavior. 14. The machine-readable medium of claim 10, wherein the selection includes: For risk levels above a first threshold, a first subset of verification techniques is selected, and for risk levels below the first threshold, a second subset of verification techniques is selected, or no verification techniques are selected. 15. The machine-readable medium of claim 14, wherein the first subset of the verification techniques includes explicit biometric user verification. 16. The machine-readable medium of claim 15, wherein the second subset of the verification techniques includes non-invasive verification techniques. 17. The machine-readable medium of claim 10, wherein parameters that are highly correlated with successful verification events and/or unsuccessful verification events are selected to be included in the set of parameters. 18. The machine-readable medium of claim 10, wherein calculating the distance between the parameters associated with the current transaction and historical parameters includes performing anomaly detection using a Gaussian distribution of the parameters. 19. A verification system, comprising: A client device, the client device being used to provide a set of parameters related to the current user's activity; Verification server, the verification server being used for: Receive a request to verify the user's information for the current transaction; Calculate the distance between the parameters associated with the current transaction and historical parameters from the existing dataset; The risk level associated with the current transaction is determined based on the calculated distance between the parameters associated with the current transaction and the historical parameters; and Based on the risk level, select one or more verification technologies required to verify the user; A verification engine, which executes one or more verification techniques to attempt to verify the user and generate a verification result; The verification server is further configured to update the historical parameters using the parameters associated with the current transaction and the verification results, and to employ machine learning to select the set of parameters by performing a correlation analysis between each parameter and the results of previous verification events. 20. The system of claim 19, wherein the parameters include parameters associated with a validator identifier or key used to perform the verification, parameters associated with the verification time, parameters associated with the verification location, parameters associated with network connectivity, and/or parameters associated with a biometric score generated by the validator on the client device. 21. The system of claim 19, wherein if the distance between one or more of the parameters associated with the current transaction and the corresponding historical parameter is less than a specified threshold, the risk level is set to a first level representing normal user behavior. 22. The system of claim 21, wherein if the distance between one or more of the parameters associated with the current transaction and the corresponding historical parameter is greater than a specified threshold, the risk level is set to a second level indicating suspicious user behavior.