System and method for delegating trust to a new authenticator

Abstract

A system, apparatus, method, and machine readable medium are described for delegating trust to a new client device or a new authenticator on a trusted device. For example, one embodiment of a method comprises: implementing a series of trust delegation operations to transfer registration data associated with one or more trusted authenticators on a trusted client device to one or more new authenticators on a new client device or on the trusted client device.

Description

BACKGROUND

Field of the Invention

This invention relates generally to the field of data processing systems. More particularly, the invention relates to a system and method for delegating trust to a new authenticator.

Description of Related Art

FIG. 1 illustrates an exemplary client 120 with a biometric device 100. When operated normally, a biometric sensor 102 reads raw biometric data from the user (e.g., capture the user's fingerprint, record the user's voice, snap a photo of the user, etc) and a feature extraction module 103 extracts specified characteristics of the raw biometric data (e.g., focusing on certain regions of the fingerprint, certain facial features, etc). A matcher module 104 compares the extracted features 133 with biometric reference data 110 stored in a secure storage on the client 120 and generates a score based on the similarity between the extracted features and the biometric reference data 110. The biometric reference data 110 is typically the result of an enrollment process in which the user enrolls a fingerprint, voice sample, image or other biometric data with the device 100. An application 105 may then use the score to determine whether the authentication was successful (e.g., if the score is above a certain specified threshold).

While the system shown in FIG. 1 is oriented towards biometric authentication, various other or additional authentication techniques may be employed on the exemplary client 120. For example, the client-side authenticators may be based on a PIN or other secret code (e.g., a password) entered by the user and/or may be triggered based on user presence (e.g., a button that user pushes to verify presence).

Systems have been designed for providing secure user authentication over a network using biometric sensors. In such systems, the score generated by the application, and/or other authentication data, may be sent over a network to authenticate the user with a remote server. For example, Patent Application No. 2011/0082801 (“'801 application”) describes a framework for user registration and authentication on a network which provides strong authentication (e.g., protection against identity theft and phishing), secure transactions (e.g., protection against “malware in the browser” and “man in the middle” attacks for transactions), and enrollment/management of client authentication tokens (e.g., fingerprint readers, facial recognition devices, smartcards, trusted platform modules, etc).

The assignee of the present application has developed a variety of improvements to the authentication framework described in the '801 application. Some of these improvements are described in the following set of US patent applications (“Co-pending applications”), all filed Dec. 29, 1012, which are assigned to the present assignee and incorporated herein by reference: Ser. No. 13/730,761, Query System and Method to Determine Authentication Capabilities; Ser. No. 13/730,776, System and Method for Efficiently Enrolling, Registering, and Authenticating With Multiple Authentication Devices; Ser. No. 13/730,780, System and Method for Processing Random Challenges Within an Authentication Framework; Ser. No. 13/730,791, System and Method for Implementing Privacy Classes Within an Authentication Framework; Ser. No. 13/730,795, System and Method for Implementing Transaction Signaling Within an Authentication Framework.

Briefly, the Co-Pending applications describe authentication techniques in which a user enrolls with biometric devices of a client to generate biometric template data (e.g., by swiping a finger, snapping a picture, recording a voice, etc); registers the biometric devices with one or more servers over a network (e.g., Websites or other relying parties equipped with secure transaction services as described in the Co-Pending applications); and subsequently authenticates with those servers using data exchanged during the registration process (e.g., encryption keys provisioned into the biometric devices). Once authenticated, the user is permitted to perform one or more online transactions with a Website or other relying party. In the framework described in the Co-Pending applications, sensitive information such as fingerprint data and other data which can be used to uniquely identify the user, may be retained locally on the user's client device (e.g., smartphone, notebook computer, etc) to protect a user's privacy.

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG. 1 illustrates an exemplary client equipped with a biometric device;

FIG. 2 illustrates one embodiment of a system for user confirmation of online transactions;

FIG. 3 illustrates details of one embodiment of a client used in a system for user confirmation of online transactions;

FIG. 4 illustrates one embodiment of a method for user confirmation of online transactions;

FIG. 5 illustrates one embodiment of a system for delegating trust to a new client device from a trusted client device;

FIG. 6 illustrates additional details for one embodiment of a system for delegating trust to a new client device from a trusted client device;

FIG. 7 illustrates one embodiment of a method for delegating trust to a new client device from a trusted client device;

FIG. 8 illustrates one embodiment of a method for verifying a trust delegation provided to a new client device from a trusted client device; and

FIG. 9 illustrates one embodiment of a system for synchronizing private data between devices;

FIG. 10 illustrates one embodiment of a method for adding a device to a trust circle;

FIG. 11 illustrates one embodiment of a method for synchronizing data between devices;

FIGS. 12 A-B illustrate exemplary system architectures on which the embodiments of the invention may be implemented.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Described below are embodiments of an apparatus, method, and machine-readable medium for delegating trust to a new authenticator. Throughout the description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are not shown or are shown in a block diagram form to avoid obscuring the underlying principles of the present invention.

The embodiments of the invention discussed below involve client devices with authentication capabilities such as biometric devices or PIN entry. These devices are sometimes referred to herein as “tokens,” “authentication devices,” or “authenticators.” While certain embodiments focus on facial recognition hardware/software (e.g., a camera and associated software for recognizing a user's face and tracking a user's eye movement), 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 the retina of a user). The authentication capabilities may also include non-biometric devices such as trusted platform modules (TPMs) and smartcards.

In a mobile biometric implementation, 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 boundary of the computer it is communicatively coupled to (e.g., it is not embedded into the same physical enclosure as the relying party computer). By way of 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, there may be no way for the relying party to know if the device is one which is authorized by the relying party (e.g., one which provides an acceptable level of authentication and integrity protection) and/or whether a hacker has compromised the biometric device. Confidence in the biometric device depends on the particular implementation of the device.

The term “relying party” is sometimes used herein to refer, not merely to the entity with which a user transaction is attempted (e.g., a Website or online service performing user transactions), but also to the secure transaction servers implemented on behalf of that entity which may performed the underlying authentication techniques described herein. The secure transaction servers may be owned and/or under the control of the relying party or may be under the control of a third party offering secure transaction services to the relying party as part of a business arrangement.

The term “server” is used herein to refer to software executed on a hardware platform (or across multiple hardware platforms) that receives requests over a network from a client, responsively performs one or more operations, and transmits a response to the client, typically including the results of the operations. The server responds to client requests to provide, or help to provide, a network “service” to the clients. Significantly, a server is not limited to a single computer (e.g., a single hardware device for executing the server software) and may, in fact, be spread across multiple hardware platforms, potentially at multiple geographical locations.

