System and method for authorizing a new authenticator

• US 9,413,533 B1
• Filed: 05/02/2014
• Issued: 08/09/2016
• Est. Priority Date: 05/02/2014
• Status: Active Grant

• Current Assignee: Nok Nok Labs Incorporated
• Original Assignee: Nok Nok Labs Incorporated
• Inventors: Lindemann, Rolf
• Primary Examiner(s): Traore, Fatoumata
• Application Number:
  US14/268,686
• Time in Patent Office: 830 Days
• Field of Search: None
• US Class Current: 1/1
• CPC Class Codes: H04L 9/0891 Revocation or update of secret information, e.g. encryption key update or rekeying
• CPC Class Codes: H04L 9/321 involving a third party or a trusted authority
• CPC Class Codes: H04L 9/3231 Biological data, e.g. fingerprint, voice or retina network architectures or network communication protocols for supporting authentication of entities using biometrical features in a packet data network H04L63/0861
• CPC Class Codes: H04L 9/3247 involving digital signatures

Abstract

A system, apparatus, method, and machine readable medium are described for authorizing a new authenticator with a relying party. For example, one embodiment of a method comprises: identifying a plurality of relying parties with which an old authenticator is registered; generating at least one key for each of the plurality of relying parties; authenticating with each of the relying parties using a client having the old authenticator configured thereon, the client authorizing the new authenticator by providing an authorization object to each relying party comprising the at least one key, data identifying the new authenticator, and cryptographic data to be used by the relying party to verify the authorization object; and wherein, in response to verifying the authorization object, each relying party registers the new authenticator.

Claims

1. A method for authorizing a new authenticator comprising:

identifying a plurality of relying parties with which an old authenticator is registered;

generating at least one key for each of the plurality of relying parties;

authenticating with each of the relying parties using a client having the old authenticator configured thereon, the client authorizing the new authenticator by providing an authorization object to each relying party comprising the at least one key, data identifying the new authenticator, and cryptographic data to be used by the relying party to verify the authorization object;

wherein, in response to verifying the authorization object, each relying party registers the new authenticator;

wherein an operation of generating at least one key is performed by the new authenticator;

wherein identifying the plurality of relying parties comprises the new authenticator receiving a list of usernames and unique identification codes to identify each relying party from the old authenticator; and

establishing a secure communication channel between the old authenticator and the new authenticator, wherein the new authenticator receives the list of usernames and unique identification codes to identify each relying party from the old authenticator over the secure communication channel.

2. The method as in claim 1 wherein the data identifying the new authenticator comprises an Authenticator Attestation ID (AAID).

3. The method as in claim 1, wherein the authorization object further comprises a first unique identification code identifying the relying party'"'"'s service.

4. The method as in claim 1 wherein the authorization object further comprises a Username or UserID identifying a user account at each relying party.

5. The method as in claim 4 wherein generating at least one key comprises generating a public/private key pair for each relying party and wherein the public key of the key pair is provided in the authorization object to the relying party.

6. The method as in claim 1 wherein the cryptographic data comprises a signature generating using a private key of the old authenticator.

7. The method as in claim 6 wherein the signature is generated over contents of the authorization object.

8. The method as in claim 1 wherein generating at least one key comprises the new authenticator generating a public/private key pair for each pair of the username and unique identification codes to identify each relying party.

9. The method as in claim 1 wherein the old authenticator is configured within a control system managed by an organization, the new authenticator is configured within a staff computer of the organization, and the relying party comprises a trust anchor managed by the organization.

10. The method as in claim 1 wherein the secure communication channel comprises a Bluetooth channel, Near Field Communication channel, WiFi channel, or Ethernet channel.

11. The method as in claim 1 wherein the old authenticator (Aold) displays the unique identification code for a first relying party and a public key hash of the key on a secure display used for transaction confirmation operations and wherein the new authenticator (Anew) displays the public key hash derived from a public key extracted from an authenticated message received from Aold and also displays the unique identification code for the first relying part and the public key hash on its secure display, thereby allowing the user to verify the correctness of the operation even in the case of compromised client devices.

12. A non-transitory machine-readable medium having program code stored thereon which, when executed by one or more computing devices, causes the one or more computing devices to perform the operations of:

identifying a plurality of relying parties with which an old authenticator is registered;

generating at least one key for each of the plurality of relying parties;

