HK1263015B - Query system and method to determine authentication capabilities - Google Patents

Description

Query system and method for determining verification function

Related information of divisional applications

The application is a divisional application of a Chinese invention patent application with the application number of 201380068869.3 after the PCT application with the international application numbers of PCT/US2013/077888 and the application date of 2013, namely 12-month and 26-month query system and method for determining verification function enters the Chinese national stage.

Technical Field

The present invention relates generally to the field of data processing systems. More particularly, the present invention relates to a query system and method for determining an authentication function.

Background

Existing systems have been designed to provide secure user authentication in a network using biometric sensors. In particular, the Online Secure Transaction Plugin (OSTP) protocol developed by the online fast identity verification (FIDO) consortium enables strong verification (e.g., to prevent identity theft and phishing), secure transactions (e.g., to prevent "malware in browser" and "man-in-the-middle" attacks on transactions), and registration/management of client authentication tokens (e.g., fingerprint readers, facial recognition devices, smart cards, trusted platform modules, etc.). Details of existing OSTP protocols can be found, for example, in U.S. patent application No.2011/0082801 ("the' 801 application") and a document entitled OSTP Framework, both of which describe a Framework for user registration and authentication on a network.

Disclosure of Invention

In one embodiment, the present application provides a method comprising: receiving a policy identifying a set of acceptable authentication functions; determining a set of client authentication functions for a client by identifying, by the client, a set of authentication devices on the client that correspond to the set of client authentication functions based on a secure storage of the client; filtering, by the client, the set of acceptable authentication functions based on a privacy preference level of a user of the client and the determined set of client authentication functions to obtain a filtered set of one or more authentication functions for authenticating the user; and authenticating the user over the network using the filtered set of one or more authentication functions.

In another embodiment, the present application provides a system comprising: a client that receives a policy to identify a set of acceptable authentication functions and determines a set of client authentication functions, the client comprising a secure store, the client identifying, based on the secure store, a set of authentication devices on the client corresponding to the set of client authentication functions, the client further comprising a policy filter that filters the set of acceptable authentication functions based on a privacy preference level of a user of the client and the determined set of client authentication functions to obtain a filtered set of one or more authentication functions for authenticating the user of the client; and the client authenticating the user over the network using the filtered set of one or more authentication functions.

In yet another embodiment, the present application provides a machine-readable medium having program code stored thereon, which when executed by a machine, causes the machine to perform the operations of: receiving a policy identifying a set of acceptable authentication functions; determining a set of client authentication functions for a client by identifying, by the client, a set of authentication devices on the client that correspond to the set of client authentication functions based on a secure store of the client; filtering, by the client, the set of acceptable authentication functions based on the privacy preference level of the user of the client and the determined set of client authentication functions to obtain a filtered set of one or more authentication functions for authenticating the user of the client; and authenticating the user over the network using the filtered set of one or more authentication functions.

Drawings

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

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

FIG. 2 is a transaction diagram showing how an authentication device on a client device may be located.

Fig. 3 is a transaction diagram showing how a user may enroll on an authentication device.

Fig. 4 is a transaction diagram showing how a key may be registered into an authentication device.

FIG. 5 is a transaction diagram showing how user authentication may be implemented within an authentication framework.

FIG. 6 is a transaction diagram showing how transaction details may be verified.

FIG. 7 illustrates a query policy filter implemented according to an embodiment of the invention.

FIG. 8 is a transaction diagram illustrating how a registration operation with a query policy is implemented in one embodiment of the invention.

FIG. 9 illustrates one embodiment of an architecture for implementing multiple authentication device processes.

10A-10C illustrate three embodiments of the present invention of multiple authentication device processing.

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

FIG. 12 illustrates an architecture for implementing privacy classes according to one embodiment of the invention.

FIG. 13 is a transaction diagram implementing privacy classes according to one embodiment of the invention.

FIG. 14 illustrates one embodiment of an architecture for verifying transactions using signatures.

Fig. 15-16 illustrate exemplary embodiments of computer systems for performing embodiments of the present invention.

Detailed Description

Embodiments of an apparatus, method, and machine-readable medium for intelligently implementing a verification framework in a client-server environment are described below. 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. It will be apparent, however, to one 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 underlying principles of the present invention.

