HK1234909B - Enhanced security for registration of authentication devices - Google Patents

Description

Enhanced security for verifying device registration

Background Art

Technical Field

The present invention generally relates to the field of data processing systems. More particularly, the present invention relates to an apparatus and method for securely registering an authentication device.

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. ,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”; and Serial No. 13/730,795 entitled “System and Method for Implementing Privacy Classes Within an Authentication Framework.” 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”).

In short, in the authentication technology described in these co-pending applications, a user registers with an authentication device (or authenticator) on a client device, such as a biometric device (e.g., a fingerprint sensor). When a user registers with a biometric device, biometric reference data is captured by the authentication device's biometric sensor (e.g., by swiping a finger, taking a photo, recording a sound, etc.). The user can then register 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 can then authenticate to those servers using the data exchanged during the registration process (e.g., encryption keys pre-set to 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 a user) can be maintained locally on the user's authentication device to protect the user's privacy. The '504 application describes a variety of additional techniques, including techniques for designing composite authenticators, intelligently generating authentication assurance levels, using non-intrusive user authentication, transferring authentication data to new authentication devices, augmenting authentication data with client risk data, adaptively applying authentication policies, and creating circles of trust, among others.

BRIEF DESCRIPTION OF THE DRAWINGS

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

1A and 1B illustrate two different embodiments of a secure authentication system architecture.

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

3A and 3B illustrate an embodiment of secure transaction confirmation using a secure display.

FIG4 shows an embodiment of the present invention for registering with a relying party;

FIG5 is a transaction diagram illustrating how a registration operation with a query strategy is implemented in one embodiment of the present invention;

FIG6 illustrates one embodiment of an architecture for registration with enhanced security;

FIG7 illustrates one embodiment of a method for secure registration;

8A and 8B illustrate different embodiments of methods for secure registration;

FIG9 illustrates another embodiment of a method of sending a password from a user to a relying party;

FIG10 illustrates another embodiment of a method for registering using a user's existing credentials; and

11 and 12 illustrate exemplary embodiments of computer systems for implementing embodiments of the present invention.

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 authentication functionality (such as biometric devices or PIN entry). These devices are sometimes referred to herein as "tokens," "authentication devices," or "authenticators." Although some embodiments focus on facial recognition hardware/software (e.g., a camera and associated software for recognizing a user's face and tracking the user's eye movements), some embodiments may utilize additional biometric devices, including, for example, fingerprint sensors, voice recognition hardware/software (e.g., a microphone and associated software for recognizing a user's voice), and optical recognition functionality (e.g., an optical scanner and associated software for scanning a user's retina). User authentication functionality 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 for cryptographic operations.

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 physically conducting a transaction 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 a secure transaction server implemented on behalf of that entity (which can perform the underlying authentication techniques described herein). The secure transaction server can be owned and/or under the control of the relying party, or can be under the control of a third party that provides secure transaction services to the relying party as part of a business arrangement.

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

Exemplary system architecture