Embodiments for User Confirmation for Online Transactions

There are various scenarios where completing a transaction with a relying party may require approval from one or more other users. By way of example, and not limitation, a parent may want to approve a financial transaction initiated by a child, a commander may need to approve a transaction initiated by a soldier, a manager may need to approve a business transaction initiated by an employee, and a cryptographic key management system may require multiple users to approve a particular transaction before it can be committed.

One embodiment of the invention uses the techniques described herein for providing strong authentication of users over a network to enable multi-user confirmation applications. One such example is illustrated in FIG. 2 which shows a client device with remote authentication capabilities 200 controlled by a user attempting to initiate a transaction with a relying party with secure transaction services 250 (hereinafter simply referred to as “relying party”). In one embodiment, the user of client device 200 authenticates with the relying party 250 using one or more of the remote authentication techniques described herein (e.g., providing biometric input such as swiping a finger on a fingerprint sensor, entering a PIN or password, etc).

In the illustrated embodiment, other client devices 201-202 have users who are registered with the relying party as “approvers” for the user of client device 200. Thus, for certain types of transactions (e.g., financial transactions involving amounts over a specified threshold), the relying party may require approval from the users of client devices 201-202. As discussed below, the remote authentication techniques described herein are employed as part of the approval process.

In one embodiment, in response to a successful authentication by the user of client device 200, notification generation logic at the relying party 250 sends a notification the other client devices 201-202 with users registered as “approvers” indicating that the user of client device 200 is attempting to complete a transaction. The notification may be sent in a variety of ways in accordance with the underlying principles of the invention. For example, if the client devices 201-202 are mobile devices, then a push notification may be sent to the client devices 201-202. Alternatively, or in addition, the notification may be sent via email, text message (e.g., SMS), instant message, or any other technology capable of delivering a message to the client devices 201-202.

In one embodiment, the notification includes details of the transaction being attempted by the user of client device 200. For example, if the transaction is a financial transaction, then the notification may include the particular amount of money being processed and the type of financial transaction being performed (e.g., withdrawal, transfer between accounts, etc). Alternatively, the notification may include a link such as a hyperlink or other type of pointer directing the users of client devices 201-202 to an approval service on the relying party. Upon selection of the link, the users of client devices 201-202 may be provided with details of the transaction (e.g., in a Web page or other useful format for providing information).

In one embodiment, upon responding to the notifications and reviewing the details of the transaction, the users of client devices 201-202 may confirm the request by performing remote authentication with the relying party (e.g., using the multi-factor authentication techniques described herein) and indicating an approval of the transaction.

Additional architectural details of a client device 200-202 employed in one embodiment of the invention are illustrated in FIG. 3. In particular, the client devices 200-202 of this embodiment includes a secure transaction application 304 for communicating with the relying party 250 and coordinating the transaction approval techniques described herein. The secure transaction application 304 may be a stand-alone application which interfaces with the authentication engine 310 via a secure application programming interface (API). Alternatively, the secure transaction application 304 may be implemented as a mobile device app or a Web browser plugin.

In addition to coordinating the user confirmation process described herein, in one embodiment, the secure transaction application 304 ensures that the text displayed to each user is the actual text related to the transaction. For example, the application 304 may display text within a secure window and ask the user to provide authentication to confirm the transaction. The application may initiate a timer and periodically verify the content of the current window being displayed to the user (e.g., by generating a signature on the content). The period of verification may be randomly chosen. Thus, the application continually ensures that each user sees the valid transaction details in the window (thereby ensuring that the transaction text has not been modified by a “man in the middle” attack). If the application detects that the content has been tampered with it prevents the confirmation of the transaction from being generated.

In one embodiment, after the a user provides valid authentication (e.g., swipes a finger on the fingerprint sensor), the client device identifies the user and generates a token (cryptographic signature) with the transaction details (e.g., the displayed text) and a random challenge provided from the relying party (e.g., the token may be a signature over the transaction details and a nonce). This allows the relying party 250 ensure that the transaction details have not been modified between the server and the client. In one embodiment, the application 304 sends the generated token and username to the relying party, which then identifies the user with the username and verifies the token. If verification succeeds, a confirmation message is sent to the client and the transaction is processed.

The above techniques may be implemented for both the transaction request/confirmation originating from the client device 200 and for the approval transactions originating from the users of client devices 201-202.

Returning to FIG. 3, in one embodiment, authentication may be performed via an authentication engine 310 on the client devices 200-202 designed to perform a series of transactions with the relying party 250 to remotely authenticate each user. For example, as described in the co-pending applications an authentication framework and associated authentication techniques may be employed in which a user enrolls with biometric devices 320-321 of a client to generate biometric template data (e.g., by swiping a finger, snapping a picture, recording a voice, etc); registers the biometric devices with one or more relying parties 250 over a network (e.g., Websites or other relying parties equipped with secure transaction services); and subsequently authenticates with those relying parties 250 using data exchanged during the registration process (e.g., encryption keys provisioned into the biometric devices). In one embodiment, “registration” with relying parties includes exchanging symmetric or asymmetric keys with the relying party for each user authentication device 320-321 and storing the keys within a secure storage 325 associated with each authentication devices 320-321. A secure key provisioning protocol such as the Dynamic Symmetric Key Provisioning Protocol (DSKPP) may be used to share keys with the client over a secure communication channel (see, e.g., Request for Comments (RFC) 6063). However, the underlying principles of the invention are not limited to any particular key provisioning protocol.

During the authentication phase, the keys are used, for example, to generate signatures, verify signatures, and/or encrypt communication between the clients 200-202 and the relying party 250. Once authenticated, the user is permitted to perform one or more online transactions. In addition, in one embodiment, sensitive information such as fingerprint data and other data which may uniquely identify the user may be retained locally on the user's client device (e.g., smartphone, notebook computer, etc) to protect the user's privacy.

In one embodiment, the authentication engine 310 includes an assurance level calculation module 306 for calculating an assurance level corresponding to a likelihood that the legitimate user is in possession of the client device 200-202. It may then use this assurance level to determine whether the relying party 250 should authorize a current transaction. In one embodiment, the relying party 250 may specify the level of assurance required for a given transaction. For example, for a financial transaction involving the transfer of a significant amount of money, the relying party 250 may require a relatively higher assurance level than, for example, a transaction involving no exchange of money or mere access to a user information.

