HK1237157B - System and method for establishing trust using secure transmission protocols - Google Patents

Description

System and method for establishing trust using a secure transmission protocol

Background Art

Technical Field

The present invention generally relates to the field of data processing systems. More particularly, the present invention relates to systems and methods for establishing trust using a secure transmission protocol.

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 the biometric device, biometric reference data is captured (e.g., by swiping a finger, taking a photo, recording a voice, etc.). The user can then register the authentication device with one or more servers (e.g., websites or other relying parties equipped with secure transaction services, as described in the co-pending applications) via a network; and then authenticate with those servers using the data exchanged during the registration process (e.g., a key pre-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 the 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 those for designing composite authenticators, intelligently generating authentication assurance levels, employing non-intrusive user verification, transmitting authentication data to new authentication devices, augmenting authentication data with client-side risk data, adaptively applying authentication policies, and creating circles of trust.

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-1B illustrate two different embodiments of a security verification system architecture;

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

Figure 3 shows a transaction graph showing remote verification;

Figure 4 shows how authentication to a relying party might use a relying party application;

FIG5 illustrates one embodiment of a system for authentication using a secure communication protocol to establish trust;

FIG6 illustrates one embodiment of a method for authentication using a secure communication protocol to establish trust;

FIG. 7 illustrates an exemplary data processing architecture for implementing the clients and/or servers described herein; and

FIG8 illustrates another exemplary data processing architecture for implementing the clients and/or servers described herein;

DETAILED DESCRIPTION

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

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

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

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

The term "relying party" is sometimes used herein to refer not only to the entity with which a user transaction is attempted (e.g., a website or online service that performs the user transaction), but also to a secure transaction server (sometimes referred to as implemented on behalf of that entity, which entity 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, then performs one or more operations in response, and transmits a response to the client, which typically includes the results of the operations. The server responds to client requests, thereby providing or helping to provide network "services" to the client. It is worth noting that a server is not limited to a single computer (e.g., a single hardware device for executing server software), but can actually be distributed across multiple hardware platforms, potentially located in multiple geographical locations.

Exemplary System Architecture and Transactions

Figures 1A and 1B show two embodiments of a system architecture including client-side components and server-side components for registering verification devices and verifying users. 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 technologies 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 demonstrate 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 verifying end users. As described above, the authentication devices 110 to 112 may include biometric devices such as fingerprint sensors, voice recognition hardware/software (e.g., a microphone and associated software for recognizing a user’s voice), facial recognition hardware/software (e.g., a camera and associated software for recognizing a user’s face), and optical recognition capabilities (e.g., an optical scanner and associated software for scanning a user’s retina), and support non-biometric modalities (such as PIN verification). The authentication device may use a Trusted Platform Module (TPM), a smart card, or a secure element for cryptographic operations and key storage.

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

Certain basic principles related to remote registration of an authentication device and authentication of a relying party will be described in conjunction with Figures 2 to 5, followed by a detailed description of an embodiment of the present invention for establishing trust using a secure communication protocol.

FIG2 illustrates a series of transactions for registering an authentication device on a client (e.g., devices 110-112 on client 100 in FIG1A-1B ). For simplicity, secure transaction service 101 and interface 102 are grouped together as authentication client 201, and secure enterprise or web destination 130, including secure transaction servers 132-133, is represented as relying party 202.

During registration of an authenticator (e.g., a fingerprint authenticator, a voice authenticator, etc.), a key associated with the authenticator is shared between the authenticating client 201 and the relying party 202. Referring back to Figures 1A-1B, 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 is used. In this embodiment, a public/private key pair can be generated by the secure transaction server 132-133. The public key can then be stored by the secure transaction server 132-133, and the associated private key can be stored in the secure storage 120 on the client. In an alternative embodiment, the key can be generated on the client 100 (e.g., by the authenticating device or authenticating device interface rather than by the secure transaction server 132-133). The underlying principles of the present invention are not limited to any particular type of key or method of generating the key.

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

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

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

In one embodiment, relying party 202 generates a verification key for each verification device registered. It writes a key to a secure database and utilizes a key presetting protocol to send a key back to verification client 201. Once completed, verification device and relying party 202 share the same key when using a symmetric key, or share different keys when using an asymmetric key. For example, if an asymmetric key is used, relying party 202 can store a public key and provide a private key to verification client 201. When receiving the private key from relying party 202, verification client 201 presets a key (storing the key within the secure storage device associated with the verification device) in the verification device. Then it can use this key (as described below) during verification of the user. In an alternative embodiment, a key is generated by verification client 201 and a key presetting protocol is used to provide a key to relying party 202. In either case, once presetting is completed, verification client 201 and relying party 202 all have a key, and verification client 201 notifies relying party that it has been completed.

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

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

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

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

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

System and method for establishing trust using a secure transmission protocol

As mentioned above, in certain specific implementations using remote authentication, secure communication protocols such as TLS or SSL can be used to securely exchange data between the relying party and the authentication client. In short, TLS and SSL are cryptographic protocols that provide secure communication over typically insecure communication channels (e.g., the Internet). These protocols use X.509 certificates that implement asymmetric cryptography to exchange symmetric keys. This symmetric key is then used to encrypt the data channel between the two parties during the communication session. Although the remainder of this detailed description will focus on the use of TLS, other cryptographic protocols such as SSL can be used to implement the basic principles of the present invention.

In one embodiment, TLS is used to protect the communication channel between the relying party and the verification client and to verify the identity of the sender. That is, by using asymmetric cryptography supported by X.509 certificates, one party (e.g., the verification client) can verify the identity of the other party (e.g., the relying party), or vice versa. The identity of the other party can be embodied in a code or name that, for example, identifies the relying party (e.g., "RPNAME") or identifies the verification client, or a specific application on the client that is used to establish a communication channel with the relying party (e.g., "AppID"). When there is a direct channel between the verification client and the relying party (as in the example provided above), since data is typically sent over the Internet and TLS is always available, the use of TLS can well meet this purpose.

However, on certain computing device platforms such as iOS ^™ , Android ^™ and near field communication (NFC) transactions, this TLS assumption does not hold true. As roughly shown in Figure 4, on these platforms, it is expected that third-party code (e.g., relying party application 410) manages all communications between relying party 402 and verification client 401. Therefore, relying party application 410 is basically similar to a middleman between relying party 402 and verification client 401. In addition, verification client 401 does not have information about the validity of the TLS connection established by relying party application 410. It must only rely on third-party code to make this decision and use IPC mechanisms to forward the verification request (as shown). These IPC mechanisms can access the identification code (e.g., "bundle ID") of the sending application, but the authenticity of the identity (e.g., RPNAME, AppID) of the sender/receiver verified using bundle ID mainly depends on the attention of the operating system and the review process implemented by the application store that distributes the relying party application.

When using NFC, the situation is even worse because there is no identification code such as a bundle ID that accompanies the transport mechanism. NFC is handled by a general Multipurpose Internet Mail Extensions (MIME) handler. The authenticating client 401 must assume that any identification code claimed (e.g., RPNAME) is correct and that the authentication request comes from a valid source.

More specifically, on iOS devices, the application 410 that the authentication client 401 is communicating with is determined using the sourceApplication parameter of the openURL() call in the multi-factor authentication client's AppDelegate code: -(BOOL)application:(UIApplication*)application openURL:(NSURL*)urlsourceApplication:(NSString*)sourceApplication annotation:(id)annotation

In this example, sourceApplication contains the calling application's bundle ID. The bundle ID is a unique string in the calling application's plist manifest that identifies the application in Apple ^'s database. It is recommended to partially construct the bundle ID using the company's base URL (e.g., com.paypal.app) in reverse notation. This assumes that Apple reviews this string to ensure that the application is not attempting to deceive other applications.

For Android devices, first call getCallingUid() from the system Binder to return the Linux uid assigned to the relying party process that sent the current transaction to the multi-factor authentication process being processed, for example:

int callerUId=Binder.getCallingUid();;

The application then retrieves the package associated with the user ID from the system PackageManager. The package is named using the relying party's base URL as a component but in reverse notation (for example, "com.fido.android.sample.app.paypal"). For example:

String packageNames[]=mPackageManager.getPackagesForUid(callerUId);;

When using NFC, there is no trusted piece of information that can be mapped to a peer identifier (for example, RPNAME or AppID). When using NFC on Android, requests arrive through a Multipurpose Internet Mail Extensions (MIME) handler and do not identify the caller. Therefore, any identifier included in the request may or may not be valid.

One embodiment of the present invention addresses these limitations by using a trusted certificate to sign the verification request and source identifier. One option employed in one embodiment is an SSL X.509 certificate from a web server that can be verified against the mobile device's root certificate store. However, the relying party's verification server may not have access to the key. Generating a new X.509 certificate specifically for the verification server is another option, but this implies the additional overhead of managing yet another X.509 certificate.

To avoid these problems, one embodiment of the present invention, shown in Figure 5, uses a self-signed certificate from a decentralized public key infrastructure (PKI) to sign the verification request and corresponding source identifier (e.g., the "RPNAME" identifier) from the verification server 520 of the relying party 502. Specifically, in one embodiment, the self-signed certificate includes a private key 522 and one or more public keys stored in a public key file 525 on the verification server 520. Unlike X.509 certificates, these self-signed certificates cannot be trusted by themselves because there is no chain connecting them to a root trusted certificate.

In one embodiment, to establish trust, public keys stored in a public key file 525 on a web server are transmitted to a verification client 530 on a client device 500 (e.g., a mobile smartphone) via a secure communication channel established using a trusted certificate 526 (e.g., an existing X.509 trusted certificate used to open a TLS connection). Using TLS ensures that the vulnerable self-signed public keys in the public key file 525 are obtained from the correct owner because the trusted certificate/key 526 used to transmit these keys from the web server over the Internet can be verified against a root certificate store (if X.509 or other known standards are used). Those self-signed public keys in the file 526 can then be implicitly trusted and used to verify verification requests 523 that include a source identifier (e.g., RPNAME).

The verification server 520 may generate a verification request 523 in the same manner and under the same circumstances as described above with reference to FIG3. For example, the verification server 520 may generate a random challenge and identify the client-side authenticator to be used (e.g., using a public key registered for the authenticator). The random challenge and authenticator ID information may be encapsulated in the verification request 523.

Additionally, in one embodiment, the private key 522 of the decentralized PKI is used to sign the verification request 523. As mentioned, in one embodiment, the private key 522 corresponds to the public key in the file 525. For example, any signature generated by the private key 522 can be verified using one of the public keys.

Again, to establish trust, a verification request 523 signed using a private key 522 on the verification server 520 is transmitted to the relying party application 510 on the client device 500 via a secure communication channel established using a trusted certificate 521 (e.g., an existing X.509 trusted certificate used to open a TLS connection). In one embodiment, the trusted certificate 521 is the same as the trusted certificate 526 used to establish the TLS channel with the verification client 530. The private key-signed verification request 523 is then transmitted to the relying party application 510 using the TLS channel along with a source identifier (e.g., an RPNAME used to identify the relying party).

In one embodiment, relying party application 510 extracts the underlying private key-signed verification request (i.e., disassembles the TLS data) and provides the verification request to verification client 530 on client device 500. Relying party application 510 can use known inter-process communication (IPC) mechanisms to communicate with verification client 530. However, the underlying principles of the present invention are not limited to any particular communication mechanism for exchanging information on client device 500.

Upon receiving a private key-signed verification request 523, the verification client 530 verifies the signature using the public key from the public key file. If the signature is valid, it then generates a verification response as described above. For example, in response to a successful verification of the user, it can use the authenticator's private key to generate a signature on the random challenge included in the verification request 523, and transmit the resulting verification response to the verification server 520 (e.g., directly or via the relying party application 510). Once the verification server 520 verifies the signature using the corresponding public authenticator key, it authenticates the user to the relying party 502 and allows the user to complete the desired transaction.

Using the techniques described herein, the authentication request 523 and the source identifier (e.g., RPNAME) are cryptographically verified by a centralized SSL X.509 key, while still maintaining the flexibility and minimal management overhead provided by a decentralized PKI. By taking advantage of the fact that the file containing those certificates is located on a specific web server, implicitly trusting the validity of self-signed certificates carries a certain risk. Anyone who can modify this file on the web server can also change the public key. However, as long as access to the file is carefully protected as X.509 certificates can be managed, the trust granted by either solution should be similar.

A method according to one embodiment of the present invention is shown in Figure 6. The method may be implemented using the architecture shown in Figure 5, but is not limited to any specific architecture.

At 601, a first authentication-related communication is generated at a verification server on behalf of a relying party. In one embodiment, the first authentication-related communication includes the verification request 523 mentioned above (eg, including a random challenge, a verifier ID, etc.).

At 602, a first authentication-related communication is signed using a first key from a self-signed certificate of a decentralized public key infrastructure (PKI). In one embodiment, the first key comprises the private key 522 discussed above.

At 603, a first secure channel is established with a relying party application on the client device using an existing trusted communication infrastructure. In one embodiment, using the existing trusted communication infrastructure includes establishing a secure Transport Layer Security (TLS) channel with the relying party using a trusted X.509 certificate.

At 604, the first verification-related communication is transmitted to the relying party application via the first secure communication channel. As mentioned, in one embodiment, a source identifier (eg, RPNAME) is provided with the communication.

At 605, a second secure communication channel is established with the verification client on the client device using the existing trusted communication infrastructure. As mentioned, in one embodiment, using the existing trusted communication infrastructure includes establishing a secure TLS channel with the relying party using a trusted X.509 certificate.

At 606, a second key from the self-signed certificate of the decentralized PKI is transmitted to the verification client via a second secure communication channel. In one embodiment, the second key comprises a public key associated with the self-signed certificate from the decentralized PKI. One or more additional keys may also be provided via public key file 526 (as discussed above).

At 607, a first authentication-related communication with a signature is provided from the relying party application to the authenticating client. In one embodiment, this is performed compliant with existing inter-process communication (IPC) mechanisms on the client device.

At 608, the verification client verifies the signature generated by the first key using the second key. If the verification is successful, the verification client generates a second verification-related communication in response to the first verification-related communication. For example, as discussed above, if the first verification-related communication includes a verification request, the second verification-related communication may include a verification response. To generate the response, the verification client may first require the user to perform verification on the client device (e.g., swipe a finger, record a voice, enter a code, etc.). If the verification is successful, the verification client may transmit an indication of successful verification and other verifiable information (e.g., a random challenge provided with the verification request). Once the verification server receives the second verification-related communication, it may verify the user to the relying party and allow the user to enter into a transaction with the relying party.

Exemplary data processing apparatus

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

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

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

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

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

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

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

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

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

Claims (24)

1. A method comprising: generating, at a verification server on behalf of a relying party, a first verification-related communication directed to a client device having one or more authenticators; signing the first verification-related communication using a first key from a self-signed certificate of a decentralized public key infrastructure (PKI); establishing a first secure communication channel with a relying party application on the client device using a trusted secure communication infrastructure; transmitting the first verification-related communication with the signature to the relying party application via the first secure communication channel; establishing a second secure communication channel with the authentication client on the client device using the trusted secure communication infrastructure; transmitting a second key of the self-signed certificate from the decentralized PKI to the verification client via the second secure communication channel; providing the first authentication-related communication from the relying party application to the authentication client; and The verification client uses the second key to verify the signature generated by the first key on the first verification-related communication. 2 . The method of claim 1 , wherein the first key comprises a private key of the decentralized PKI and the second key comprises a corresponding public key. 3. The method of claim 1, wherein the trusted secure communication infrastructure comprises a trusted certificate, the trusted certificate being usable to establish a secure Transport Layer Security (TLS) connection for the first and/or the second secure communication channel. The method of claim 3 , wherein the trusted certificate comprises an X.509 certificate. 5. The method according to claim 1, further comprising: The authentication client generates a second authentication-related communication in response to the first authentication-related communication. 6. The method of claim 5, wherein the first authentication-related communication comprises an authentication request generated at an authentication server operating on behalf of the relying party, and the second authentication-related communication comprises an authentication response generated by the authentication client. 7. The method of claim 6, wherein the authentication request comprises a random challenge and a signature generated over the random challenge using a public key associated with an authenticator on the client device. 8. The method of claim 7, wherein the verification client verifies the signature using a private key associated with the authenticator. 9. The method of claim 8, wherein the authentication client generates the authentication response in response to successful user authentication achieved using one or more of the authenticators on the client device. 10. The method of claim 9, wherein the authenticator on the client device comprises a fingerprint authenticator. 11. The method of claim 1 , wherein providing the first authentication-related communication from the relying party application to the authentication client further comprises implementing inter-process communication (IPC) between the relying party application and the authentication client. 12. The method of claim 1, wherein the second key of the self-signed certificate is transmitted over the second secure communication channel in a public key file. 13. A system for performing verification, comprising: a client device having one or more of an authenticator, an authentication client, and a relying party application; an authentication server operating on behalf of a relying party, the authentication server generating a first authentication-related communication directed to the client device; the verification server signing the first verification-related communication using a first key from a self-signed certificate of a decentralized public key infrastructure (PKI); The verification server establishes a first secure communication channel with a relying party application on the client device using a trusted secure communication infrastructure; the verification server transmitting the first verification-related communication with the signature to the relying party application via the first secure communication channel; The verification server establishes a second secure communication channel with the verification client on the client device using a trusted secure communication infrastructure; The verification server transmits a second key of the self-signed certificate from the decentralized PKI to the verification client via the second secure communication channel; the relying party application providing the first authentication-related communication to the authentication client; and The verification client uses the second key to verify the signature generated by the first key on the first verification-related communication. 14. The system of claim 13, wherein the first key comprises a private key of the decentralized PKI and the second key comprises a corresponding public key. 15. The system of claim 13, wherein the trusted secure communication infrastructure includes a trusted certificate, the trusted certificate being usable to establish a secure Transport Layer Security (TLS) connection for the first and/or the second secure communication channel. 16. The system of claim 15, wherein the trusted certificate comprises an X.509 certificate. 17. The system of claim 13, further comprising: The authentication client generates a second authentication-related communication in response to the first authentication-related communication. 18. The system of claim 17, wherein the first authentication-related communication comprises an authentication request generated at an authentication server operating on behalf of the relying party, and the second authentication-related communication comprises an authentication response generated by the authentication client. 19. The system of claim 18, wherein the authentication request comprises a random challenge and a signature generated over the random challenge using a public key associated with an authenticator on the client device. 20. The system of claim 19, wherein the verification client verifies the signature using a private key associated with the authenticator. 21. The system of claim 20, wherein the authentication client generates the authentication response in response to successful user authentication achieved using one or more of the authenticators on the client device. 22. The system of claim 21, wherein the authenticator on the client device comprises a fingerprint authenticator. 23. The system of claim 13, wherein providing the first authentication-related communication from the relying party application to the authentication client further comprises implementing inter-process communication (IPC) between the relying party application and the authentication client. 24. The system of claim 13, wherein the second key of the self-signed certificate is transmitted over the second secure communication channel in a public key file.