authenticating with each of the relying parties using a client having the old authenticator configured thereon, the client authorizing the new authenticator by providing an authorization object to each relying party comprising the at least one key, data identifying the new authenticator, and cryptographic data to be used by the relying party to verify the authorization object; and

wherein, in response to verifying the authorization object, each relying party registers the new authenticator;

wherein an operation of generating at least one key is performed by the new authenticator;

wherein identifying the plurality of relying parties comprises the new authenticator receiving a list of usernames and unique identification codes identifying each relying party from the old authenticator; and

establishing a secure communication channel between the old authenticator and the new authenticator, wherein the new authenticator receives the list of usernames and unique identification codes identifying each relying party from the old authenticator over the secure communication channel.

13. The non-transitory machine-readable medium as in claim 12 wherein the data identifying the new authenticator comprises an Authenticator Attestation ID (AAID).

14. The non-transitory machine readable-medium as in claim 12, wherein the authorization object further comprises a first unique identification code identifying the relying party'"'"'s service.

15. The non-transitory machine-readable medium as in claim 12 wherein the authorization object further comprises a username/UserID identifying a user account at each relying party.

16. The non-transitory machine-readable medium as in claim 15 wherein generating at least one key comprises generating a public/private key pair for each relying party and wherein the public key of the key pair is provided in the authorization object to the relying party.

17. The non-transitory machine-readable medium as in claim 12 wherein the cryptographic data comprises a signature generating using a private key of the old authenticator.

18. The non-transitory machine-readable medium as in claim 17 wherein the signature is generated over contents of the authorization object.

19. The non-transitory machine-readable medium as in claim 12 wherein generating at least one key comprises the new authenticator generating a public/private key pair for each pair of the username and unique identification codes to identify each relying party.

20. The non-transitory machine-readable medium as in claim 12 wherein the old authenticator is configured within a control system managed by an organization, the new authenticator is configured within a staff computer of the organization, and the relying party comprises a trust anchor managed by the organization.

21. The non-transitory machine-readable medium as in claim 12 wherein the secure communication channel comprises a Bluetooth channel, Near Field Communication channel, WiFi channel, or Ethernet channel.

22. The non-transitory machine-readable medium as in claim 12 wherein the old authenticator (Aold) displays the unique identification code for a first relying party and a public key hash of the key on a secure display used for transaction confirmation operations and wherein the new authenticator (Anew) displays the public key hash derived from a public key extracted from an authenticated message received from Aold and also displays the unique identification code for the first relying part and the public key hash on its secure display, thereby allowing the user to verify the correctness of the operation even in the case of compromised client devices.

23. A method for authorizing a new authenticator comprising:

identifying a plurality of relying parties with which an old authenticator is registered;

generating at least one key for each of the plurality of relying parties;

authenticating with each of the relying parties using a client having the old authenticator configured thereon, the client authorizing the new authenticator by providing an authorization object to each relying party comprising the at least one key, data identifying the new authenticator, and cryptographic data to be used by the relying party to verify the authorization object;

wherein, in response to verifying the authorization object, each relying party registers the new authenticator;

wherein the operation of generating at least one key is performed by the new authenticator;

wherein identifying the plurality of relying parties comprises the new authenticator receiving a list of usernames and unique identification codes to identify each relying party from the old authenticator; and

wherein generating at least one key comprises the new authenticator generating a public/private key pair for each pair of the username and unique identification codes to identify each relying party.

24. A non-transitory machine-readable medium having program code stored thereon which, when executed by one or more computing devices, causes the one or more computing devices to perform the operations of:

identifying a plurality of relying parties with which an old authenticator is registered;

generating at least one key for each of the plurality of relying parties;

authenticating with each of the relying parties using a client having the old authenticator configured thereon, the client authorizing the new authenticator by providing an authorization object to each relying party comprising the at least one key, data identifying the new authenticator, and cryptographic data to be used by the relying party to verify the authorization object; and

wherein, in response to verifying the authorization object, each relying party registers the new authenticator;

wherein the operation of generating at least one key is performed by the new authenticator;

wherein identifying the plurality of relying parties comprises the new authenticator receiving a list of usernames and unique identification codes to identify each relying party from the old authenticator; and

wherein generating at least one key comprises the new authenticator generating a public/private key pair for each pair of the username and unique identification code to identify each relying party.