In one embodiment, the assurance level calculation module 306 transmits the assurance level (e.g., specified as a value, percentage, code, etc) to the relying party 250, without disclosing any confidential user information, thereby protecting the user's privacy. In another embodiment, the assurance level calculation module 306 knows the assurance level required for the current transaction, determines whether the assurance level is sufficiently high, and transmits an indication of whether the transaction is permitted or denied to the relying party 250 (without disclosing the user's private information to the relying party 250).

In one embodiment, the communication between the client devices 200-202 and relying party 250 is secured via a secure communication module 313, which may encrypt outgoing communication using a first key and decrypt incoming communication using a second key. In a symmetric key encryption scheme the first and second keys are the same. In an asymmetric key encryption scheme, the keys are different. However, the underlying principles of the invention are not limited to any particular type of encryption.

In one embodiment, the assurance level calculation module 306 determines the assurance level based, at least in part, on current user authentication results 305 which may include the results of a current or recent explicit user authentication via one or more explicit user authentication devices 320-321. This may include, for example, fingerprint authentication via a fingerprint device, facial recognition authentication via a camera and facial recognition hardware/software, voice recognition via a microphone and voice recognition hardware/software, retinal scanning using a camera and associated hardware/software, a password/PIN entry by the end user via a keypad, and/or various other types of explicit user authentication devices and/or techniques.

In one embodiment, the secure storage 325 cryptographically protects the biometric reference data records for each user authentication device 320-321 (e.g., wrapping the data using a symmetric key to make the storage 325 secure). While the secure storage 325 is illustrated outside of the secure perimeter of the authentication device(s) 320-321, in one embodiment, each authentication device 320-321 may have its own integrated secure storage to cryptographically protect the biometric reference data records.

In addition to explicit user authentication, one embodiment of the authentication engine 310 performs non-intrusive authentication by collecting data from sensors 343 to be used by the assurance calculation module 306 to generate the assurance level. By way of example, the sensors 343 may include location sensors such as GPS sensors to indicate a current location of the user. If the client devices 200-202 are in an expected location such as the known vicinity (e.g., a “home” or “office” location), then this increases the likelihood that the user is the legitimate user. By contrast, if the GPS reading indicates that the user is not at an expected location, then this indicates that the user initiating the transaction is not the legitimate user. Thus, in one embodiment, the assurance calculation module 306 will increase the assurance level if the user is in an expected location and decrease the assurance level if the user is in an unexpected location.

Various additional sensors 343 such as temperature sensors, humidity sensors and accelerometers may be used to collect data relevant to user authentication. For example, the temperature/humidity sensors may provide a current temperature/humidity which may be compared against the known temperature/humidity for the location specified by the location sensor. If the values are significantly different, then this may indicate that the client devices 200-202 are being spoofed. The comparison of the asserted location and the temperature/humidity may be done at a remote server such as the secure transaction server(s) used by the relying party 250. In another embodiment, accelerometers on the device may be used to measure the gait of the user and compare these measurements against the known gait of the user. If the gaits match (within a specified threshold), then this increases the likelihood that the legitimate user is in possession of the client device 200-202.

Another non-intrusive authentication technique comprises measuring an amount of time which has elapsed since the last successful user authentication. For example, if the user has very recently performed an explicit user authentication (e.g., swiping a finger on a fingerprint reader just a few minutes earlier), then this will tend to indicate that the legitimate user is still in possession of the client device (thereby resulting in a high baseline assurance level). By contrast, if the last explicit authentication has been several hours or several days earlier, then a new explicit user authentication may be required to reach an acceptable assurance level.

A method in accordance with one embodiment of the invention is illustrated in FIG. 4. At 401, the user of a client triggers a transaction which requires a confirmation by N other users. For example, the user's account at the relying party may indicate that certain types of transactions initiated by the user (or all transactions) require confirmation by one or more other users. For example, the user's account may identify the user as a minor, requiring authorization by one or more parents or guardians. The user is also authenticated at 401 by implementing one or more of the authentication techniques described herein.

At 402, the server selects N other users who must confirm the transaction triggered by the user. For example, upon detecting the initiation of the transaction by the user, the relying party may query its user database to determine that the transaction requires confirmation and the identity of the users who can confirm the transaction. In one embodiment, a subset of all of the users who are capable of confirming the transaction may actually confirm the transaction. For example, if the user is a minor with two parents then, in one embodiment, the notification may be sent to both parents, but a confirmation by either parent will allow the transaction to proceed. Similarly, there may be 10 users who are authorized to confirm a business transaction, but only 2 confirmations are required to allow the transaction to proceed.

In one embodiment, a push notification may be sent to the client devices of those users who can confirm the transaction (e.g., if the users have client devices capable of receiving push notifications). Alternatively, or in addition, the notification may be sent via email, text message (e.g., SMS), instant message, or any other technology capable of delivering a message to the client devices. In one embodiment, a user may be registered with the server to receive confirmation messages through two or more communication channels. For example, a user may receive both a push notification and an email containing the confirmation request.

Regardless of how the confirmation request is sent, at 403 all or a subset of the N users perform authentication with the server as part of the confirmation process. Any remote authentication techniques may be employed to authenticate the users and confirm the transaction. For example, a user may confirm a transaction by providing biometric data to a biometric device on the client which has been previously registered with the relying party (e.g., swiping a finger on a fingerprint scanner). As mentioned above, the details associated with the transaction may be provided to the users via a secure transaction application capable of securely displaying text and other information (i.e., ensuring that when a user confirms the transaction, he/she has viewed the actual, unaltered text describing the transaction).

Once a minimum specified number of users have confirmed the request, determined at 404, then the transaction is permitted at 407. One embodiment of the method starts a confirmation timer to measure the amount of elapsed time since the confirmation requests were sent. Once the confirmation timer has reached a threshold value (e.g., a few hours, a day, etc.), determined at 405, the transaction is disallowed at 406. Until the timer threshold is reached, the method waits at 404 for the minimum specified number of users to confirm the request.

System and Method for Delegating Trust Between Client Devices

Existing authentication systems do not allow new authenticators to be enabled using registered authenticators on trusted clients. For example, if a user has a fingerprint sensor on her phone which she has registered with number of websites and then she installs a voice authenticator on her phone, she has no way to automatically register her voice authenticator with all the websites she was using with fingerprint sensor. Rather, in this case, the user must step through the same enrollment and registration process to register the voice authenticator with the relying party. Similarly, if the user purchases a new device with a new set of authenticators, the user must re-enroll and reregister all of the new authenticators with the server.