Embodiments of the invention discussed below relate to client devices having authentication functionality, such as biometric devices. These devices are sometimes referred to herein as "tokens". A variety of different biometric devices may be used, including, but not limited to, 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 functionality (e.g., an optical scanner and associated software for scanning a user's retina). The authentication function may also include non-biometric devices such as Trusted Platform Modules (TPMs) and smart cards.

The embodiments of the present invention described below provide various improvements over prior art authentication techniques. For example, in contrast to current techniques that require a client to transmit an exhaustive list of all of its authentication functions (e.g., all of its authentication tokens/devices) over a network, one embodiment of the invention implements a query policy in which a secure transaction server initially transmits a server policy to the client indicating the authentication functions accepted by the server. The client then analyzes the server policy to identify a subset of the authentication functions to reduce privacy impact on the client.

In another embodiment, a plurality of configurable privacy protection levels are employed. The privacy classes are predefined and may be selected and/or modified by the end user. In one embodiment of the invention, the privacy classes are defined based on the probability that the client can be identified using the requested information. At relatively higher privacy levels (with relatively lower privacy impacts), relatively less information about the client device is revealed to perform the authentication techniques described herein.

Another embodiment of the present invention provides for the configuration or validation of multiple devices simultaneously, thereby increasing efficiency. For example, rather than requesting registration or authentication of a single authentication device at a time, a list of authentication devices may be sent from the server. The symmetric and/or asymmetric keys are then configured into multiple tokens/devices by a single operation or a series of sequential operations performed locally on the client. Several tokens/devices may be selected simultaneously for a given transaction for verification.

Another embodiment of the present invention increases the efficiency of processing and managing server challenges. Today, after the server sends a random challenge (e.g., a cryptographic nonce) to the client, if the client does not respond within a specified timeout period, the nonce is no longer valid and the client will receive an error in response to subsequent authentication attempts. For example, if a user suspends a client to move to a new location (e.g., closes a lid on a laptop) and then attempts authentication, the authentication attempt will be denied. In one embodiment of the invention, the client detects that the random challenge has expired and automatically and transparently requests a new challenge from the server. The server then generates a new challenge and transmits it to the client, which can be used for authentication. The end user experience is improved because the user does not receive an error or denial of the authentication request.

Another embodiment of the invention employs transaction signatures on a secure transaction server so that there is no need to maintain any transaction state on the server to maintain a current session with the client. The transaction content (such as transaction text) is sent to the client signed by the server, which sends back the signed transaction content when the server responds. The server need not store the transaction state because it can verify that the signed transaction response received by the client is valid by verifying the signature.

While described above as separate embodiments, all of the above-described techniques may be combined together in various ways within a single integrated verification system. Thus, a given embodiment of the invention may be combined with one or more other embodiments described herein for improved client and user authentication in a secure network environment.

Exemplary System architecture

Figures 1A-1B illustrate two embodiments of a system architecture that includes a client and server-side component for authenticating a user. The embodiment shown in FIG. 1A uses a browser plug-in based architecture for communicating with web sites, whereas the embodiment shown in FIG. 1B does not require a browser. The various techniques described herein (such as enrolling a user on an authentication device, enrolling an authentication device on a secure server, and authenticating a user) may be implemented on any of these system architectures. Thus, while the architecture shown in FIG. 1A is used to show the operation of some of the embodiments described below, the same basic principles can be readily implemented on the system shown in FIG. 1B (e.g., by removing the browser plug-in 105 as an intermediary for communications between the server 130 and the secure transaction service 101 on the client).

Turning first to FIG. 1A, the illustrated embodiment includes a client 100 equipped with one or more authentication devices 110-112 (sometimes referred to in the art as authentication "tokens") for enrolling and authenticating end users. As described above, the authentication devices 110-112 may include biometric identification 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 functionality (e.g., an optical scanner and associated software for scanning a user's retina), as well as non-biometric identification devices, such as Trusted Platform Modules (TPMs) and smart cards.

The verification devices 110-112 are communicatively coupled to the client through an interface 102 (e.g., an application programming interface or API) exposed by the secure transaction service 101. The secure transaction service 101 is a secure application for communicating with one or more secure transaction servers 132-133 over a network and for interacting with a secure transaction plugin 105 executing within the context of a web browser 104. As shown, the interface 102 may also provide secure access to a secure storage 120 on the client 100, the secure storage 120 storing information about each of the authentication devices 110-112, such as a device identification code, a user identification code, user enrollment data (e.g., a scanned fingerprint or other biometric data), and keys for performing the secure authentication techniques described herein. For example, as described in detail below, the unique key may be stored within each of the authentication devices and used when communicating with the server 130 in a network (such as the Internet).

As described below, certain types of network transactions are supported by the secure transaction plug-in 105, such as HTTP or HTTPs transactions using the website 131 or other server. In one embodiment, the secure transaction plugin is launched in response to a specific HTML tag inserted into the HTML code of a Web page by a Web server 131 within the secure enterprise or Web target 130 (sometimes referred to hereinafter simply as "server 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. Further, for certain types of transactions (such as secure key exchanges), the secure transaction service 101 may open a direct communication channel with the local transaction server 132 (i.e., co-located with the website) or with the off-board transaction server 133.

The secure transaction servers 132-133 are coupled to a secure transaction database 120 for storing user data, authentication device data, keys, and other secure information needed to support secure authentication transactions as described below. It should be noted, however, that the underlying principles of the invention do not require the separation of logical components within the secure enterprise or web target 130 shown in FIG. 1A. For example, the website 131 and the secure transaction servers 132-133 may be implemented within a single physical server or separate physical servers. Further, the website 131 and the secure transaction servers 132-133 may be implemented within an integrated software module executing on one or more servers for performing the functions described below.

As described above, the underlying principles of the invention are not limited to the browser-based architecture shown in FIG. 1A. FIG. 1B illustrates an alternative embodiment in which a standalone application 154 utilizes the functionality provided by the secure transaction service 101 to authenticate a user over a network. In one embodiment, the application 154 is designed to establish a communication session with one or more network services 151, the network services 151 relying on the secure transaction servers 132-133 for performing user/client authentication techniques described in detail below.

In any of the embodiments shown in fig. 1A-1B, the secure transaction servers 132-133 may generate keys that are then securely transmitted to the secure transaction service 101 and stored within the authentication device within the secure memory 120. In addition, the secure transaction servers 132-133 manage the secure transaction database 120 on the server side.

Equipment search,

Enrollment, registration and verification overview

A series of exemplary transactions for performing authentication device lookup, enrollment, registration, and authentication are shown in fig. 2-6. Some aspects of these transactions are employed in the OSTP protocol described above (see the OSTP framework (23/3/2011) for additional details, which is incorporated herein by reference). An understanding of the basic operation of these transactions will provide a context in which embodiments of the present invention may be implemented.

The operations described below include the detection of a verification device (FIG. 2); user enrollment on an authentication device (fig. 3); registration of the authentication device (fig. 4); user authentication on a registered authentication device (fig. 5); and a verified secure transaction implementation (fig. 6).

Fig. 2 illustrates a series of transactions for detecting an authentication device on a client. After successful completion of device detection, the server 130 has detailed information about the authentication devices attached to the client and will be able to evaluate which device or devices are best suited for use with the enhanced security infrastructure. Only the server 130 filters the list of authentication devices. The user will be provided with this list and may select one (or a combination) of the authentication devices for further authentication and implementation of the secure transaction.

In operation, a user is authenticated in a browser by a username and password and logs into a website. This is only once the user is required to provide a username and password. The server 130 determines that the user is not currently using the enhanced security (e.g., by querying the secure transaction database 120) and provides suggestions to the user to change to the enhanced security.

In one embodiment, the server 130 includes a "query device" tag in the HTML page that is detected by the secure transaction plugin 105. In response to detecting the tag, the secure transaction plugin 105 reroutes the request to the secure transaction service 101, which secure transaction service 101 then prepares detailed information about all verification devices attached to the system, including the security features of the devices. In one embodiment, the information is packaged in XML format prior to transmission using a pre-specified data scheme.

The secure transaction plugin 105 receives this information from the secure transaction service 101 and, in one embodiment, passes the information to the web page's JavaScript via a registered callback. Which then selects how the information is to be displayed in the browser 104. The website filtered list may be displayed to the user and the user may select one or a combination of the authentication devices.

Fig. 3 shows a series of transactions for enrolling a user at an authentication device. In one embodiment, registration is a precondition for using the enhanced security provided by the embodiments of the invention described herein. Enrollment involves acquiring biometric reading data (e.g., a fingerprint, voice sample, etc.) of the user so that the user can be authenticated using the same authentication device during subsequent transactions. The registration operation may be done on the client only, without interaction with the server 130. The user interface or interfaces provided for enrollment may be displayed in the browser extension or may be displayed in a separate application or mobile device app.

The registration operation may be initiated upon detection of the device. The user may choose to use one or a set of the found devices to achieve enhanced security. In operation, a user may select one device from a list of displayed devices in a browser, application, or mobile device app. For the browser-based embodiment shown in FIG. 3, the secure transaction plugin 105 displays a device-specific registration Graphical User Interface (GUI). The secure transaction plugin 105 transmits the device identifier and the registration request to the secure transaction service 101 and waits for completion. If the user is already registered on the authentication device on the client, the user may only need to verify his identity (i.e., he will not need to register again). If the user is not currently enrolled, the secure transaction service 101 begins the enrollment process by activating a physical verification device (e.g., via the device interface 102). The user then interacts with the secure transaction plugin 105GUI and follows the specified enrollment steps (e.g., scan finger, speak into microphone, snap picture, etc.). Upon completion, the user will enroll on the authentication device. Importantly, once a user registers with a device, the registration can be used for registration or authentication on any website or web service as described herein.

Fig. 4 shows a series of transactions for verifying device registration. During registration, a key is shared between the authentication device and one of the secure transaction servers 132-133. The key is stored in the secure memory 120 of the client 100 and the secure transaction database 120 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 described below, an asymmetric key may be used. In this embodiment, the public key may be stored by the secure transaction servers 132-133 and the second associated private key may be stored in the secure memory 120 on the client. Further, in one embodiment (also discussed below), one or more keys may be generated on the client 100 (e.g., by an authentication device or authentication device interface rather than the secure transaction servers 132-133).

Keys may be shared with clients over a secure communication channel using a secure key configuration protocol, such as dynamic symmetric key configuration protocol (DSKPP) (see, e.g., request for comments (RFC) 6063). However, the underlying principles of the invention are not limited to any particular key provisioning protocol.

Turning to the specific details shown in fig. 4, once user enrollment or user authentication is complete, the server 130 generates a randomly generated challenge (e.g., a cryptographic nonce) that must be presented by the client during device registration. The random challenge may be valid for a limited period of time. The secure transaction plugin detects the random challenge and forwards it to the secure transaction service 101. In response, the secure transaction service initiates an out-of-band session (e.g., out-of-band transaction) with the server 130 and communicates with the server 130 using a key provisioning protocol. The server 130 locates the user by username, verifies the random challenge, verifies the device's verification code (if one was sent), and creates a new entry in the secure transaction database 120 for the user. It may also generate a key, write the key to the database 120 and send the key back to the secure transaction service 101 using a key provisioning protocol. Once this is done, the authentication device and the server 130 may share the same key when using a symmetric key or different keys when using an asymmetric key.

Fig. 5 shows a series of transactions for user authentication on a registered authentication device. Once device registration is complete, server 130 will accept the token generated by the local authentication device as a valid authentication token.

Turning in specific detail to fig. 5, which illustrates a browser-based implementation, a user enters a Uniform Resource Locator (URL) of server 130 in browser 104. In embodiments using a standalone application or mobile device app (rather than a browser), the user may enter a network address of the network service or the application or app may automatically attempt to connect to the network service at the network address.

For browser-based implementations, the website embeds the query of the registered device in an HTML page. This can be done in many ways other than embedding the query in an HTML page, such as through Javascript or using an HTTP header. The secure transaction plugin 105 receives the URL and sends it to the secure transaction service 101 and the secure transaction service 101 searches the secure store 120 (as described, the secure store 120 includes a database of authentication device and user information) for a lookup and determines if there is a user registered in the URL. If so, the secure transaction service 101 sends a list of configured devices associated with the URL to the secure transaction plugin 105. The secure transaction plugin then calls the registered JavaScript API and passes this information to the server 130 (e.g., website). The server 130 selects the appropriate device from the transmitted device list, generates a random challenge, and sends device information and parameters back to the client. The website displays the corresponding user interface and requests authentication from the user. The user then provides the requested authentication measure (e.g., scans a finger on a fingerprint reader, speaks for voice recognition, etc.). The secure transaction service 101 identifies the user (this step may be skipped for devices that do not support storing users), obtains the username from the database, generates an authentication token using the key, and sends this information to the website via the secure transaction plugin. The server 130 identifies the user from the secure transaction database 120 and verifies the token by generating the same token (e.g., using its key copy) on the server 130. Once verified, the verification process is complete.

Fig. 6 illustrates a secure transaction after authentication of a browser-based embodiment. Secure transactions are designed to provide greater security for certain types of transactions (e.g., financial transactions). In the illustrated embodiment, the user confirms the transaction before submitting each transaction. Using the illustrated technique, the user accurately confirms what he/she wants to submit and accurately confirms what is displayed in the GUI that he/she sees. In other words, this embodiment ensures that the transaction text cannot be modified by the "man-in-the-middle" to submit a transaction that is not confirmed by the user.

In one embodiment, the secure transaction plugin 105 displays a window 601 in the browser context to show the transaction details. The secure transaction server 101 periodically (e.g., at random intervals) verifies that the text shown in the window is not tampered with by anyone.

The following example will help to highlight the operation of this embodiment. The user selects an item to purchase from the commercial site and selects "settle". The merchant site sends the transaction to a service provider having a secure transaction server 132-133 (e.g., payPal) that implements one or more of the embodiments of the invention described herein. The merchant site authenticates the user and completes the transaction.

The secure transaction servers 132-133 receive the Transaction Details (TD) and place and send the "secure transaction" request in an HTML page to the client 100. The secure transaction request includes transaction details and a random challenge (e.g., a random nonce). The secure transaction plugin 105 detects the request for the transaction confirmation message and forwards all data to the secure transaction service 101. In embodiments that do not use a browser or plug-in, the information may be sent directly from the secure transaction server to the secure transaction service on the client 100.

For a browser-based embodiment, the secure transaction plugin 105 displays (in the browser context) a window 601 with transaction details to the user and requests that the user provide verification to confirm the transaction. In embodiments that do not use a browser or plug-in, the secure transaction service 101 or the application 154 may display a window 601. The secure transaction service 101 starts a timer and verifies the contents of the window 601 displayed to the user. The verification period may be randomly selected. The secure transaction service 101 ensures that the user sees valid transaction details in window 601. It will prevent the generation of a confirmation token if it detects that the content has been tampered with.

After the user provides valid authentication (e.g., scanning a finger over a fingerprint sensor), the device identifies the user and generates a token (cryptographic signature) with transaction details and a random challenge (i.e., computing the token based on the transaction details and a nonce). This allows the secure transaction servers 132-133 to ensure that transaction details are not modified between the server and the client. The secure transaction service 101 sends the generated token and username to the secure transaction plugin 105, which secure transaction plugin 105 forwards the token to the secure transaction servers 132-133. The secure transaction servers 132-133 identify the user by the username and authenticate the token. And if the verification is successful, sending a confirmation message to the client and processing the transaction.

System and method for secure queries

Policy for determining client authentication functionality

As mentioned, one embodiment of the present invention implements a query policy, wherein the secure transaction server transmits a server policy to the client indicating the authentication function accepted by the server. The client then analyzes the server policy to identify a subset of authentication functions that it supports and/or that the user indicates is intended to use. The client then registers and/or authenticates the user using a subset of the authentication token that matches the provided policy. Thus, the impact on client privacy is low, as the client does not need to transmit detailed information about its authentication function (e.g., all of its authentication devices) or other information that can be used to uniquely identify the client.

By way of example and not limitation, a client may include a number of authentication functions, such as a fingerprint sensor, voice recognition functions, facial recognition functions, eye/optical recognition functions, trusted Platform Module (TPM), and smart card, among others. However, for privacy reasons, the user may not wish to reveal details of all of their functionality to the requesting server. Thus, using the techniques described herein, the secure transaction server may transmit a server policy to the client indicating that it supports, for example, fingerprint, optical, or smart card authentication. The client may then compare the server policy against its own authentication function and select one or more of the available authentication options.

FIG. 7 illustrates one embodiment of a client-server architecture for implementing these techniques. As shown, the secure transaction service 101 implemented on the client 100 includes a policy filter 701 for analyzing policies provided by the server 130 and identifying a subset of authentication functions to be used for enrollment and/or authentication. In one embodiment, the policy filter 701 is implemented as a software module executing within the context of the secure transaction service 101. It should be noted, however, that policy filter 701 may be implemented in any manner while still complying with the underlying principles of the invention and may include software, hardware, firmware, or any combination thereof.

The particular embodiment shown in FIG. 7 includes a secure transaction plugin 105 for establishing communications with a secure enterprise or Web target 130 (sometimes referred to simply as a "server 130") using the techniques previously described. For example, the secure transaction plug-in may identify a particular HTML tag inserted into the HTML code by the web server 131. Thus, in this embodiment, the server policy is provided to the secure transaction plugin 105, which the secure transaction plugin 105 forwards to the secure transaction service 101 implementing the policy filter 701.

The policy filter 701 may determine the client authentication function by reading the function from the client in the secure storage area 720. As previously described, secure memory 720 may include a repository of all of the client authentication functionality (e.g., all of the identification codes in the authentication device). If the user has enrolled the user on his authentication device, the user's enrollment data is stored in secure memory 720. The secure memory may also store an encrypted private key associated with each authentication device if the client has registered the authentication device with the server 130.

Using the authentication data retrieved from secure storage 720 and the policy provided by the server, policy filter 701 may then identify a subset of the authentication functions to use. Depending on the configuration, policy filter 701 may identify a complete list of authentication functions supported by both the client and the server or may 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 701 may identify the entire subset of generic authentication functions to the server: A. b and C. Alternatively, if a higher level of privacy is desired, as indicated by user preferences 730 in FIG. 7, a more limited subset of authentication functions may be identified to the server. For example, the user may indicate that only a single generic authentication function should be identified to the server (e.g., one of a, B, or C). In one embodiment, the user may establish a priority scheme for all of the authentication functions of the client 100 and the policy filter may select the highest priority authentication function (or a set of N authentication functions that are preferred) that is common to both the server and the client.

Depending on the operation (registration or authentication) that the server 130 has initiated, the secure transaction service 130 performs the operation on the filtered subset of authentication devices (110-112) and sends an operation response back to the server 130 via the secure transaction plugin 105 as shown in figure 7. Alternatively, in embodiments where the plug-in 105 component does not rely on a Web browser, the information may be sent directly from the secure transaction service 101 to the server 130.

FIG. 8 illustrates a transaction diagram showing additional details of a series of exemplary registrations with query policy transactions. In the illustrated embodiment, the user has not previously registered a device with the server 130. Thus, at 801, a user may enter a username and password as an initial one-time authentication step, which is forwarded to server 130 via client browser 104 at 802. It should be noted, however, that the username and password are not required to comply with the underlying principles of the invention.

Because it is determined at 803 that the user has not previously registered for enhanced security, server 130 transmits its server policy to the client at 804. As mentioned, the server policy may include an indication of the authentication functions supported by the server 130. In the illustrated example, the server policy is communicated to the secure transaction service 101 via transaction 806.

At transaction 807, the secure transaction service 101 compares the server policy to the client's functionality (and potentially other information, such as device priority scheme and/or user preferences as described above) to derive a filtered list of authentication functions. The filtered list of devices (102) then generates keys (808 and 809) and then provides the public portions of these keys to the secure transaction service 101, which in turn sends these back to the server 130 as a registration response. The server authenticates the verification device and stores the public key in a secure transaction database. Token authentication as used herein is the process of verifying the identity of a verification device during enrollment. It enables the server to cryptographically ensure that the device reported by the client is indeed the device it purports to be.

Alternatively or additionally, at 807, the user may be provided with an opportunity to view a list and/or select a particular authentication function to be used with that particular server 130. For example, the filtered list may indicate options for verification using fingerprint scanning, facial recognition, and/or voice recognition. The user may then choose to use one or more of these options when authenticating with the server 130.

The above-described techniques for filtering server policies at the client may be implemented at various different stages of the above-described series of transactions (e.g., during device lookup, device registration, device configuration, user authentication, etc.). That is, the underlying principles of the invention are not limited to a particular set of transactions and a particular ordering of transactions set forth in FIG. 8.

Furthermore, as previously mentioned, the browser plug-in architecture is not required to comply with the underlying principles of the present invention. For architectures that do involve a browser or browser plug-in (e.g., a standalone application or mobile device app), the transaction diagram shown in fig. 8 (and the remaining transaction diagrams disclosed herein) may be simplified such that the browser 104 is removed and the secure transaction service 101 communicates directly with the server 130.

Efficient registration, registration on multiple authentication devices

And system and method of authentication

An embodiment of the present invention enables registration, registration and authentication of multiple devices simultaneously, thereby improving efficiency and user experience. For example, rather than requesting registration and authentication of a single device at a time, a list of devices may be sent to the client. The symmetric or asymmetric key may then be registered into multiple devices in one operation or a series of sequential operations performed locally on the client. Several tokens/devices may be selected simultaneously for a given transaction for verification.

FIG. 9 illustrates one embodiment of a client-server architecture for implementing these techniques. As shown, the secure transaction service 101 implemented on the client 100 includes a plurality of device processing logic 901 for performing specified operations (such as registering and registering multiple devices at once) without requiring continuous back-and-forth communication with the server 130 when registering/registering each device. Similarly, server 130 includes a plurality of device processing logic for issuing commands for a plurality of authentication devices. In one embodiment, the plurality of device processing logic 901 is implemented as software modules executing within the context of the secure transaction service 101. It should be noted, however, that the plurality of device processing logic 901 may be implemented in any manner while still complying with the underlying principles of the invention and may include software, hardware, or firmware components or any combination thereof.

As in the embodiments described above, the particular implementation shown in FIG. 9 includes a secure transaction plugin 105 for establishing communication with a server 130 (which, as noted, may include a web server 131 and secure transaction servers 132-133). Thus, the server 130 communicates with the secure transaction service 101 via the secure transaction plug-in 105. However, as mentioned, a browser-based plug-in architecture is not required to comply with the underlying principles of the invention.

The plurality of device processing logic 902 on the server 130 may transmit commands to be executed by the plurality of device processing logic 901 on the client 100 that the client 100 performs operations on the plurality of authentication devices 110-112. By way of example, the plurality of device processing logic 902 may generate N keys to be registered on each of the N authentication devices and then securely transmit to the plurality of device processing logic 901 along with a command to register the N devices. The multiple device processing logic 901 may then perform registration for all N devices (e.g., for authentication devices 110-112) simultaneously or in a series of sequential operations without further interaction with the server. A single response may then be sent to server 130 to indicate that registration of all N devices is complete.

An exemplary series of multiple device transactions is shown in fig. 10A-10C. FIG. 10A illustrates a number of device enrollment processes that may be performed without any interaction with the server 130 (e.g., enrollment of a user on an authentication device may be performed under control of the secure transaction service 101 on a client). In an alternative embodiment, server 130 may transmit a request to a client (not shown) to register the user on the N devices. 10B-10C illustrate two different embodiments for registering multiple devices on server 130.

Turning to the enrollment process in fig. 10A, at 1001, a user indicates a desire to enroll on N authentication devices (representing all or a subset of the available authentication devices) on a client. In response, the secure transaction plugin is invoked 1002 and a device-specific Graphical User Interface (GUI) is generated 1003 to guide the user through the process or to register on the verification device number 1. During the enrollment process, the user interacts with the secure transaction plugin as indicated (e.g., by positioning a finger on a fingerprint sensor, speaking into a microphone, snapping a picture with a camera, etc.). In one embodiment, registration is performed for each of the N devices until registration is completed for the nth device at 1004. Different device-specific scripts and/or user interfaces may be presented to the user to enroll the user on each individual authentication device. As previously described, when a user enrolls on each device, the user enrollment data may be stored in the secure memory 720 on the client 100 and may only be accessed through the secure transaction service 101. Once registration of all N devices is complete, a notification may be sent to the server 130 via transactions 1004-1005.

Regardless of how the registration is performed, once completed, the N devices may be registered on the server 130 using the transaction diagram shown in fig. 10B. At 1010, the server 130 generates a user-specific random challenge that is valid only for a limited period of time and may include a randomly generated code, such as a cryptographic nonce, as previously described. At 1011, a random challenge is transmitted along with a command to register N authentication devices on server 130. At 1012, the secure transaction service 101 creates a secure connection with the server 130 and transmits the identification data of the N devices along with the random challenge. In one embodiment, the secure connection is an HTTPS connection. However, the underlying principles of the invention are not limited to any particular type of secure connection.

At 1013, the server 130 authenticates the N devices, generates a key for each of the N devices, and sends the N keys back to the secure transaction service over the secure connection. In one embodiment, dynamic symmetric key configuration protocol (DSKPP) is used to exchange keys with clients over secure connections. However, the underlying principles of the invention are not limited to any particular key provisioning technique. Alternatively, in embodiments that do not rely on the DSKPP protocol, a key may be generated in each authentication device and subsequently transmitted to server 130.

At 1014-1015, a plurality of device processing logic of the secure transaction service registers each of the N keys into each of the N devices. As previously described, each key may be stored and associated with its respective device within secure memory 720 on the client. Once registration is complete for each authentication device, a notification is sent to the server over the secure connection at 1016.

In one embodiment, the key registered with each authentication device is a symmetric key. Thus, identical copies of each key are stored in the secure storage 720 on the client and the secure transaction database 120 on the server 130. In an alternative embodiment, an asymmetric key pair may be generated, where one of the keys is maintained as a public key in the secure transaction database 120 on the server and a private key stored in the secure memory 720 of the client. It should be noted, however, that the underlying principles of the invention are not limited to any particular type of encryption key.

An alternative embodiment is shown in fig. 10C, where the key is generated on the client instead of the server 130. In this embodiment, after receiving a request to register a device with a random challenge at 1011, the plurality of device processing logic of the secure transaction service 101 generates N keys for each of the N devices at 1120. Once generated, the keys are registered on each of the N devices and the registrations are stored in secure memory 720 as previously described at 1013-1014. Once all keys are registered, the secure transaction service 101 provides a notification to the server (to verify the identity of the client) along with the random challenge at 1015. The server 130 may then store the registration in the secure transaction database 120 as described above.

Handling random challenges within a verification framework

System and method of

One embodiment of the present invention improves the manner in which the server generates and processes the random challenge. In one embodiment, the random challenge includes a randomly generated code, such as a cryptographic nonce. In current systems, after the server transmits the random challenge to the client, if the client does not respond within a specified timeout period, the random challenge is no longer valid and the client will receive an error in response to a subsequent authentication attempt (e.g., the user will scan a finger on a fingerprint reader and get rejected).

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

Fig. 11A illustrates one such embodiment within the context of a registration process, and fig. 11B illustrates an embodiment within the context of a verification process. It should be noted, however, that the underlying principles of the invention may be employed in contexts other than those illustrated in FIGS. 11A-11B. For example, the techniques described herein may be used with any method in which time-sensitive code is transmitted from a server to a client.

Turning first to fig. 11A, at 1101, server 130 generates a random challenge and a timeout period indication. In one embodiment, the timeout period includes a period of time during which the random challenge is deemed valid. After the timeout period has elapsed, the random challenge is no longer considered valid by the server 130. In one embodiment, the timeout period is specified only as a point in time when the random challenge will no longer be valid. Once this point in time is reached, the random challenge is invalidated. In another embodiment, the timeout period is specified by using the current timestamp (i.e., the time at which the random challenge was generated by the server 130) and the duration. The secure transaction service 101 may then calculate the timeout by: the duration value is added to the timestamp to calculate the point in time at which the random challenge becomes invalid. It should be noted, however, that the underlying principles of the invention are not limited to any particular technique for calculating the timeout period.

Regardless of how the timeout period is specified or calculated, at 1102, the random challenge and the timeout indication are both transmitted to the secure transaction service 101 (via the browser 104 and the secure transaction plugin 105 in the illustrated example). At 1103, the secure transaction service 101 detects that the random challenge has timed out and is no longer valid based on a timeout indication sent from the server 130. By way of example, the user may have closed his/her client or closed the lid on his/her laptop before completing a series of transactions. If the transaction is one that requires user interaction, the user may simply leave or ignore the message displayed within the GUI.

Upon detecting that the random challenge is no longer valid, the secure transaction service 101 transmits a new random challenge request to the server 130 (via the secure transaction plugin 105 and browser 104 in the illustrated example) at 1104. At 1105, server 130 generates a new random challenge and a new indication of the timeout period. In one embodiment, the timeout period is the same as in operation 1101 or may be modified. For example, the server 130 may increase the duration of the timeout period to reduce data traffic with the client or decrease the duration to increase the level of security provided by the random challenge. At 1106, the new random challenge and the timeout indication are transmitted to the secure transaction service 101.

The remainder of the transaction proceeds as previously described. For example, the secure transaction service opens a secure connection directly to the server at 1107 to perform device registration and key exchange as described above with respect to fig. 4, 10B, or 10C. At 1108, the server 130 identifies the user (e.g., by username or other ID), authenticates the verification device, and generates a key for the device. As mentioned, the key may be a symmetric key or an asymmetric key. At 1109, the key is transmitted to the secure transaction service 101 via a secure connection, and at 1110, the secure transaction service 101 registers the key within the authentication device. At 1111, a notification of registration completion is transmitted to server 130.

Thus, in the embodiment shown in fig. 11A, the key for device registration is generated at the server 130 as in the embodiment shown in fig. 10B. However, the underlying principles of the invention may also be used in embodiments in which one or more keys are generated by the secure transaction service 101 on the client 100, such as the embodiment described above with respect to FIG. 10C.

FIG. 11B illustrates one embodiment of the invention implemented within the context of an authentication process. At 1151, the user enters a specific website URL in the browser 104 and is directed to a web server 131 in the enterprise/web target server 130, the server 130 including the secure transaction servers 132-133. At 1152, a query is sent back to the secure transaction service (via the browser and plug-in) to determine which device or devices are registered on the URL of the website. The secure transaction service 101 queries the secure memory 720 on the client 100 to identify the list of devices sent back to the server 130 at 1153. The server 1154 selects the device to be used for authentication, generates a random challenge and a timeout indication 1154, and sends this information back to the secure transaction service 101 at 1155.

At 1156, the secure transaction service 1156 automatically detects that the random challenge is no longer valid upon reaching the end of the timeout period. As described above, various different techniques may be employed to indicate and detect the end of the timeout period (see FIG. 11A and related text). Upon detecting the random challenge expiration, the secure transaction service 101 transparently (i.e., without user intervention) notifies the server 130 and requests a new random challenge at 1157. In response, at 1158, server 130 generates a new random challenge and a new indication of the timeout period. As mentioned, the new timeout period may be the same as the timeout period previously sent to the client or may be modified. In either case, at 1159, a new random challenge and timeout indication are sent to the secure transaction service 101.

The remainder of the transaction diagram shown in FIG. 11B operates in substantially the same manner as described above (see, e.g., FIG. 5). For example, at 1160, an authentication user interface is displayed (e.g., the user is guided to scan a finger over the fingerprint sensor) and at 1161, the user provides authentication (e.g., scans a finger over the fingerprint scanner). At 1162, the secure transaction service verifies the identity of the user (e.g., compares the verification data collected from the user with data stored in secure memory 720) and encrypts the random challenge using a key associated with the verification device. At 1163, the username (or other ID code) and encrypted random challenge are sent to server 130. Finally, at 1164, the server 130 identifies the user within the secure transaction database 120 using the username (or other ID code) and decrypts/authenticates the random challenge using the key stored in the secure transaction database 120 to complete the authentication process.

For implementing privacy classes within a verification framework

System and method

In one embodiment, multiple privacy preserving categories may be predefined, selected, and/or modified by an end user. The privacy classes may be defined based on a probability that the client may be identified using the revealed information. Under a privacy category having a relatively high privacy level, relatively little information about the client device is revealed to perform the authentication techniques described herein. In one embodiment, a user may choose to disclose as little information as possible when communicating with different servers (i.e., a transaction may be selected for each website or web service that has the lowest privacy impact allowable).

FIG. 12 illustrates a high-level architecture for implementing privacy classes. As shown, the secure transaction service 101 of this embodiment includes privacy management logic 1201 to analyze queries received from the server 130 to obtain client information, such as information related to authentication devices, implement privacy policies in response to such queries, and generate responses containing client information collected based on the particular privacy in use. In one embodiment, the privacy management module 1201 is implemented as a software module executing within the context of the secure transaction service 101. It should be noted, however, that the privacy management module 1201 may be implemented in any manner while still complying with the underlying principles of the invention and may include software, hardware, firmware, or any combination thereof.

The privacy classes utilized by the privacy management logic 1201 may be pre-specified and stored on the client 100 (e.g., within the secure memory 720). In one embodiment, three privacy classes are defined: high privacy impact, medium privacy impact and low privacy impact. Each privacy category may be defined based on the probability that the revealed information is available to uniquely identify the user/client. For example, information revealed for low privacy impact transactions may result in a probability of 10% of uniquely identifying a user or machine over the internet; a 50% probability that a medium privacy-impacting transaction may result in a user or machine being uniquely identified; and a high privacy-impacting transaction may result in a 100% probability of a user or machine being uniquely identified. Various other privacy class levels may be defined while still complying with the underlying principles of the invention.

In one embodiment, each relying party (e.g., each website 131 or service 151) may specify a desired privacy category or other privacy threshold. For example, websites and services that require an enhanced security level may only allow communication according to a high privacy impact category, while other websites/services may allow interaction in the medium privacy impact or low privacy impact categories. In one embodiment, the query for client information sent from server 130 includes attributes that specify which information privacy categories (i.e., low, medium, and high) should be retrieved. Thus, the privacy management logic 1201 will store the information of the highest approved privacy class for each relying party. In one embodiment, whenever a relying party requests information belonging to a higher privacy class than the approved privacy class, the user will be prompted to permanently approve (or reject) the new privacy class for the relying party. In response to the user's approval, the privacy management logic may store a new association between the relying party (e.g., identified via a URL) and the new privacy class.

While user preferences 1230 are applied directly to the privacy management logic in FIG. 12 for simplicity, it should be noted that the user may specify the preferences via a browser-based graphical user interface (not shown). In such a case, the user would enter the privacy settings via the browser window. The secure transaction plug-in 105 then stores the new settings to the privacy management logic 1201, or to a configuration data file accessible through the privacy management logic 1201. In short, the underlying principles of the invention are not limited to any particular mechanism for configuring privacy management logic.

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

Fig. 13 illustrates a series of transactions for providing information to a requestor using defined privacy classes. At 1301, server 130 generates a notification containing the client device information query. At 1302, the query is sent to the client and ultimately received by the secure transaction service 101. At 1303, privacy management logic of the secure transaction service determines privacy classes of responses and collects necessary information. As described above, N different privacy class levels may be defined and the secure transaction service 101 may select one privacy class level that simultaneously reveals as little information about the client as desired by the requestor. At 1304, the collected information is sent to the server 130, and at 1305 the server uses the information for one or more subsequent transactions with the client.

For implementing a verification framework using transaction signatures

System and method

One embodiment of the present invention employs transactions signed on a secure transaction server such that no transaction state needs to be maintained on the server to maintain a session with the client. In particular, transaction details, such as transaction text, may be sent to the client signed by the server. The server may then verify that the signed transaction response received by the client is valid by verifying the signature. The server need not permanently store transactional content, which would take up a lot of storage space for a large number of clients and would open up the possibility of denying service type attacks on the server.

One embodiment of the present invention is shown in FIG. 14, which illustrates a website or other network service that initiates a transaction with a client 100 (1401). For example, the user may have selected items on the website to purchase and may be ready for settlement and payment. In the illustrated example, the website or service 1401 hands the transaction off to a secure transaction server 1402, which secure transaction server 1402 includes signature processing logic 1403 for generating and verifying a signature (as described herein) and verification logic for performing client verification 1404 (e.g., using the previously described verification techniques).

In one embodiment, the verification request sent from the secure transaction server 1402 to the client 100 includes a random challenge such as a cryptographic nonce (as described above), transaction details (e.g., specific text presented to complete the transaction), and a signature generated by the signature processing logic 1403 using a private key (known only to the secure transaction server) for the random challenge and transaction details.

Once the above information is received by the client, the user may receive an indication that authentication is required to complete the transaction. In response, the user may scan a finger, snap a picture, speak into a microphone, or perform any other type of authentication permitted by a given transaction, for example, on a fingerprint scanner. In one embodiment, once the user has successfully authenticated on the client 100, the client transmits back to the server: (1) a random challenge and transaction text (both previously provided to the client by the server), (2) authentication data that verifies that the user successfully completed authentication, and (3) a signature.

The verification module 1404 on the secure transaction server 1402 may then confirm that the user has been correctly verified and the signature processing logic 1403 uses the private key to regenerate the signature for the random challenge and transaction text. If the signature matches the signature sent by the client, the server may verify that the transaction text is the same as the text originally received from the website or service 1401. Storage and processing resources are conserved because the secure transaction server 1402 is not required to permanently store transaction text (or other transaction data) within the secure transaction database 120.

Exemplary data processing apparatus

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

As shown in fig. 15, computer system 1500, in the form of a data processing system, includes one or more buses 1550, which couple processing system 1520, power supply 1525, memory 1530, and non-volatile memory 1540 (e.g., hard disk drives, flash memory, phase Change Memory (PCM), etc.). The one or more buses 1550 may be connected to each other through various bridges, controllers and/or adapters as is well known in the art. The processing system 1520 may retrieve the one or more instructions from the memory 1530 and/or the non-volatile memory 1540 and execute the instructions to perform the operations described above. The bus 1550 interconnects the above-described components together and also interconnects those components to an optional docking device 1560, a display controller and display device 1570, input/output devices 1580 (e.g., a NIC (network interface card), cursor control (e.g., a mouse, touch screen, touch pad), keyboard, etc.), and optionally one or more wireless transceivers 1590 (e.g., bluetooth, wiFi, infrared, etc.).

FIG. 16 is a block diagram illustrating an exemplary data processing system that may be used in some embodiments of the invention. For example, data processing system 1600 may be a handheld computer, personal Digital Assistant (PDA), mobile telephone, portable gaming system, portable media player, tablet computer, or handheld computing device that may include a mobile telephone, media player, and/or gaming system. As another example, data processing system 1600 may be an embedded processing device within a network computer or another device.

An exemplary architecture for data processing system 1600 may be used for the mobile device described above, according to one embodiment of the invention. Data processing system 1600 includes a processing system 1620, which processing system 1620 may include one or more microprocessors and/or systems on integrated circuits. Processing system 1620 is coupled to memory 1610, power supply 1625 (which includes one or more batteries), audio input/output 1640, display controller and display device 1660, optional input/output 1650, one or more input devices 1670, and one or more wireless transceivers 1630. It is to be appreciated that additional components not shown in FIG. 16 may also be part of data processing system 1600 in some embodiments of the present invention, and that fewer than the number of components shown in FIG. 16 may be used in some embodiments of the present invention. Further, it should be understood that one or more buses, not shown in FIG. 16, may be used to interconnect the various components as is well known in the art.

Memory 1610 may store data and/or programs that are executed by data processing system 1600. Audio input/output 1640 may include a microphone and/or speaker, for example, to play music and/or provide telephone functionality through the speaker and microphone. The display controller and display device 1660 can include a Graphical User Interface (GUI). A wireless (e.g., RF) transceiver 1630 (e.g., a WiFi transceiver, an infrared transceiver, a bluetooth transceiver, a wireless cellular telephone transceiver, etc.) may be used for communicating with other data processing systems. The one or more input devices 1670 allow a user to provide input to the system. These input devices may be a keypad, keyboard, touch panel, multiple touch panels, etc. Optional other input/output 1650 may be a connector of a docking device.

Embodiments of the invention may include various steps as described above. The steps may be implemented with machine-executable instructions, which cause a general-purpose or special-purpose processor to perform certain steps. Alternatively, these steps may be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

Elements of the present invention may also be provided as a machine-readable medium for storing the machine-executable program code. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, or other type of media/machine-readable medium suitable for storing electronic program code.

Throughout the foregoing description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without some of these specific details. For example, it will be 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 invention are not limited to mobile computing implementations. Indeed, any type of client or peer-to-peer data processing device may be used in some embodiments, including for example, desktop or workstation computers. Therefore, the scope and spirit of the present invention should be judged in terms of the claims which follow.

Claims (18)

1. A method, comprising:

receiving a policy to identify a set of acceptable authentication functions, wherein the policy to identify the set of acceptable authentication functions is received by a client in response to sending a registration request of the client;

determining a set of client authentication functions for the client by identifying, by the client, a set of authentication devices on the client that correspond to the set of client authentication functions based on a secure storage of the client;

filtering, by the client, the set of acceptable authentication functions based on the privacy preference level of the user of the client and the determined set of client authentication functions to obtain a filtered set of one or more authentication functions for authenticating the user, wherein the filtering the set of acceptable authentication functions is performed in registering the set of authentication devices with a network server through one or more random challenges; and

authenticating the user over the network using the filtered set of one or more authentication functions, comprising: a set of keys is generated and sent for each of the set of filtered one or more authentication functions via the network.

2. The method of claim 1, wherein the policy comprises a set of authentication device types and/or classes deemed acceptable by the network server.

3. The method of claim 1, further comprising:

displaying one or more of the set of filtered validation functions in a Graphical User Interface (GUI);

querying the user to select or prefer one or more of a verification function from the GUI; and

a filtered list of user-specified authentication functions is generated based on user input to the query.

4. The method of claim 1, wherein the authentication function comprises a fingerprint sensor.

5. The method of claim 1, wherein the authentication function comprises a voice authentication function.

6. The method of claim 1, wherein the authentication function comprises a smart card.

7. The method of claim 1, wherein the verification function comprises a Trusted Platform Module (TPM).

8. The method of claim 1, wherein the filtering of the set of acceptable validation functions is further based on a validation function priority.

9. A system, comprising:

a client that receives a policy to identify a set of acceptable authentication functions and determines a set of client authentication functions, wherein the policy to identify the set of acceptable authentication functions is received by the client in response to a registration request that is sent to the client, the client comprising a secure store based on which the client identifies a set of authentication devices on the client that correspond to the set of client authentication functions, the client further comprising a policy filter that filters the set of acceptable authentication functions based on a privacy preference level of a user of the client and the determined set of client authentication functions to obtain a filtered set of one or more authentication functions for authenticating the user of the client, wherein the filtering the set of acceptable authentication functions is performed in the process of registering the set of authentication devices with a network server through a random challenge; and

the client authenticating the user over the network using the filtered set of one or more authentication functions, wherein using the filtered set of one or more authentication functions to authenticate the user comprises: a set of keys is generated and sent for each of the set of filtered one or more authentication functions via the network.

10. The system of claim 9, wherein the policy comprises a set of authentication device types and/or classes deemed acceptable by the network server.

11. The system of claim 10, further comprising:

the client displaying one or more of the set of filtered validation functions in a Graphical User Interface (GUI);

querying the user to select or prefer one or more of verification functions from the GUI; and

a filtered list of user-specified authentication functions is generated based on user input to the query.

12. The system of claim 9, wherein the authentication function comprises a fingerprint sensor.

13. The system of claim 9, wherein the authentication function comprises a voice authentication function.

14. The system of claim 9, wherein the authentication function comprises a smart card.

15. The system of claim 9, wherein the verification function comprises a Trusted Platform Module (TPM).

16. A machine-readable medium having program code stored thereon, which when executed by a machine, causes the machine to perform operations comprising:

receiving a policy identifying a set of acceptable authentication functions, wherein the policy identifying the set of acceptable authentication functions is received by a client in response to sending a registration request for the client;

determining a set of client authentication functions for the client by identifying, by the client, a set of authentication devices on the client that correspond to the set of client authentication functions based on secure storage of the client;

filtering, by the client, the set of acceptable authentication functions based on the privacy preference level of the user of the client and the determined set of client authentication functions to obtain a filtered set of one or more authentication functions for authenticating the user of the client, wherein the filtering the set of acceptable authentication functions is performed in registering the set of authentication devices with a network server through one or more random challenges; and

authenticating the user over the network using the filtered set of one or more authentication functions, comprising: a set of keys is generated and sent for each of the set of filtered one or more authentication functions via the network.

17. The machine-readable medium of claim 16, wherein the policy comprises a set of authentication device types and/or classes deemed acceptable by the network server.

18. The machine-readable medium of claim 16, comprising additional program code to cause the machine to perform the operations of:

displaying one or more of the set of filtered validation functions in a Graphical User Interface (GUI);

querying the user to select or prefer one or more of verification functions from the GUI; and

a filtered list of user-specified authentication functions is generated based on user input to the query.