Figures 1A and 1B show two embodiments of a system architecture including a client-side component and a server-side component for verifying a user. The embodiment shown in Figure 1A uses an architecture based on a web browser plug-in to communicate with a website, while the embodiment shown in Figure 1B does not require a web browser. Various techniques described herein, such as registering a user with a verification device, registering a verification 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 illustrate the operation of several embodiments described below, the same basic principles can be easily implemented on the system shown in Figure 1B (for example, by deleting the browser plug-in 105, which acts as an intermediary for communicating between the server 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 authenticating 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 forms (such as PIN authentication). The authentication device may use a trusted platform module (TPM), a smart card, or a secure element for cryptographic operations and key storage.

The 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 the 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 keys 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 the server 130 via a network (such as the Internet).

As discussed below, 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 by a web server 131 within a secure enterprise or web destination 130 (sometimes referred to hereinafter as "server 130"). In response to detecting such a tag, secure transaction plugin 105 may forward the transaction to secure transaction service 101 for processing. In addition, for certain types of transactions (e.g., such as secure key exchange), 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 120, 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 120 on the server side.

Device registration and transaction confirmation

One embodiment of the present invention employs secure transaction confirmation technology during registration. Therefore, various registration operations and secure transaction operations will be initially described in conjunction with Figures 2 to 5, followed by a detailed description of an embodiment of the present invention for secure registration verification.

Figure 2 illustrates a series of transactions for registering an authentication device. 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 storage 120 of the client 100 and in 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, discussed below, an asymmetric key may be used. In this embodiment, a public key may be stored by the secure transaction server 132-133, and a second, related private key may be stored in the secure storage 120 on the client. Furthermore, in another embodiment, the key may be generated on the client 100 (e.g., by the authentication device or authentication 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.

A secure key provisioning protocol, such as the Dynamic Symmetric Key Provisioning Protocol (DSKPP), may be used to share keys with the client via a secure communication channel (see, for example, Request for Comments (RFC) 6063). However, the underlying principles of the invention are not limited to any particular key provisioning protocol.

Turning to the specific details shown in FIG2 , once user registration or user verification is complete, server 130 generates a randomly generated challenge (e.g., a cryptographic random number) that the client must present during device registration. This random challenge is valid for a limited period of time. The secure transaction plugin detects the random challenge and forwards it to secure transaction service 101. In response, secure transaction service initiates an out-of-band session (e.g., an out-of-band transaction) with server 130 and communicates with server 130 using a key provisioning protocol. Server 130 locates the user using the username, verifies the random challenge, verifies the device's verification code if it has already been sent, and creates a new entry for the user in secure transaction database 120. It also generates a key, writes the key to database 120, and sends the key back to secure transaction service 101 using a key provisioning protocol. Once complete, the authenticating device and server 130 share the same key if symmetric keys are used, or different keys if asymmetric keys are used.

Figure 3A shows a secure transaction confirmation for a browser-based implementation. Although a browser-based implementation is shown, the same basic principles can be implemented using a standalone application or a mobile device application.

This secure transaction confirmation is designed to provide enhanced security for certain types of transactions (e.g., financial transactions). In the illustrated embodiment, the user confirms each transaction before conducting it. Using the illustrated technique, the user confirms exactly what transaction they want to conduct and actually conducts the transaction they see in window 301 of the graphical user interface (GUI). In other words, this embodiment ensures that a "man in the middle" (MITM) or "man in the browser" (MITB) cannot modify the transaction text to conduct a transaction that the user has not confirmed.

In one embodiment, the secure transaction plug-in 105 displays a window 301 in the browser environment to display transaction details. The secure transaction server 101 periodically (e.g., at random intervals) verifies that the text displayed in the window has not been tampered with by anyone. In various embodiments, the verification device includes a trusted user interface (e.g., an API for providing a trusted UI compliant with the GlobalPlatform organization).

The following example will help highlight the operation of this embodiment. A user selects an item to purchase from a merchant website and selects "Checkout." The merchant website sends the transaction to a service provider (e.g., PayPal) that has secure transaction servers 132-133 that implement one or more embodiments of the present invention described herein. The merchant website authenticates the user and completes the transaction.

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

In a browser-based implementation, the secure transaction plug-in 105 displays a window 301 with the transaction details to the user (e.g., in a browser environment) and asks the user to provide verification to confirm the transaction. In embodiments that do not use a browser or plug-in, the secure transaction service 101, application 154 ( FIG. 1B ), or verification device 110 may display window 301. The secure transaction service 101 starts a timer and verifies the contents of window 301 being 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 301 (e.g., generates a hash of the details and verifies the accuracy of the content by comparing it to a hash of the correct content). If it is detected that the content has been tampered with, the generation of the confirmation token/signature is blocked.

After the user provides valid authentication data (e.g., by swiping a finger across a fingerprint sensor), the authentication device authenticates the user and generates a cryptographic signature (sometimes called a "token") using the transaction details and a random challenge (i.e., a signature calculated from the transaction details and a random number). This allows secure transaction servers 132-133 to ensure that the transaction details have not been modified between the server and the client. Secure transaction service 101 sends the generated signature and username to secure transaction plugin 105, which forwards the signature to secure transaction servers 132-133. Secure transaction servers 132-133 use the username to identify the user and verify the signature. If authentication is successful, a confirmation message is sent to the client and the transaction is processed.

One embodiment of the present invention implements a query strategy in which a secure transaction server transmits a server policy to a client, indicating the authentication capabilities accepted by the server. The client then analyzes the server policy to identify a subset of authentication capabilities that the server supports and/or that the user has indicated they wish to use. The client then registers and/or authenticates the user using the subset of authentication tokens that matches the provided policy. Consequently, there is less impact on the client's privacy because the client is not required to transmit detailed information about its authentication capabilities (e.g., all of its authentication devices) or other information that could be used to uniquely identify the client.

By way of example and not limitation, a client may include a variety of user authentication capabilities, such as a fingerprint sensor, voice recognition, facial recognition, eye/optical recognition, PIN verification, and so on. However, for privacy reasons, a user may not wish to reveal all details of their capabilities to the requesting server. Therefore, using the techniques described herein, a secure transaction server may transmit a server policy to the client indicating that it supports (for example) fingerprint, optical, or smart card authentication. The client may then compare the server policy with its own authentication capabilities and select one or more available authentication options.

One embodiment of the present invention utilizes transaction signing on a secure transaction server, allowing the client session to be maintained without maintaining any transaction state on the server. Specifically, transaction details, such as the transaction text, displayed in window 301 can be sent to the client, where they are signed by the server. The server can then verify the validity of the signed transaction response received by the client by verifying the signature. The server does not need to permanently store the transaction content, as doing so would consume significant storage space for a large number of clients and could lead to the possibility of a denial-of-service attack on the server.

One embodiment of the present invention is illustrated in FIG3B , which shows a website or other network service 311 initiating a transaction with a client 100. For example, a user may have selected items to purchase on the website and may be ready to check out and pay. In the illustrated example, the website or service 311 submits the transaction to a secure transaction server 312, which includes signature processing logic 313 for generating and verifying signatures (as described herein) and verification logic 314 for performing client verification (e.g., using the verification techniques previously described).

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

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

The verification module 314 on the secure transaction server 312 can then confirm that the user has been correctly authenticated, and the signature processing logic 313 uses the private key to regenerate a signature on the random challenge and the transaction text. If the signature matches the signature sent by the client, the server can verify that the transaction text is the same as when it was originally received from the website or service 311. This saves storage and processing resources because the secure transaction server 312 does not need to permanently store the transaction text (or other transaction data) in the secure transaction database 120.

Figure 4 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 401, which is used to analyze the policy provided by the server 130 and identify a subset of authentication functions to be used for registration and/or authentication. In one embodiment, policy filter 401 is implemented as a software module that executes within the context of the secure transaction service 101. However, it should be noted that policy filter 401 can be implemented in any manner while still consistent with the underlying principles of the present invention and may include software, hardware, firmware, or any combination thereof.

The particular implementation shown in FIG4 includes a secure transaction plug-in 105 for establishing communication with a secure enterprise or web destination 130 (sometimes referred to simply as "server 130" or "relying party" 130) using the techniques previously discussed. For example, the secure transaction plug-in can identify specific HTML tags inserted into the HTML code by the web server 131. Thus, in this embodiment, the server policy is provided to the secure transaction plug-in 105, which forwards it to the secure transaction service 101, which implements the policy filter 401.

The policy filter 401 can determine the client authentication capabilities by reading the capabilities from the client's secure storage area 420. As previously discussed, the secure storage 420 can include a repository of all client authentication capabilities (e.g., identification codes for all authentication devices). If the user has registered the user with their authentication device, the user's registration data is stored in the secure storage 420. If the client has registered authentication devices with the server 130, the secure storage can also store the encryption secret key associated with each authentication device.

Using the authentication data extracted from the secure storage device 420 and the policy provided by the server, the policy filter 401 can then identify a subset of authentication functions to be used. Depending on the configuration, the policy filter 401 can identify the complete list of authentication functions supported by both the client and the server, or can identify a subset of the complete list. For example, if the server supports authentication functions A, B, C, D, and E, and the client has authentication functions A, B, C, F, and G, the policy filter 401 can identify the entire subset of common authentication functions to the server: A, B, and C. Alternatively, if a higher level of privacy is desired, as indicated by the user preferences 430 in Figure 4, a more limited subset of authentication functions can be identified to the server. For example, the user can indicate that only a single common authentication function (e.g., one of A, B, or C) should be identified to the server. In one embodiment, the user can establish a prioritization scheme for all authentication functions of the client 100, and the policy filter can select the highest priority authentication function (or prioritized group of N authentication functions) shared by both the server and the client.

Depending on which operation (registration or authentication) was initiated by the server 130, the secure transaction service 130 performs the operation on the selected authentication device subset (110 to 112) and sends the operation response back to the server 130 via the secure transaction plug-in 105, as shown in Figure 4. Alternatively, in an embodiment that does not rely on the plug-in 105 component of the web browser, this information can be passed directly from the secure transaction service 101 to the server 130.

FIG5 shows a transaction diagram illustrating additional details of an exemplary series of registrations using a query strategy transaction. In the illustrated embodiment, the user has not previously registered the device with the server 130. Therefore, at 501, the user may enter a username and password as an initial, one-time authentication step, which are forwarded to the server 130 via the client browser 104 at 502. However, it should be noted that a username and password are not necessarily required in order to comply with the underlying principles of the present invention.

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

At transaction 507, the secure transaction service 101 compares the server policy with the client's capabilities (and possibly other information, such as a device priority scheme and/or user preferences, as described above) to obtain a filtered list of authentication capabilities. The filtered list of devices (102) then generates transaction key pairs 508 and 509 and provides the public portions of these key pairs to the secure transaction service 101, which in turn sends these public portions back to the server 130 as a registration response at 510. The server authenticates the authentication device and stores the public key in the secure transaction database. Token authentication, as employed herein, is the process of confirming the identity of the authentication device during registration. It allows the server 130 to cryptographically ensure that the device reported by the client is actually the device it claims to be.

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

The techniques described above for filtering server policies at the client can be implemented at various stages in the series of transactions described above (e.g., during device discovery, device registration, device provisioning, user authentication, etc.). That is, the underlying principles of the invention are not limited to the specific set of transactions and specific transaction order set forth in FIG.

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

Registering devices with enhanced security

Various organizations, including the European Central Bank (ECB) and the Federal Financial Institutions Examination Committee (FFIEC), recommend the use of strong authentication for financial transactions. Furthermore, the European Network and Information Security Agency (ENISA) recently proposed that financial institutions should treat all client devices as if they were compromised. While the aforementioned secure transaction confirmation methods provide adequate protection even in the event of a client compromise (as long as the authentication device is not compromised), the aforementioned registration techniques for registering authentication devices over a network (even though these registration techniques are generally secure) do not operate under the assumption that the client device is compromised and, therefore, may be vulnerable to malware on the device.

To enhance security during device registration, one embodiment of the present invention includes using an out-of-band communication channel to transmit a password from a relying party to a user, or vice versa. This out-of-band communication channel is used only once to register the authenticator. The authenticator can then be used for subsequent authentication or transaction confirmation steps without using this channel. Additionally, secure transaction confirmation techniques, including the use of a secure display (e.g., such as described above in connection with Figures 3A and 3B), can be employed to allow the user to confirm the password sent via out-of-band transmission.

6 illustrates an exemplary client device 690 that includes or is connected to an authenticator 600 that includes an enhanced security registration module 604 for implementing the enhanced security techniques described herein. The illustrated embodiment also includes an authentication engine 610 having an assurance calculation module 606 for generating an assurance level that a legitimate user possesses the client device 600. For example, explicit and non-intrusive authentication results 605 are collected using explicit user authentication devices 620-621, one or more sensors 643 (e.g., a location sensor, an accelerometer, etc.), and other data related to the current authentication state of the client device 600 (e.g., such as the time since the last explicit authentication).

Explicit authentication can be performed, for example, using biometric technology (e.g., swiping a finger on a fingerprint authentication device) and/or by the user entering a password. Non-invasive authentication techniques can be performed based on data such as the current location of the client device 600 detected (e.g., via a GPS sensor), other user behaviors sensed (e.g., measuring the user's gait using an accelerometer), and/or variables such as the time since the last explicit authentication. Regardless of how the authentication results 605 are generated, the assurance calculation module 606 always uses these results to determine an assurance level indicating the likelihood that the legitimate user 650 possesses the client device 600. The secure communication module 613 establishes secure communication with the relying party 613 (e.g., using a secure encryption key, as discussed herein). The public/private key pair or symmetric key can be stored in a secure storage device 625, which can be implemented as a cryptographically secure hardware device (e.g., a security chip) or can be implemented using any combination of secure hardware and software.

As shown in FIG6 , client device 690 may include various additional components, such as a web browser 691, various mobile applications 692, and other hardware/software components. In some embodiments described herein, it is assumed that authenticator 600 has been compromised, necessitating the secure registration techniques described herein. However, this assumption may have no impact on the remaining hardware/software components in client device 690, which may operate normally without affecting the basic principles of the present invention.

One embodiment of a method for performing registration with enhanced security is shown in FIG7 . At 701 , a user attempts to register an authentication device with an online service (such as a relying party with a secure transaction service, as described herein). For example, the user may have purchased a new device with a new authentication device/functionality (such as a new fingerprint authenticator). Alternatively, the user may have installed a new authenticator on an existing client device and/or may be using an existing authenticator to access an online service for the first time.

At 702, in response to the authentication attempt, a password is sent from the service to the user or from the user to the service via an out-of-band communication channel. For example, in one embodiment, the password is generated using a hash of the public key generated during the registration process (see, e.g., transaction 510 in FIG. 5 ), and then sent via the out-of-band channel. In a specific embodiment, a hash operation (such as a SHA-256, SHA-1, or SHA-3 hash operation) is applied to the public key to generate a password comprising a hash value.

In one embodiment, the password is generated by the relying party and sent to the user via an out-of-band channel (e.g., via standard mail or email, etc.). In another embodiment, the password is securely displayed on the client device using a secure transaction confirmation operation; the user can then copy the securely displayed password (e.g., a public key hash) and send it to the relying party via an out-of-band communication channel.

Various types of out-of-band channels may be employed. As used herein, an "out-of-band" channel is a communication channel of a different type than the communication channel used for standard registration and standard authentication. In one embodiment, the out-of-band channel comprises a non-email communication channel. For example, the relying party may use a postal service to mail the hash value to a known address of the user. In another embodiment, the out-of-band channel may comprise an electronic channel such as email, text messaging (e.g., Short Message Service (SMS)), instant messaging, or any other type of communication channel that uses a destination address associated with the user that is known to the relying party.

Regardless of which out-of-band channel is used, at 703, the registration is verified using a password (e.g., a public key hash received via the out-of-band channel). For example, in embodiments where the public key hash is securely displayed on the client, the user submits the public key hash displayed on the secure display via the out-of-band channel. In embodiments where a code is sent from the relying party to the client via the out-of-band channel, the user can confirm the password on the client (e.g., via a secure transaction confirmation operation). In one embodiment, the secure transaction confirmation techniques described herein (see, for example, Figures 3A and 3B, and associated text) can be used to securely display the public key hash on a display for user verification and/or allow the user to copy the public key hash and send it back to the relying party via the out-of-band channel.

If verification is determined to be successful at 704 (e.g., if the public key hash received as part of registration 701 matches the public key hash sent via the out-of-band channel), then registration is confirmed at 705. However, if the public key hashes do not match, or if a threshold amount of time has passed before the public key hash is received via the out-of-band channel, then registration is denied at 706.

In one embodiment, various other data may be displayed for user verification during the registration process. For example, in one embodiment, a unique code associated with the user's account on the relying party is also displayed (and verified by the user) using transaction confirmation technology and secure display technology. This unique code that associates the user with the relying party is sometimes referred to herein as an "AppID." In some embodiments where the relying party offers multiple online services, a user may have multiple AppIDs with a single relying party (the relying party providing one AppID for each service).

A variety of different implementations may be employed, including post-registration embodiments where the relying party has advance knowledge of the user, pre-registration embodiments where the user registers with the relying party before the relying party identifies the user (e.g., in accordance with applicable Know Your Customer (KYC) guidelines), and hybrid embodiments involving quasi-simultaneous registration (e.g., using an existing code known to both the user and the relying party).

1. Post-registration

FIG8A illustrates an embodiment of a post-registration process in which a relying party is aware of a user. For example, the relying party may have identified the user based on Know Your Customer (KYC) guidelines before the user performs registration. At 801, the user is identified by the relying party (e.g., using KYC), and the relying party creates an electronic record for the user in its database.

At 802, a user visits a website of a relying party, and the relying party's web application detects that the user's device is equipped with enhanced authentication capabilities (eg, such as those described herein for remote authentication over a network).

At 803, the user initiates registration with the relying party. For example, a series of transactions such as those shown in FIG5 may be performed to generate a public/private key pair for the authenticator. At 804, the relying party sends a password (e.g., a hash of the registered public key) to the user using an out-of-band method (e.g., postal mail, email, SMS, etc.).

At 805, the relying party triggers a secure transaction confirmation operation. For example, in one embodiment, a message may be displayed to the user with a password and possibly a unique account ID code, asking the user to confirm this information (e.g., "I confirm that the public key hash received via the out-of-band method is identical to the public key hash displayed on my secure display at this time, and that this public key hash has been registered to the AppID shown there."). At 806, the user may then accept the transaction if the password and ID code match the password and ID code displayed within the secure display, thereby confirming the registration at 807. If the user rejects the transaction at 806 (e.g., because the displayed information does not match the password and/or ID code), the registration is rejected at 808.

FIG8B illustrates another embodiment of a post-registration process in which a relying party is aware of a user. Similarly, the relying party may have identified the user based on Know Your Customer (KYC) guidelines before the user performs registration. At 811, the user is identified by the relying party (e.g., using KYC), and the relying party creates an electronic record for the user in its database.

At 812, the user visits a relying party's website, and the relying party's web application detects that the user device is equipped with enhanced authentication capabilities (eg, such as those described herein for remote authentication via a network).

At 813, the user agrees to register with the relying party. For example, a series of transactions such as that shown in FIG. 5 may be performed to generate a public/private key pair for the validator. At 804, the relying party triggers a secure transaction confirmation operation. For example, in one embodiment, a message may be displayed to the user, possibly with a unique account ID code, requesting the user to confirm this information (e.g., "I confirm registration and will send the public key hash shown below signed via an authenticated out-of-band channel").

At 815, the user transmits the public key hash shown on the secure display via an authenticated out-of-band channel (e.g., a signed letter). At 816, the relying party verifies the public key hash sent in 815 using the public key hash received in step 813 and may then accept the registration at 817. If the values do not match, the relying party rejects the registration at 818.

2. Pre-registration

Figure 9 illustrates one embodiment of a process in which a user registers with a relying party before the relying party identifies the user (e.g., according to corresponding KYC guidelines). At 901, the user accesses the website of the relying party, and the relying party's web application detects that the user's device is equipped with enhanced authentication capabilities (e.g., such as those described herein for remote authentication via a network).

At 902, the user initiates registration with the relying party. For example, a series of transactions such as those shown in FIG. 5 may be performed to generate a public/private key pair for the authenticator. At 903, the relying party triggers a transaction confirmation operation in response to the registration request. For example, a message may be displayed on a secure display requesting confirmation that the user wishes to register with the relying party (e.g., "I would like to register with <relying party> and will undergo KYC later"). In addition, the secure display may display a code (e.g., a public key hash) and the AppID. Note that this code may or may not be a "secret" code.

At 904, the user sends the code to the relying party using a verified out-of-band mechanism. For example, in one embodiment, the user may physically take a printout of the hash to a branch of the relying party to present it as part of the KYC confirmation. Alternatively, the user may enter the code into a form as part of the identification process. Alternatively, the user may send the code via email, postal mail, SMS, or any other type of verified out-of-band channel.

At 905, the relying party performs code verification (e.g., comparing the public key hash to a hash value calculated from the public key received from the user during registration). If a match is confirmed at 906, then the registration is confirmed at 907. If a match is not confirmed, then the registration is denied at 908.

3. Quasi-simultaneous registration

Some users already have multiple credentials, such as an electronic ID card with an identity certificate. Utilize this identity certificate, the electronic ID card as shown in Figure 10 can be used to replace the out-of-band method with an electronic method.

At 1001 , a user visits a website of a relying party, and the relying party's web application detects that the user's device is equipped with enhanced authentication capabilities (eg, such as those described herein for remote authentication over a network).

At 1002, the user agrees to register with the relying party. For example, a series of transactions such as that shown in FIG. 5 may be performed to generate a public/private key pair for the authenticator. At 1003, the relying party triggers a transaction confirmation operation for the registration request. For example, a secure display confirming the transaction may display a message requesting confirmation that the user wishes to register with the relying party using existing credentials (e.g., "I would like to register with <relying party> and will use identification based on my electronic ID card"). In addition, the secure display may display a password (e.g., a public key hash) and an AppID to the user.

At 1004, the user creates a verification object (e.g., a document or binary file) containing the AppID and a public key hash, and signs the object using a private key associated with an existing credential (e.g., an identity certificate on the user's electronic ID card). At 1005, the relying party verifies the signed object and extracts the identity data from the credential (e.g., identity certificate). In addition, the relying party compares the public key hash extracted from the signed object with a hash value calculated from the public key received from the user during registration. If the two match at 1006, the registration is confirmed at 1007. If not, the registration is rejected at 1008.

Exemplary data processing apparatus

FIG11 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 FIG11 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 or more components may also be used with the present invention.

As shown in FIG11 , a computer system 1100, which is a form of data processing system, includes a bus 1150 coupled to a processing system 1120, a power supply 1125, a memory 1130, and a non-volatile memory 1140 (e.g., a hard drive, flash memory, phase change memory (PCM), etc.). The bus 1150 can be connected to each other via various bridges, controllers, and/or adapters as are well known in the art. The processing system 1120 can retrieve instructions from the memory 1130 and/or the non-volatile memory 1140 and execute these instructions to perform the operations described above. The bus 1150 interconnects the above components and also interconnects those components to an optional base 1160, a display controller and display device 1170, an input/output device 1180 (e.g., a NIC (network interface card), a cursor control (e.g., a mouse, touch screen, touchpad, etc.), a keyboard, etc.), and an optional wireless transceiver 1190 (e.g., Bluetooth, WiFi, infrared, etc.).

Figure 12 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 1200 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 1200 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 1200 can be used for the mobile device described above. The data processing system 1200 includes a processing system 1220, which may include one or more microprocessors and/or systems on integrated circuits. The processing system 1220 is coupled to a memory 1210, a power supply 1225 (which includes one or more batteries), an audio input/output 1240, a display controller and a display device 1260, an optional input/output 1250, an input device 1270, and a wireless transceiver 1230. It should be understood that in certain embodiments of the present invention, other components not shown in Figure 12 may also be part of the data processing system 1200, and in certain embodiments of the present invention, fewer components than shown in Figure 12 may be used. In addition, it should be understood that one or more buses not shown in Figure 12 can be used to interconnect various components as is known in the art.

Memory 1210 can store data and/or programs for execution by data processing system 1200. Audio input/output 1240 can include a microphone and/or speaker to (for example) play music, and/or provide telephone functionality through the speaker and microphone. Display controller and display device 1260 can include a graphical user interface (GUI). Wireless (e.g., RF) transceiver 1230 (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 1270 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 1250 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 (23)

1. A method for registering a verification device with enhanced security, the method comprising: Receive requests from the user's registration authenticator at the dependent side; Sending code from the user to the dependent party via a verified out-of-band communication channel; and The code is used to verify the user's identity, and in response to a positive verification, the verifier is registered with the dependent party. 2. The method according to claim 1, wherein verifying the code further comprises: Perform a secure transaction confirmation operation, including displaying the code in the secure display of the user's authenticator and requesting the user to send the code displayed on the secure display via the verified out-of-band communication channel. 3. The method according to claim 1, wherein the code is a password generated by the user's authenticator. 4. The method according to claim 1, further comprising: In response to the request to register the validator, a public key associated with the validator is generated and transmitted to the dependent party. 5. The method according to claim 4, further comprising: The code is generated by performing a hash operation on the public key. 6. The method of claim 5, wherein the hash operation includes SHA-256, SHA-1, or SHA-3 hash operations. 7. The method of claim 1, wherein the out-of-band communication channel includes postal mail, email, or short message service (SMS) messages. 8. The method of claim 2, wherein performing the secure transaction confirmation operation further comprises: Displays an identification code associated with the user's account linked to the dependent party. 9. The method of claim 1, wherein the code is extracted from an electronic message verified/signed using the user's electronic identification certificate. 10. The method of claim 2, wherein the content is protected by generating a hash of the content displayed within the secure display and providing the resulting hash value to the dependent party, the dependent party verifying the validity of the content by checking the hash value. 11. A method for registering a verification device with enhanced security, the method comprising: Receive requests from the user's registration authenticator at the dependent side; Code is generated by the verifier; The code is securely provided to the user; The code is sent from the user to the dependent party via a verified out-of-band communication channel; and The code is used to verify the user's identity, and in response to a positive verification, the verifier is registered. 12. The method of claim 11, wherein securely providing the code to the user comprises: Perform a secure transaction confirmation operation, including displaying the code in the user's authenticator's secure display. 13. The method of claim 11, further comprising: In response to the request to register the validator, a public key associated with the validator is generated and transmitted to the dependent party. 14. The method of claim 13, further comprising: The code is generated by performing a hash operation on the public key. 15. The method of claim 14, wherein the hash operation includes a SHA-256, SHA-1, or SHA-3 hash operation. 16. The method of claim 11, wherein the out-of-band communication channel includes postal mail, email, or short message service (SMS) messages. 17. The method of claim 12, wherein performing the secure transaction confirmation operation further comprises: Displays an identification code associated with the user's account linked to the dependent party. 18. The method of claim 11, wherein the code is extracted from an electronic message verified/signed by the user's electronic identity certificate. 19. The method of claim 12, wherein the content is protected by generating a hash of the content displayed within the secure display and providing the resulting hash value to the dependent party, the dependent party verifying the validity of the content by checking the hash value. 20. A method for registering a verification device with enhanced security, the method comprising: Receive a request from the user's registration authenticator at the dependent party, the request containing identification information for identifying the user's existing credentials; A verification object is created at the user's client, the verification object containing a signature generated using a private key associated with the user's existing credentials; and The signature is verified at the dependent party, and in response to a positive verification, the verifier is registered. 21. The method of claim 20, further comprising: Generate a public/private key pair associated with the verifier; and send the public key to the dependent party. 22. The method of claim 21, wherein the verification object includes an identification code associated with the user's account at the dependent party, a hash of the public key generated using the private key, and the signature generated using the private key. 23. The method of claim 22, wherein verifying the signature includes comparing a hash of the public key extracted from the object with a hash value calculated from the public key received from the user during registration.