The embodiments of the invention described below allow a user to easily enable and register the authenticator(s) on a new client device using a trusted client device that is already enabled and registered with one or more relying parties. In particular, these embodiments may be used to enable new authenticators, enable new client devices, and keep the registrations in sync between multiple client devices.

FIG. 5 provide a high level overview of trust delegation in accordance with one embodiment of the invention. A trusted device 502, i.e., a device which has an authenticator which is registered with one or more relying parties 550, establishes a secure connection with the user's new client device 500. The particular manner in which the secure connection is established is not pertinent to the underlying principles of the invention. Various techniques may be used such as near field communication (NFC), Bluetooth, Wifi Direct, using a quick response (QR) code and establishing an HTTPS connection. In one embodiment, the devices may exchange a large random token (LRT) needed for a secure connection and may establish a connection by providing the captured LRT to an online service and bootstrap a secure communication via the service.

In one embodiment, once the secure connection is established between the trusted client device 502 and new client device 500, a secure protocol is implemented (described in detail below) to transfer and integrate the registration data from the trusted device to the new device. Once the registrations have been transferred, another secure protocol is implemented (e.g., HTTPS in one embodiment) between the new client device 500 and relying parties 550 to verify the registrations.

While the embodiments described herein focus on transferring authentication data used for authentication transactions with a relying party 550, the relying party may not be required for complying with the underlying principles of the invention. For example, the trusted device 502 may establish a secure connection to provide authentication data to the new client device 500 without any relying party involved in the system (e.g., to provide authentication data for authenticating locally with the new client device 500).

As illustrated in FIG. 6, a trust delegation module 600-601 may be executed on the new device 500 and trusted device 502, respectively, to establish the secure connection, exchange the registrations, and verify the registrations with a secure transaction service 604 on each relying party 550. As used herein, a “trusted authenticator” is an authenticator that a user has already registered with one or more relying parties. A new “new authenticator” is one which the user wishes to enable with all the relying party registrations currently being used with the trusted authenticator. Thus, the authentication engine 311 is considered a trusted authenticator if it has previously registered one or more user authentication devices 320-321 with a relying party. The goal of one embodiment is to turn the authentication engine 310 of the new device 500 from a new authenticator into a trusted authenticator. A “trusted device” is one which has a trusted authenticator and a “new device” is one which has a new authenticator.

Trust delegation refers to the process of enabling the new authenticator using a trusted authenticator. Thus, the preconditions of trust delegation are: the user has a trusted device; the user has a new device; the user wants to delegate trust from trusted device to new device.

Returning to FIG. 6, in one embodiment, the user initiates the trust delegation application 600 on the new client device 500 and the trust delegation application 601 on the trusted client device to establish the initial secure connection. In one embodiment, the trust delegation applications may be mobile device apps, specifically designed to perform the trust delegation operations described herein. In another embodiment, the trust delegation applications may be browser plugins executed in response to the user indicating that he/she wishes to perform trust delegation (e.g., via a web page with embedded Javascript or other applet or executable program code). Moreover, the trust delegation applications 600-601 may be software modules within a larger application such as an authentication application designed to manage authentications with relying parties. It should be noted, however, that the underlying principles of the invention are not limited to any particular implementation of the trust delegation applications 600-601.

In one embodiment, to approve the trust delegation operations on the trusted device 502, the user locally authenticates with the authentication engine 311 on the trusted device (e.g., providing biometric input to a user authentication device 322-323). Similarly, in one embodiment, the user may locally authenticate with the authentication engine 310 on the new client device 500. These two authentication steps may provide authorization for the trust delegation applications 600-601 to perform the delegation process.

As mentioned, the trust delegation applications 600-601 may utilize any of the communication interfaces available on their respective client devices 500, 502 to establish a secure connection (e.g., Bluetooth interfaces for a Bluetooth connection, NFC interfaces for an NFC connection, etc).

Once the secure connection is established, in one embodiment, the trust delegation application 601 of the trusted client 502 provides data indicating the number of keys (N) on the trusted client which are registered with relying parties. In response, in one embodiment, the trust delegation application 600 generates N new device key pairs (ND_Uauth) including one private key (ND_Uauth.priv) and one public key (ND_Uauth.pub) and sends the N new device pubic keys to the trust delegation application 601 on the trusted device 502.

In one embodiment, the trust delegation application 601 then signs each of the N new device public keys with its corresponding trusted device private key (TD_Uauth.priv) to generate a signature (TD_Uauth.sig) associated with each of the N new device public keys. In one embodiment, the “corresponding” private key is the private key associated with a particular registration with a corresponding relying party. The trust delegation application 601 may also insert a timestamp into the generated signature which may subsequently be used by the relying party to verify exactly when the trust delegation occurred. In one embodiment, the trust delegation application 601 of the trusted client 502 then transmits each of the generated signatures along with other registration data associated with each relying party to the trust delegation application 600 on the new client 500. The data for each relying party may include, one or more relying party ID codes (e.g., application ID codes identifying services at the relying party), user names registered for the user at the relying party, key ID codes used by the relying party to locate the appropriate keys during authentication, and any other data relevant to the authentication process.

In one embodiment, once the trust delegation application 600 receives the signatures and other registration data, it integrates this data into the local secure storage device 325 so that it may be subsequently used when the new client device 500 connects to the relying party 550.

In one embodiment, after the registration data base been stored in the local secure storage 325, a series of bootstrapping operations may be performed by the trust delegation application 600 to leverage the delegated registrations on the new client device 500 with relying parties (e.g., websites, services, etc) that had previously been registered with the trusted client device 502. Alternatively, the described bootstrapping operations may be performed by the authentication engine 310 itself (via direct communication with the secure transaction service 604 as shown in FIG. 6). The underlying principles of the invention remain the same regardless of which particular software component on the new client device 500 performs the operations.

In particular, in one embodiment, the secure transaction service 604 of the relying party 550 detects that there are registrations on the new client device 500 using the remote authentication protocol supported by the secure transaction service 604 and trust delegation application 600. In one embodiment, the user may initially be asked by the secure transaction service 604 to perform biometric authentication or other form of authentication (e.g., entering a secure code) from the new client device 500. In addition, at this stage, the secure transaction service 604 may verify the timestamp inserted into the signature(s) and ensure that the timestamp is not older than a threshold amount of time.

Assuming that the user successfully provides biometric or other authentication data at an acceptable assurance level, the trust delegation application 600 and/or the new authenticator 310 prepare a response including the following three assertions:

1. An attestation over the new device public key associated with the relying party (ND_Uauth.pub). In one embodiment, the attestation comprises a signature generated over the public key (e.g., using a public key of the relying party).

2. An assertion using the new device private key associated with the relying party (ND_Uauth.priv). In one embodiment, to generate the assertion, the private key is used to generate a signature over content known by the relying party (e.g., such as a random challenge sent from the relying party). Because the relying party is provided with the public key (in step 1), it can decrypt the content, thereby verifying that the private key was used to encrypt the content.

3. The signature previously generated by the trusted client device and associated with the new device public key for this particular relying party (TD_Uauth.sig) along with the key ID used by the relying party (TD_Uauth.keyid) to locate the public key (e.g., so that it may use the key ID to query its secure transaction database 625 to retrieve the public key).

In one embodiment, all of the above data is then transmitted to the secure transaction service 604 of the relying party in a remote authentication response.

In one embodiment, after receiving the above assertions, the secure transaction service 604 may perform the following verifications:

1. Locate the trusted device's public key (TD_Uauth.pub) using the key ID;

2. Verify the signature generated by the trusted device (TD_Uauth.sig) using the trusted device's public key (TD_Uauth.pub);

3. Verify the signature generated by the new device's private key (ND_Uauth.sig) using the new device's public key (ND_Uauth.pub); and

4. Verify the attestation over the new device public key associated with the relying party (ND_Uauth.pub). In one embodiment, this verification is performed using the private key of the relying party.

One embodiment of a method for securely transferring registration data from a trusted device to a new device is illustrated in FIG. 7 and one embodiment of a method for verifying the registration data with the relying party is illustrated in FIG. 8. While these methods may be implemented within the context of the system architectures shown in FIGS. 5-6, the underlying principles of the invention are not limited to any particular system architecture.

Turning first to FIG. 7, at 701, the new devices establishes a secure communication channel with the trusted device and determines the number (N) of key pairs to generate. As mentioned, this may be the number of key pairs registered by the trusted device with relying parties.

At 702, the new device generates N new public/private key pairs. In an alternate implementation which utilizes symmetric keys, the new device may generate a single (symmetric) key to be shared with the relying party. At 703, the N public keys are sent to the trusted device and, at 704, the trusted device signs each public key with a corresponding private key to generate a signature. At 705, the signatures are sent to the new device with other registration data for the relying party (e.g., key IDs, application IDs, etc). Finally, at 706, all of the registration data and signatures are integrated within the local secure database(s) used by the authentication engine.

Turning now to FIG. 8, at 801 at new client (having already performed the delegation operations from FIG. 7) establishes a secure connection with the relying party. At 802, the relying party detects that there are existing registrations which have been delegated to the new device. In response, at 803, the relying party makes an authentication request to the new device. The user may then authenticate using one or more biometric or other authentication techniques. As discussed above, at 804, the new device prepares a response which includes an attestation over the new device public key, a signature generated with the new device private key (e.g., over a challenge), and the signature generated with the trusted device's private key and the associated key ID. At 805 all of the data in the response is transmitted to the relying party and, at 806, the relying party verifies the data contained in the response (see above for details of one embodiment). If the verification is successful, then at 807 the transaction being attempted by the user is permitted.

The techniques described herein may be used to delegate trust between two authenticators on different devices (as described above). In addition, in one embodiment, these techniques may be used to delegate trust between two authenticators on the same device. In this case, the secure connection between two devices does not need to be established but all of the other operations may be performed between the two authenticators within the device.

Moreover, it should be noted that some of the operations involved can be implemented in various ways. For example the secure protocol for delegating trust may be initiated by trusted device rather than the new device. In either case, the new device (or, more specifically, the authenticator on the new device) may generate a number of new key pairs (ND_Uauth) and the authenticator on the trusted device may sign the public keys of these key pairs.

System and Method for Privacy-Enhanced Data Synchronization

Current systems exist for synchronizing data between multiple client devices using cloud services. When a user creates a new document on a device (e.g., snaps a picture, creates a word processing document, etc) or modifies an existing document, a cloud service to which the user is subscribed will typically store a copy of the new/modified document “in the cloud.” When the user accesses the cloud service from a second device (e.g., a computer at work or a another device used by a different family member), the cloud service may be configured to synchronize the device.

One problem which exists is that data is frequently stored in the cloud service in an unencrypted format thereby making the data vulnerable to various types of cyber attacks and queries by federal agencies.

The embodiments of the invention described below provide a set of protocols and techniques which allow data to be synchronized among devices in a privacy-enhanced manner. Using these protocols and techniques, cloud services never have access to data in plaintext (e.g., unencrypted format), thereby preserving the user's privacy.

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

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

One embodiment of the invention comprises a protocol and associated techniques for allowing a new user device to (a) join a circle and (b) subsequently synchronize with the circle. These embodiments will be described with respect to FIG. 9 which shows a three client devices 901-903 each with a privacy sync application 911-913, respectively, for implementing the protocols and techniques described herein and secure data storage 921-932, respectively, for storing data used for joining and synchronizing. Device 901 is sometimes referred to herein as device d1, device 902 is sometimes referred to as device d2, and device 903 is sometimes referred to as device d3.

In one embodiment the joining and synchronizing are performed through a circle cloud 950 which includes a plurality of storage servers. A trust chain 960 within the circle cloud 950 maintains data defining trust relationships between the devices 901-903 as described below. The circle channel 970 comprises a secure communication channel provided by the circle-cloud that is used by two or more devices to exchange and synchronize data.

a. Joining the Circle

A device 902 (d2) joins an existing network of devices 901 (d1) and 903 (d3) that belong to the user (i.e., the “circle” of trusted devices). A device 902 can join an existing circle only if another device 901, which is already part of that circle, authorizes it.

One embodiment of a method for authorizing a new device 902 using a trusted device 901 is illustrated in FIG. 10. At 1001 a user authorizes the new device 902 on an existing trusted device 901. For example, in one embodiment, the user may initiate its privacy sync application 911 on the trusted device 901 and the privacy sync application 912 on the new client device 902.

At 1002, in one embodiment, the privacy sync applications 911-912 cause the devices 901-902 to establish a secure connection. Various techniques may be used to establish the secure connection such as near field communication (NFC), Bluetooth, Wifi Direct, using a quick response (QR) code and establishing an HTTPS connection.

At 1003, device 901 sends secure data to the new device 902, referred to herein as “join1_data.” In one embodiment, the join1_data includes the following fields: {d1.pub, sk.sym, circle-id}, where d1.pub is the public key of device 901, sk.sym is a randomly-generated session key generated by device 901, and the circle-id is a unique identification code identifying the circle which device 902 is joining.

At 1004, device 902 reads the join1_data and prepares a response which may include the following:

• • HMAC (sk.sym, d2.pub|T)|d2.pub|T where T is a timestamp
  • trust-block1=S(d2.priv, d1.pub)|d1.pub|d2.pubNote that HMAC stands for Hash-Based Message Authentication Code. In the above embodiment, the HMAC is generated by concatenating the public key of device 902 with a timestamp and protecting the integrity of the result with sk.sym using HMAC or a similar algorithm. In addition, trust-block1 includes a signature generated with device 902's private key over device 901's public key. In one embodiment, the trust-block1 entry also includes a timestamp (T).

Returning to FIG. 10, At 1005 device 902 securely connects to the circle-cloud 950 and transmits the response which includes the HMAC and trust-block1. The circle-cloud 950 stores the data received by device 901 and waits for device 901 to connect.

At 1006, device 901 connects to the circle cloud using the circle-id, validates the integrity of the data contained in device 902's response from operation 1005, and generates trust-block2. In particular, in one embodiment, device 901 reads and validates the integrity of d2.pub and T using sk.sym (e.g., using sk.sym to decrypt d2.pub and T). Device 901 then signs d2.pub using its own private key, d1.priv and generates trust-block2=S(d1.priv, d2.pub)|d2.pub|d1.pub, which comprises a signature generated over d2.pub with d1 priv. In one embodiment, trust-block2 also includes a timestamp (T). The device 901 then sends the above data including trust-block2 to the circle cloud 950.

At 1007, the circle-cloud 950 adds both trust-blocks to trust-chain 960. In one embodiment, after the above operations, device 902 joins the circle associated with circle-id. All devices 901, 903 in this circle trust device 902 and device 902 trusts all of these devices. Note that any trusted device can authorize a new device using the techniques described herein.

b. Sync with Circle

During this process the devices 901-903, belonging to the same circle, sync data between them. There can be different application-specific sub-protocols implemented on top of this process. For example, an online cloud storage application may want to keep user's data synchronized on all devices and keep the encrypted copy on circle-cloud. Another application may propagate messages to the devices in the circle. For example, in one embodiment, registration data used by one device to authenticate with a remote relying party may be synchronized across all devices in the circle. Various other applications and sub-protocols may be implemented while still complying with the underlying principles of the invention. All such sub-protocols may use the foundational process blocks described below.

Trust-Chain

As demonstrated in the “Join the Circle” process (FIG. 10), what goes into trust-chain 960 a proof which asserts that device2 is trusted by device1. Thus, a trust-chain 960 is a chain of authorization blocks each of which asserts a trust relationship between two devices. In one embodiment, a trust-chain is commutative, meaning that if device 901 trusts device 902 then device 902 trusts device 901. The trust-chain 960 is considered to be broken if there is a block asserting that device 901 trusts device 902 and there is no block asserting that device 902 trusts device 901. In one embodiment, the trust-chain 960 is also transitive, meaning that if device 901 trusts device 902 and device 902 trusts device 903 then device 901 trusts device 903. In one embodiment, the trust-chain is circle-id specific and it does not contain any confidential information about devices.

In one embodiment, the trust chain 960 comprises a plurality of trust blocks and each block includes the following data: {di.pub, dj.pub, S(di.priv, dj.pub), S(dj.priv, di.pub)}—i.e., the public keys of each device and a signature generated using the private key of each device over the public key of each other device.

The above assertion means that device di trusts device dj and vice versa. In one embodiment, the trust-chain 960 is used by devices 901-902 to determine and verify which devices are in the circle. After the devices verify that they are in the same circle, they may use the circle-channel 970 to synchronize encrypted data between them.

In one embodiment, to determine whether device di is in the same circle as device dj the following operations are performed: (a) construct a directional graph where each node is a device in trust-chain and each arrow corresponds to a block in trust-chain and (b) determine if there is a direct path connecting di and dj.

Circle-Channel

In one embodiment, the process illustrated in FIG. 11 is implemented to synchronize data between other devices in the same circle. In the illustrated example, device 901 (d1) is the device that has new data and wants to send to other devices. At 1101, device 901 downloads the trust-chain 960 associated with the circle-id, identifies the other devices in the same circle from the trust-chain (e.g., devices 902-903), and obtains the public keys of the other devices in the same circle using the trust-chain.

At 1102, the device 901 generates a random encryption key (REK) (e.g., using known techniques for random number generation). At 1103, device 901 derives mutual session keys (SK) for each of the other devices in the circle. In one embodiment, device 901 derives the SKs using the Diffie-Hellman key exchange algorithm with respect to each of the other others devices. Diffie-Hellman is a well known algorithm which allows two parties that have no prior knowledge of each other to jointly establish a shared secret key. In the instant case, for example, if a first device has a key pair and provides its public key to a second device, then the second device can automatically derive a new key (SK in the instant application) independently using its private key and the first device's public key (and vice versa). In one embodiment, device 901 uses these techniques to generate a different SK for each other device 902, 903.

At 1104, the device 901 encrypts REK with each derived SK for each device and binds the appropriate public keys with them. For example, for a device d1 which generates SKi and SKj for devices di and dj, respectively, it uses the session keys to encrypt REK as follows:

• • {d1.pub, di.pub, E(SKi, REK)} (for device di)
  • {d1.pub, dj.pub, E(SKj, REK)} (for device dj)In at the end of the process, each of the devices di and dj are able to decrypt REK using their respective session keys (which have been independently derived by each device using Diffie-Hellman as discussed above).

At 1105, device 901 encrypts the data to be synchronized with REK—i.e., E(REK, data-to-be-synced). As mentioned, any data may be synchronized in this manner such as multimedia files, productivity document, and/or client configuration data (e.g., relying party registration data as discussed above), to name a few.

At 1107, device 901 provides to the circle channel the REK encrypted with each SK and the data to be synchronized, encrypted with REK:

• • [{d1.pub, di.pub, E(SKi, REK)}, {d1.pub, dj.pub, E(SKj, REK)}, . . . ] E(REK, data-to-be-synced)

After the data has been provided to the circle-channel, at 1106 individual devices in the same circle download the record corresponding to their public key (e.g., {d1.pub, di.pub, E(SKi, REK)} for device di), derive the same SK (e.g., SKi), decrypt REK and use REK to decrypt the data to be synchronized.

In one embodiment, a “join circle” operation as described above may require user authentication on both device1 and device2. When this protocol is implemented using the remote authentication techniques described herein, a user may be required to, for example, “swipe” a finger to authenticate on both devices to initiate and complete the “join circle” process. By contrast, in one embodiment, syncing data between devices as described may not require user authentication.

The protocol and associated techniques described herein allow networks of devices to be built that trust each other. Significantly, all data transmitted to and from the cloud and stored within the cloud is encrypted. Consequently, data may be synchronized among the plurality of devices without storing any confidential data on cloud, resulting in improved user privacy protection.

The embodiments of the invention described above implement a private synchronization protocol for device synchronization where the participating cloud storage cannot view any of the user's data in plaintext (i.e., data is encrypted in the cloud). These embodiments includes various novel and beneficial features including, but not limited to:

• • A system and method implementing a device synchronization protocol where device has a public and private key for authorizing other devices.
  • A system and method which implement a trust-chain to indicate trust relationships between devices within the same circle.
  • A system and method where devices use Diffie-Hellman or similar key exchange algorithms to generate mutual session keys and encrypt data with those keys.
  • A system and method where a hash of a circle-id is stored in a circle-cloud instead of on the device itself.
  • A system and method where circle-cloud uses a challenge response protocol to authenticate a device before allowing it to put any data in circle's circle-channel.
  • A system and method where a permanent circle group key is used to encrypt the syncing data
  • An application which uses the described private synchronization protocols to share user's data (documents, files, photos, etc) among multiple devices and stores the encrypted backup of data on the cloud.
  • A system and method where the device's private key (d.priv) and all operations that use this key are implemented inside an authenticator for remotely authenticating a user over a network.
  • An application which uses the described private synchronization protocols in combination with the embodiments of the invention for performing user controlled trust delegation to a new device to share authenticator registrations among a user's devices.
  • An application which uses the described private synchronization protocols in combination with the embodiments of the invention for performing user controlled trust delegation to a new device to share new registrations among a user's devices where a user doesn't need to authenticate with an authenticator every time when a new registration is being delegated to other devices.
  • A set of authenticators belonging to the same user and forming a circle, where these authenticators are using the private synchronization protocols described above to sync authentication key pairs in order to share registrations of a single authenticator with other authenticators belonging to the same circle.

Exemplary System Architectures

It should be noted that the term “relying party” is used herein to refer, not merely to the entity with which a user transaction is attempted (e.g., a Website or online service performing user transactions), but also to the secure transaction servers implemented on behalf of that entity which may performed the underlying authentication techniques described herein. The secure transaction servers may be owned and/or under the control of the relying party or may be under the control of a third party offering secure transaction services to the relying party as part of a business arrangement. These distinctions are indicated in FIGS. 12A-B discussed below which show that the “relying party” may include Websites 1231 and other network services 1251 as well as the secure transaction servers 1232-1233 for performing the authentication techniques on behalf of the websites and network services.

In particular, FIGS. 12A-B illustrate two embodiments of a system architecture comprising client-side and server-side components for authenticating a user. The embodiment shown in FIG. 12A uses a browser plugin-based architecture for communicating with a website while the embodiment shown in FIG. 12B does not require a browser. The various user confirmation and trust delegation techniques described herein may be employed on either of these system architectures. For example, the authentication engine 310, secure transaction application 304, and/or trust delegation application 600 may be implemented as part of the secure transaction service 1201 including interface 1202. It should be noted, however, that the embodiments described with respect to FIGS. 1-8 may be implemented using logical arrangements of hardware and software other than those shown in FIGS. 12A-B.

Turning to FIG. 12A, the illustrated embodiment includes a client 1200 equipped with one or more authentication devices 1210-1212 for enrolling and authenticating an end user. As mentioned above, the authentication devices 1210-1212 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 the retina of a user) and non-biometric devices such as a trusted platform modules (TPMs) and smartcards. A user may enroll the biometric devices by providing biometric data (e.g., swiping a finger on the fingerprint device) which the secure transaction service 1201 may store as biometric template data in secure storage 1220 (via interface 1202).

While the secure storage 1220 is illustrated outside of the secure perimeter of the authentication device(s) 1210-1212, in one embodiment, each authentication device 1210-1212 may have its own integrated secure storage. Additionally, each authentication device 1210-1212 may cryptographically protect the biometric reference data records (e.g., wrapping them using a symmetric key to make the storage 1220 secure).

The authentication devices 1210-1212 are communicatively coupled to the client through an interface 1202 (e.g., an application programming interface or API) exposed by a secure transaction service 1201. The secure transaction service 1201 is a secure application for communicating with one or more secure transaction servers 1232 over a network and for interfacing with a secure transaction plugin 1205 executed within the context of a web browser 1204. As illustrated, the Interface 1202 may also provide secure access to a secure storage device 1220 on the client 1200 which stores information related to each of the authentication devices 1210-1212 such as a device identification code, user identification code, user enrollment data (e.g., scanned fingerprint or other biometric data), and keys used to perform the secure authentication techniques described herein. For example, as discussed in detail below, a unique key may be stored into each of the authentication devices and used when communicating to servers 1230 over a network such as the Internet.

In addition to enrollment of devices, the secure transaction service 1201 may then register the biometric devices with the secure transaction servers 1232-1233 over the network and subsequently authenticate with those servers using data exchanged during the registration process (e.g., encryption keys provisioned into the biometric devices). The authentication process may include any of the authentication techniques described herein (e.g., generating an assurance level on the client 1200 based on explicit or non-intrusive authentication techniques and transmitting the results to the secure transaction servers 1232-1233).

As discussed below, certain types of network transactions are supported by the secure transaction plugin 1205 such as HTTP or HTTPS transactions with websites 1231 or other servers. In one embodiment, the secure transaction plugin is initiated in response to specific HTML tags inserted into the HTML code of a web page by the web server 1231 within the secure enterprise or Web destination 1230 (sometimes simply referred to below as “server 1230”). In response to detecting such a tag, the secure transaction plugin 1205 may forward transactions to the secure transaction service 1201 for processing. In addition, for certain types of transactions (e.g., such as secure key exchange) the secure transaction service 1201 may open a direct communication channel with the on-premises transaction server 1232 (i.e., co-located with the website) or with an off-premises transaction server 1233.

The secure transaction servers 1232-1233 are coupled to a secure transaction database 1240 for storing user data, authentication device data, keys and other secure information needed to support the secure authentication transactions described below. It should be noted, however, that the underlying principles of the invention do not require the separation of logical components within the secure enterprise or web destination 1230 shown in FIG. 12A. For example, the website 1231 and the secure transaction servers 1232-1233 may be implemented within a single physical server or separate physical servers. Moreover, the website 1231 and transaction servers 1232-1233 may be implemented within an integrated software module executed on one or more servers for performing the functions described below.

As mentioned above, the underlying principles of the invention are not limited to a browser-based architecture shown in FIG. 12A. FIG. 12B illustrates an alternate implementation in which a stand-alone application 1254 utilizes the functionality provided by the secure transaction service 1201 to authenticate a user over a network. In one embodiment, the application 1254 is designed to establish communication sessions with one or more network services 1251 which rely on the secure transaction servers 1232-1233 for performing the user/client authentication techniques described in detail below.

In either of the embodiments shown in FIGS. 12A-B, the secure transaction servers 1232-1233 may generate the keys which are then securely transmitted to the secure transaction service 1201 and stored into the authentication devices within the secure storage 1220. Additionally, the secure transaction servers 1232-1233 manage the secure transaction database 1240 on the server side.

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

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

Throughout the foregoing description, for the purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without some of these specific details. For example, it will be readily apparent to those of skill in the art that the functional modules and methods described herein may be implemented as software, hardware or any combination thereof. Moreover, although some embodiments of the invention are described herein within the context of a mobile computing environment, the underlying principles of the invention are not limited to a mobile computing implementation. Virtually any type of client or peer data processing devices may be used in some embodiments including, for example, desktop or workstation computers. Accordingly, the scope and spirit of the invention should be judged in terms of the claims which follow.

Claims

1. A method for enabling one or more new authenticators being implemented in hardware of a new client device, the method comprising: the one or more new authenticators determining a number (N) of keys or key pairs contained in registration data associated with a trusted authenticator on a trusted client device, wherein the number N is equal to a number of keys or key pairs that have been registered with a relying party for the trusted authenticator and that also are on the trusted client device, wherein the relying party is remote from the trusted client device and the new client device, wherein the trusted client device and the new client device are mobile devices, and wherein the determination further comprises: the one or more new authenticators communicating with the trusted authenticator to obtain the number of keys or key pairs in the registration data;the one or more new authenticators generating N new keys or key pairs of the one or more new authenticators;the one or more new authenticators providing the N new keys or one of each of the N new key pairs to the trusted authenticator, wherein the trusted authenticator signs each of the N new keys using a key, which corresponds to registration of the trusted authenticator with the relying party, and wherein the trusted authenticator inserts a timestamp into each signature during the signing; andthe one or more new authenticators receiving N signatures from the trusted authenticator, wherein the N signatures are based on the N new keys or the one of each of the N new key pairs; andthe one or more new authenticators performing one or more verification transactions with the relying party based on the N signatures and using the timestamps.

2. The method as in claim 1 further comprising: the trusted authenticator transferring each of the signatures and registration data associated with the relying party to the one or more new authenticators.

3. The method as in claim 2 further comprising: the one or more new authenticators integrating the registration data and signatures within a local secure database.

4. The method as in claim 3, wherein the performing the one or more verification transactions with the relying party comprises: the one or more new authenticators establishing a connection with the relying party;the one or more new authenticators identifying the registration data, one of the N new keys, and the corresponding signature in the local secure database; andthe one or more new authenticators performing one or more verification transactions with the relying party using the registration data, the one of the N new keys, and the corresponding signature.

5. The method as in claim 4 wherein at least one of the verification transactions comprises reading the timestamps and determining whether the timestamp is sufficiently new to allow the one or more new authenticators to be enabled.

6. The method as in claim 5 wherein the verification transactions include the one or more new authenticators transmitting a response to the relying party comprising an attestation over the one of the N new keys, the corresponding signature, and a new signature generated with the one of the N new keys.

7. The method as in claim 6 wherein the attestation over the one of the N new keys comprises a signature generated over the one of the N new keys.

8. The method as in claim 6 wherein the new signature is generated over a challenge sent by the relying party.

9. The method as in claim 6 wherein the response further includes an identification code usable by the relying party to identify and locate a trusted key associated with the trusted client device.

10. The method as in claim 9 further comprising: verifying the signature at the relying party using the trusted key.

11. The method as in claim 10 wherein the trusted key comprises a public key associated with the trusted client device or the trusted authenticator.

12. A system comprising: a trusted authenticator implemented in hardware of a first device;one or more new authenticators that is implemented in hardware of a second device; anda relying party remote from the first and second devices; wherein the one or more new authenticators to be enabled, wherein the enabling operations comprises:the one or more new authenticators determining a number (N) of keys or key pairs contained in registration data associated with the trusted authenticator on a trusted client device, wherein the number N is equal to a number of keys or key pairs that have been registered with the relying party for the trusted authenticator and that also are on the trusted client device, wherein the trusted client device and the new client device are mobile devices, and wherein the determination further comprises: the one or more new authenticators communicating with the trusted authenticator to obtain the number of keys or key pairs in the registration data;the one or more new authenticators generating N new keys or key pairs of the one or more new authenticators;the one or more new authenticators providing the N new keys or one of each of the N new key pairs to the trusted authenticator, wherein the trusted authenticator signs each of the N new keys using a key, which corresponds to registration of the trusted authenticator with the relying party, and wherein the trusted authenticator inserts a timestamp into each signature during from the signing;the one or more new authenticators receiving N signatures from the trusted authenticator, wherein the N signatures are based on the N new keys or the one of each of the new N key pairs; andthe one or more new authenticators performing one or more verification transactions with the relying party based on the N signatures and using the timestamps.

13. The system as in claim 12 wherein the enabling further comprises: the one or more new authenticators integrating the registration data and signatures within a local secure database.

14. The system as in claim 13 wherein the performing the one or more verification transactions with the relying party comprises: the one or more new authenticators establishing a connection with the relying party;the one or more new authenticators identifying the registration data, one of the N new keys, and the corresponding signature in the local secure database; andthe one or more new authenticators performing one or more verification transactions with the relying party using the registration data, the one of the N new keys, and the corresponding signature.

15. The system as in claim 14 wherein the verification transactions include transmitting a response to the relying party comprising an attestation over the one of the N new keys, the corresponding signature, and a new signature generated with the one of the N new keys.

16. The system as in claim 15 wherein the attestation over the one of the N new keys comprises a signature generated over the one of the N new keys.

17. The system as in claim 15 wherein the new signature is generated over a challenge sent by the relying party.

18. The system as in claim 15 wherein the response further includes an identification code usable by the relying party to identify and locate a trusted key associated with the trusted client device.

19. The system as in claim 18 further comprising: verification logic to verify the signature at the relying party using the trusted key.

20. The system as in claim 19 wherein the trusted key comprises a public key associated with the trusted client device or the trusted authenticator.