System and method for recognizing new validators

Abstract

Systems, devices, methods, and machine-readable media for attestation verifiers are described. For example, one embodiment of a device includes a first instance of a verifier associated with a first application, the first instance allowing a user of the first application to attest to a first relying party, a secure key store accessible by the first instance of the verifier, the secure key store securely storing attestation data related to the first application, and a synchronization processor sharing at least a portion of the attestation data with a second instance of the verifier associated with a second application to be executed on the device.

Description

Technical Field

[0001] This invention relates generally to the field of data processing systems. More specifically, this invention relates to systems and methods for certifying new validators. Background Technology

[0002] Figure 1 An exemplary client 120 with biometric device 100 is shown. During normal operation, biometric sensor 102 reads raw biometric data from the user (e.g., capturing the user's fingerprint, recording the user's voice, taking a photograph of the user, etc.), and feature extraction module 103 extracts specified features from the raw biometric data (e.g., focusing on certain areas of the fingerprint, certain facial features, etc.). Matcher module 104 compares the extracted features 133 with biometric reference data 110 stored in secure storage on client 120 and generates a score based on the similarity between the extracted features and biometric reference data 110. Biometric reference data 110 is typically the result of a registration process in which the user registers fingerprints, voice samples, images, or other biometric data with device 100. Application 105 can then use the score to determine whether verification was successful (e.g., whether the score is above a specified threshold).

[0003] Although Figure 1 The system shown is geared towards biometric verification, but various other or additional verification technologies can be employed on the exemplary client 120. For example, the client-side verifier may be triggered based on a PIN or other secret code (e.g., a password) entered by the user and / or based on the presence of the user (e.g., the user pressing a button to verify presence).

[0004] Systems have been designed that use biometric sensors to provide secure user authentication over a network. In such systems, scores and / or other authentication data generated by an application can be sent over the network to authenticate the user to a remote server. For example, patent application No. 2011 / 0082801 (“'801 application”) describes a framework for user registration and authentication over a network that provides strong authentication (e.g., defense against identity theft and phishing), secure transactions (e.g., defense against “browser-based malware” and “man-in-the-middle” attacks in transactions), and registration / management of client authentication tokens (e.g., fingerprint readers, facial recognition devices, smart cards, trusted platform modules, etc.).

[0005] The assignee of this application has developed several improvements to the verification framework described in the '801 application. Some of these improvements are described in the following set of U.S. patent applications (“co-pending applications”), all filed on December 29, 2012, assigned to the assignee and incorporated herein by reference: Serial No. 13 / 730,761, entitled “Query System and Method to Determine Authentication Capabilities”; Serial No. 13 / 730,776, entitled “System and Method for Efficiently Enrolling, Registering, and Authenticating With Multiple Authentication Devices”; Serial No. 13 / 730,780, entitled “System and Method for Processing RandomChallenges Within an Authentication Framework”; and Serial No. 13 / 730,791, entitled “System and Method for Implementing Privacy Classes Within an Authentication”. Framework (System and Method for Implementing Transaction Signaling Within an Authentication Framework); Serial No. 13 / 730,795, entitled "System and Method for Implementing Transaction Signaling Within an Authentication Framework".

[0006] In short, in the authentication technologies described in these co-pending applications, a user registers with an authentication device (or authenticator) such as a biometric device (e.g., a fingerprint sensor) on a client device. When a user registers with the biometric device, biometric reference data is captured (e.g., by swiping a finger, taking a photo, recording voice, etc.). The user can then register the authentication device via a network with one or more servers (e.g., websites or other dependents equipped with secure transaction services, as described in the co-pending applications); and subsequently authenticate with those servers using data exchanged during registration (e.g., keys pre-loaded into the authentication device). Once authenticated, the user is permitted to perform one or more online transactions with the website or other dependents. Within the framework described in the co-pending applications, sensitive information (such as fingerprint data and other data that can be used to uniquely identify a user) can be locally maintained on the user's authentication device to protect the user's privacy. Summary of the Invention

[0007] In one aspect, the present invention provides a device for validator authentication, the device comprising: a first instance of a validator associated with a first application, the first instance allowing users of the first application to authenticate with a first dependent party; a hardware security keystore accessible by the first instance of the validator, the security keystore securely storing authentication data associated with the first application; a first synchronization processor associated with the first application, the first synchronization processor sharing at least a portion of the authentication data with a second instance of the validator, the second instance of the validator being associated with a second application to be executed on the device, wherein the shared portion of the authentication data includes data shared with the second instance of the validator. An instance provides initial user verification reference data; and a second synchronization processor associated with the second application, the second synchronization processor transmitting an approval request to the first synchronization processor, the approval request including a verification public key, a verification object generated by the second synchronization processor, and an encrypted public key in an encrypted public / private key pair; wherein, in response to positive verification of the approval request, the first synchronization processor transmits an approval response to the second synchronization processor, the approval response including at least a portion of the verification object and the initial user verification reference data encrypted using the encrypted public key; and wherein the second instance of the verifier receives the approval response from the second synchronization processor and retrieves the initial user verification reference data from the approval response.

[0008] On the other hand, the present invention provides a method for validator authentication, the method comprising: installing a first instance of a validator associated with a first application on a client device to allow a user of the first application to authenticate with a first dependent party, the first instance of the validator securely storing authentication data associated with the first application; sharing at least a portion of the authentication data, including initial user authentication reference data, with a second instance of the validator associated with the second application via a first synchronization processor associated with the first application and a second synchronization processor associated with a second application to be executed on the client device; transmitting an authentication request from the second synchronization processor to the first synchronization processor, the authentication request including a verification public key, a verification object generated by the second synchronization processor, and an encrypted public key in an encrypted public / private key pair; transmitting an authentication response from the first synchronization processor to the second synchronization processor in response to positive verification of the authentication request, the authentication response including at least a portion of the verification object and the initial user authentication reference data encrypted using the encrypted public key; and retrieving the initial user authentication reference data from the authentication response by the second instance of the validator using an encrypted private key in the encrypted public / private key pair.

[0009] On the other hand, the present invention provides a 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 following operations: installing a first instance of a validator associated with a first application on a client device to allow a user of the first application to verify with a first dependent party, the first instance of the validator securely storing verification data associated with the first application; sharing at least a portion of the verification data, including initial user verification reference data, with a second instance of the validator associated with the second application, via a first synchronization processor associated with the first application and a second synchronization processor associated with a second application to be executed on the client device; transmitting an approval request from the second synchronization processor to the first synchronization processor, the approval request including a verification public key, a verification object generated by the second synchronization processor, and an encrypted public key in an encrypted public / private key pair; transmitting an approval response from the first synchronization processor to the second synchronization processor in response to a positive verification of the approval request, the approval response including at least a portion of the verification object and the initial user verification reference data encrypted using the encrypted public key; and retrieving the initial user verification reference data from the approval response by the second instance of the validator. Attached Figure Description

[0010] The invention can be better understood from the following specific embodiments in conjunction with the accompanying drawings, wherein:

[0011] Figure 1 An exemplary client equipped with a biometer is shown;

[0012] Figure 2 An implementation of a system for authorizing new validators to dependent parties is shown;

[0013] Figure 3 Additional details of one implementation of a system for authorizing new validators to dependent parties are shown;

[0014] Figure 4 An implementation scheme for authorizing a new validator to a trusting party is shown;

[0015] Figure 5 This illustrates one implementation in which an old validator authorizes a new validator to multiple dependent parties;

[0016] Figure 6 This illustrates a specific implementation scheme in which the control system manages the authorization of new validators within the organization; and

[0017] Figures 7A to 7B An exemplary system architecture on which embodiments of the present invention can be implemented is shown;

[0018] Figures 8 to 9 An exemplary embodiment of a system for carrying out embodiments of the present invention is shown;

[0019] Figure 10 This illustrates one implementation where the dependent party uses metadata to verify the client;

[0020] Figure 11 An implementation scheme for an architecture that uses data, such as code securely provided to the user, to guide the user to bind to a validator is shown;

[0021] Figure 12 One implementation of an architecture for using biometric data to guide users to bind to a validator is shown;

[0022] Figure 13 One implementation of an architecture for guiding a user to bind to an authenticator using a physical device such as a SIM card is shown;

[0023] Figure 14 An embodiment of the invention utilizing a portion of the FIDO protocol is illustrated;

[0024] Figure 15An embodiment of the present invention for securely sharing encrypted data is illustrated;

[0025] Figure 16 An implementation scheme utilizing a Data Migration Card (DMC) is shown;

[0026] Figure 17 A system according to one embodiment of the present invention is shown;

[0027] Figure 18 This illustrates a system-on-a-chip (SoC) according to one implementation scheme; and

[0028] Figures 19 to 21 Different implementation schemes for sharing validation data among different validators are shown.

[0029] Detailed Implementation of the Preferred Scheme

[0030] The following describes embodiments of apparatus, methods, and machine-readable media for authorizing new verifiers. Throughout the description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of the invention. However, those skilled in the art will readily appreciate that the invention can be practiced without some of these specific details. In other instances, well-known structures and apparatuses are not shown or are illustrated in block diagram form so as not to obscure the essential principles of the invention.

[0031] The embodiments of the invention discussed below relate to authentication devices with user verification functions, such as biometric forms or PIN input. These devices are sometimes referred to herein as “tokens,” “authentication devices,” or “authenticators.” While 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 (e.g.) 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 verification functions may also include non-biometric forms, such as PIN input. Authenticators may use devices such as Trusted Platform Modules (TPMs), smart cards, and secure elements for cryptographic operations and key storage.

[0032] In specific implementations of mobile biometry, the biometric device can be remotely located to the dependent party. As used herein, the term "remote" means that the biometric sensor is not part of the security boundary of the computer to which it is communicatively coupled (e.g., the biometric sensor is not embedded in the same physical enclosure as the dependent party's computer). For example, the biometric device can be coupled to the dependent party via a network (e.g., the Internet, wireless network links, etc.) or via a peripheral input (such as a USB port). Under these conditions, the dependent party may not know whether the device is authorized by the dependent party (e.g., a device providing an acceptable level of verification 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.

[0033] In this document, the term "dependent party" is sometimes used to refer not only to the entity with which a user transaction is attempted (e.g., a website or online service that executes the user transaction), but also to the secure transaction server implemented on behalf of that entity (which executes the underlying authentication technology described herein). The secure transaction server may be owned by and / or under the control of the dependent party, or may be under the control of a third party that provides secure transaction services to the dependent party as part of a business arrangement.

[0034] As used in this document, the term "server" refers to software that runs on one (or across) hardware platforms, receives requests from clients over a network, performs one or more operations in response, and transmits the response back to the client, typically including the result of the operations. A server responds to client requests, thereby providing or assisting in providing network "services" to the client. It is important to note 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 and potentially located in multiple geographical locations.

[0035] Systems and methods for authorizing new validators

[0036] In some cases, it may be useful to allow enabling new authenticators using authenticators registered on existing client devices. For example, if a user purchases a new device with a new set of authenticators, it would be beneficial to provide the user with a way to automatically register all new authenticators using existing ones.

[0037] The embodiments of the invention described below allow users to authorize validators on new client devices using existing / legacy trusted client devices registered with one or more dependent parties. Specifically, these embodiments can be used to enable new validators on new or existing client devices, and to maintain registration synchronization across multiple client devices.

[0038] Figure 2 A high-level overview of authenticator authorization according to one embodiment of the present invention is provided. An older client device 202 with an old / existing authenticator (Aold) (i.e., a device with an authenticator registered with one or more dependent parties 250) establishes a connection with a user's new client device 200 with a new authenticator (Anew). The specific manner in which the connection is established is irrelevant to the basic principles of the invention. In one embodiment, the connection includes a secure / encrypted connection (e.g., established via SSL, TLS, etc.). Various technologies can be used, such as Near Field Communication (NFC), Bluetooth, Wi-Fi Direct, using Quick Response (QR) codes, and establishing an HTTPS connection, or via a standard network connection (e.g., via Wi-Fi or Ethernet).

[0039] In one implementation, once a connection is established between an older client device 202 with Aold and a newer client device 200 with Anew, a security protocol (described in detail below) is implemented to transfer registration data from the older client device 202 and integrate it into the newer client device 200. For example, in one implementation, the older client device 202 sends registration data to the newer client device 200, which then generates a new set of key pairs (e.g., one key pair per dependent) and sends the public key along with an indication of the validator type on the newer client device 200 back to the older client device 202. The client with Aold then generates a signed authorization object (e.g., using the public key, validator identification data, and user account data) and sends it to each corresponding dependent 250.

[0040] like Figure 3 As shown, authenticator authorization applications 390 and 391 can be executed on the new client device 200 and the old client device 202, respectively, to establish secure connections, exchange authorization data, and verify registration content with the secure transaction service 304 on each dependency 250. As used herein, an "Aold authenticator" is an authenticator that a user has already registered with one or more dependencies. A "Anew authenticator" is an authenticator that a user wishes to enable using all dependency registration content currently used for the old authenticator. Therefore, the verification engine 311 in this embodiment has previously registered one or more old authenticator devices 322 to 323 with dependencies. One embodiment aims to transfer registration content from the old verification engine 311 to the new verification engine 310 to enable new authenticators 320 to 321 on each dependency.

[0041] As shown in the figure, both the new client device 200 and the old client device 202 include secure storage devices 325 and 326, respectively, for storing the registration data of each dependent party (e.g., public / private key pairs used during verification). Furthermore, dependent party 250 includes a secure transaction database 325 for securely storing the registration data of each of the new client device 200 and the old client device 202 (e.g., user account data, validator identification data, public keys provided for each validator, etc.).

[0042] In one implementation, the user launches authenticator authorization application 390 on both the new client device 200 and the old client device 202 to establish an initial secure connection. Authenticator authorization applications 390-391 can be mobile device applications (apps or applications) specifically designed to perform the authorization operations described herein. In another implementation, the authenticator authorization application can be a browser plugin (e.g., via a webpage with embedded Javascript or other applets or executable code) that executes in response to a user's instruction that he / she wishes to perform authorization. Furthermore, authenticator authorization applications 390-391 can be software modules within a larger application (such as an authentication application designed to manage authentication to dependent parties). However, it should be noted that the basic principles of the invention are not limited to any particular specific implementation of authenticator authorization applications 390-391.

[0043] In one implementation, to approve authorization operations on legacy client device 202, the user is verified by verification engine 311 on the legacy device (e.g., providing biometric input to user verification devices 322-323). Similarly, in one implementation, the user may be verified by verification engine 310 on the new client device 200. These two verification steps authorize authenticator authorization applications 390-391 to perform the authorization process.

[0044] As described above, at the start of the authorization process, authenticator authorization applications 390-391 establish a secure connection (e.g., using Bluetooth, WiFi, etc.). In one embodiment, authenticator authorization application 390 on the new client device 200 receives a set of registration data from the old client device 202 for each dependency it has registered with. The registration data may include a username and a unique code associated with the user account on each dependency. This unique code that associates a user with each dependency is sometimes referred to herein as an “AppID”. In some embodiments where the dependency provides multiple online services, a user may have multiple AppIDs on a single dependency (the dependency provides one AppID for each service).

[0045] In one implementation, the authenticator authorization application 390 on the new client device 200 then generates a new public / private key pair for each dependent party (e.g., one key pair for each username + AppID pair). The authenticator authorization application 390 on the new client device 200 sends the key pair (or only the public key) and an authenticator ID (e.g., authenticator confirmation ID or "AAID") identifying each new authenticator type to the authenticator authorization application 391 on the old client device 202. The user can then be prompted to confirm the authorization of the new authenticator.

[0046] In one implementation, the validator authorization application 391 generates a signed authorization object, which includes a signature on a tuple of AAID, public key, and AppID for each dependent party. In one implementation, the signature is generated using the current verification key associated with the dependent party (e.g., a private key associated with the dependent party's legacy validator). The validator authorization application 391 then verifies with each dependent party (e.g., via legacy verification engine 311 and one or more legacy validators 322-323), including the signed authorization object as an extension to one of the verification messages.

[0047] Upon receiving a signed verification message, the secure transaction service 304 can then verify the signature (e.g., using the public key corresponding to the private key used to generate the signature). Once verified, it identifies the user account and AppID and stores the new AAID and new public key of the new validator in the secure transaction database 325. The user can then use the new validators 320 to 321 for verification without having to re-register with each dependent party 250.

[0048] Despite Figures 2 to 3 While illustrated as a new user device, the basic principles of the invention can also be implemented in scenarios where a user installs a new authenticator on an existing client device. For example, a user can upgrade the authenticator or add it to an existing desktop computer, laptop, or other type of client. In this case, Figure 3 Communication between the validator authorization applications 390-391 shown can occur internally (e.g., via internal function calls between software modules implemented on the client).

[0049] Figure 4 An implementation of a method for authorizing new validators is shown in the figure. This method can be used in, for example... Figure 3 The system is implemented within the environment shown, but is not limited to any specific system architecture.

[0050] At step 401, the user triggers authorization for one or more new authenticators (Anew) and establishes a secure communication channel with the old authenticator (Aold). As mentioned, the secure communication channel can be established via a direct connection (e.g., via NFC, Bluetooth, etc.) or via a network (e.g., via Ethernet or WiFi connection).

[0051] At position 402, the new validator receives the username and user / dependency ID code for each dependency.

[0052] At 403, the new validator generates a public / private key pair for each username / AppID pair (e.g., for each unique dependent account).

[0053] At 404, the old validator receives the key pair and a validator confirmation ID code (e.g., AAID) that identifies the type of each new validator. The user can then be asked to confirm the authorization operation.

[0054] At 405, the old validator generates a signed authorization object, which includes a signature on a tuple of each dependent party's AAID, public key, and AppID. As mentioned, the signature can be generated using the current verification key associated with the dependent party (e.g., the private key associated with the dependent party's old validator).

[0055] At position 406, the old validator validates each dependent party and includes the signed authorization object as an extension to the validation message. Once this operation completes successfully, the user can then use the new device and / or the new validator to validate each dependent party.

[0056] Figure 5 A series of operations are illustrated graphically, in which a new validator 501 is authorized to be used with multiple dependent parties R1-Rn by an old validator 502 on an old client 500. As mentioned, after receiving account data associated with each dependent party, the new validator 501 generates a new key pair for each dependent party in R1-Rn and provides the new key pair to the old validator 502. The old validator 502 then generates a secure authorization object containing data associated with the new validator 501 (e.g., AAID) and a new key for each validator. The old validator then performs verification for each dependent party in R1-Rn, including the verification object. After verification (e.g., where a signature on the authorization object is verified), the new validator 501 is automatically registered at each dependent party R1-Rn.

[0057] In one implementation, each dependent party R1-Rn can choose whether to accept a new validator 501. For example, if the AAID indicates that the validator type is not reliable or accurate enough, the dependent party can choose to reject new registration content. Therefore, each dependent party can maintain a validator database (i.e., metadata) containing data for all known validators (e.g., those identified by the AAID). Each dependent party can then query the database in response to receiving an authorized object from an old validator, determine the characteristics of the new validator, and determine whether those characteristics are acceptable.

[0058] In one embodiment of the invention, the verifier may specify a more general "confirmation" method, wherein the verifier may be indirectly controlled by the same entity but still belong to different users. For example, in Figure 6 In this example, the old authenticator 602 can be integrated into an owner control system 601 controlled by a single owner / operator (e.g., a company or government entity). The new authenticator 612 in this example can be an authenticator belonging to an employee computer 611, and authorization of the new authenticator 612 can be triggered by the owner control system 601 using the known trusted authenticator 602. In this example, the interaction between the new authenticator 612 and the old authenticator 602 can be as described above (e.g., the new authenticator generates a new key pair, and the old authenticator sends an authorization object (e.g., for use as...) to a device 621 including an owner or supplier trust anchor 622. Figure 3 The secure transaction service 304 and the secure transaction database 325 store verifier registration data in the same way.

[0059] Exemplary verification system architecture

[0060] It should be noted that, as used herein, the term "dependent party" refers not only to the entity with which a user transaction is attempted (e.g., a website or online service executing the user transaction), but also to the secure transaction server implemented on behalf of that entity (which executes the underlying authentication technology described herein). The secure transaction server may be owned by and / or under the control of the dependent party, or may be under the control of a third party providing secure transaction services to the dependent party as part of a business arrangement. These distinctions are discussed below. Figures 7A to 7B The accompanying diagrams indicate that the “dependent party” may include website 731 and other network services 751, as well as secure transaction servers 732 to 733 for performing verification technologies on behalf of the website and network services.

[0061] Specifically, Figures 7A to 7B Two implementation schemes of a system architecture including client-side components and server-side components for user authentication are shown. Figure 7A The implementation shown uses a browser plugin-based architecture to communicate with the website, while Figure 7BThe illustrated implementation does not require a browser. Various user authentication and authorization technologies described herein can be employed on any of these system architectures. For example, authentication engines 310, 311 and validator authorization applications 390, 391 can be implemented as part of a secure transaction service 701 including interface 702. However, it should be noted that the implementation described above can use technologies other than... Figures 7A to 7B The implementation is based on the logical arrangement of hardware and software, other than those shown.

[0062] Go to Figure 7A The illustrated embodiment includes a client 700 equipped with one or more verification devices 710 to 712 for registering and verifying end users. As described above, verification devices 710 to 712 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 functions (e.g., an optical scanner and associated software for scanning a user's retina); as well as non-biometric devices such as Trusted Platform Modules (TPMs) and smart cards. Users can register biometric devices by providing biometric data (e.g., swiping their finger on a fingerprint device), and the secure transaction service 701 can store this biometric data as biometric template data (via interface 702) in a secure storage device 720.

[0063] Although the secure storage device 720 is shown outside the security perimeter of the verification devices 710 to 712, in one embodiment, each verification device 710 to 712 may have its own integrated secure storage device. Additionally, each verification device 710 to 712 may cryptographically protect biometric reference data records (e.g., by wrapping these data records using a symmetric key to secure the storage device 720).

[0064] Verification devices 710 to 712 are communicatively coupled to the client via an interface 702 (e.g., an application programming interface or API) exposed by the secure transaction service 701. The secure transaction service 701 is a secure application for communicating with one or more secure transaction servers 732 via a network and for engaging with a secure transaction plugin 705 executed within the environment of a web browser 704. As shown, interface 702 may also provide secure access to a secure storage device 720 on the client 700, which stores information associated with each verification device 710 to 712, such as device identification codes, user identification codes, user registration data (e.g., scanned fingerprints or other biometric data), and keys for performing the secure verification techniques described herein. For example, as discussed in detail below, a unique key may be stored in each verification device during registration and used when communicating with server 730 via a network (such as the Internet).

[0065] Once a user has registered with the verification device on client 700, secure transaction service 701 can register the verification device with secure transaction servers 732-733 via the network (e.g., using the registration techniques described herein), and subsequently verify with those servers using data exchanged during the registration process (e.g., encryption keys pre-installed in the biometric device). The verification process may include any of the verification techniques described herein (e.g., generating an assurance level on client 700 based on explicit or non-intrusive verification techniques and transmitting the result to secure transaction servers 732-733).

[0066] As discussed below, the secure transaction plugin 705 supports certain types of web transactions, such as HTTP or HTTPS transactions with website 731 or other servers. In one implementation, the secure transaction plugin is activated in response to a specific HTML tag inserted into the HTML code of a webpage by a web server 731 (hereinafter sometimes simply referred to as "server 730") within the security enterprise or web destination 730. In response to the detection of such a tag, the secure transaction plugin 705 may forward the transaction to the secure transaction service 701 for processing. Additionally, for certain types of transactions (e.g., such as secure key exchanges), the secure transaction service 701 may open a direct communication channel with a local transaction server 732 (i.e., located in the same location as the website) or a remote transaction server 733.

[0067] Secure transaction servers 732 to 733 are coupled to secure transaction database 740 to store user data, authentication device data, keys, and other security information required to support secure authentication transactions as described below. However, it should be noted that the basic principles of the invention do not require separation. Figure 7AThe logical components within the security enterprise or web destination 730 shown. For example, website 731 and secure transaction servers 732 to 733 may be implemented within a single physical server or a separate physical server. Furthermore, website 731 and transaction servers 732 to 733 may be implemented within an integrated software module executed on one or more servers to perform the functions described below.

[0068] As described above, the basic principles of this invention are not limited to... Figure 7A The browser-based architecture shown. Figure 7B Alternative specific implementations are shown, in which a standalone application 754 utilizes the functionality provided by the secure transaction service 701 to authenticate a user over the network. In one implementation, application 754 is designed to establish a communication session with one or more network services 751 that rely on secure transaction servers 732 to 733 to perform the user / client authentication techniques described in detail below.

[0069] exist Figures 7A to 7B In any of the embodiments shown, secure transaction servers 732 to 733 can generate keys, which are then securely transmitted to secure transaction service 701 and stored in the verification device within secure storage device 720. Additionally, secure transaction servers 732 to 733 manage the secure transaction database 740 on the server side.

[0070] Typical verification system

[0071] Even after years of IT innovation, passwords remain the most widely used authentication method. However, both users and service providers fail to handle passwords properly, making this form of authentication inherently insecure. On the other hand, over 1 billion Trusted Platform Modules (TPMs) and over 150 million Secure Elements have been delivered; microphones and cameras are integrated into most smartphones, and fingerprint sensors and Trusted Execution Environments (TEEs) are on the rise. There are better authentication methods than passwords or One-Time Passwords (OTPs).

[0072] In 2007, the average user had 25 accounts, used 6.5 passwords, and logged in 8 times a day. Today, the situation is much worse. An analysis of 6 million accounts showed that 10,000 common passwords could access 30% of the accounts (Burnett, 2011). Even when examining bank account passwords, it was found that 73% of users shared their online banking passwords with at least one non-financial website (Trusteer, Inc., 2010), meaning that bank accounts are at risk when non-bank websites are hacked.

[0073] Several recommendations have been made for password replacement, including verification silos, diversified verification, and trusted client environments.

[0074] Verification silo Current alternative technologies require their own proprietary server technologies. Therefore, the current verification architecture consists of a silo comprising verification methods, related client implementations, and related server technologies.

[0075] The innovative verification methods proposed by the research team have not been widely deployed because, in addition to client-side implementations, complete server software needs to be implemented and deployed. Verification companies are not competing for better user verification methods, but rather for the best server technology.

[0076] Diversified Validation Users can use a standalone PC, tablet, or smartphone for verification. Employers can control some devices, while users can control others (David A. Willis, Gartner, 2013). The increasing adoption of mobile devices and the BYOD trend have led to a more diversified verification landscape. A single verification method that meets all needs seems unattainable.

[0077] Trustworthy client environment Client-side malware can capture and expose passwords or OTPs. It can alter transactions that require confirmation upon display, or it can abuse verified communication channels to perform unintended actions. Authentication (even via username and password) requires at least one trusted component on the client side.

[0078] Currently, alternative methods for authentication based on cryptography or OTP cannot be scaled. This is mainly due to the suboptimal combination of authentication building blocks. To address this limitation, one embodiment of the present invention identifies typical building blocks that may be implemented in various different ways and still result in well-known and functional authentication systems—suitable for integration within existing platform functionalities.

[0079] Recent large-scale password attacks have all focused on the server side. These attacks are unrelated to user efforts and security measures. Figure 8 In the attack categories shown, these attacks are labeled (1). Introducing protections against this single threat category would likely divert attackers' attention to attacks aimed at stealing and abusing authentication credentials from user devices (2-4), including stealing and abusing data by impersonating users (2-3) and abusing authenticated sessions (4). Items (5) and (6) involve the physical theft of user devices and the theft of data and / or the abuse of devices to impersonate users. However, attacks are likely to focus on some type of scalable attack, i.e., attacks with a fixed cost but potentially a large number of sellable items. Physical attacks can be launched against individual devices, but scalability is poor.

[0080] In one embodiment of the invention, instead of storing a hash cipher with relatively low entropy, an asymmetric public key can be stored on a server, and the associated private key can be stored in the device. Calculating the private key from a given public key is very resource-intensive because it requires RSA factorization or solving the discrete logarithm problem (DSA / ECDSA). At a minimum, the private key should be protected against malware attacks. In one embodiment, this is accomplished using a Trusted Execution Environment (TEE) or Secure Element (SE) on the client device.

[0081] Given that most client devices are always online, malware might not extract the private key, but rather simply attempt to abuse it. To protect against such attacks, (a) access using the key should be limited to qualified applications, and (b) some type of user interaction is required that malware cannot mimic. TrustedUI (GlobalPlatform, 2013) can be used to implement this type of user interaction. It should be noted that SecureElement typically lacks a user interface and therefore does not provide this type of protection.

[0082] Authentication is secure when the protective measures described above are implemented. However, attackers may then focus their attacks on applications that control the authenticated sessions. Existing PC infection rates (APWG, 2014) demonstrate the feasibility of these types of attacks. When an authenticator with higher protection than current mobile applications is present, it can be used to display and retrieve a user's confirmation of a specific transaction. In this case, an infected application could result in (a) a malicious transaction being displayed that will be rejected by the user, or (b) a signed transaction being modified after signing, which can be detected by the server. This is a second use case of the TrustedUI implementation.

[0083] In one implementation, a secure element is used to protect against physical key extraction. The underlying chip hardware of the SE typically implements state-of-the-art protections against physical attacks (Dr. Sergei Skorobogatov, University of Cambridge, 2011). Alternatively, in one implementation, a TrustedUI or other dedicated user authentication hardware (such as a fingerprint sensor) can be used to meet the need for physical user interaction.

[0084] If an attacker gains physical access to the device, they can attempt to abuse the key instead of extracting it. To protect against such attacks, effective user authentication methods with low false acceptance rates, robust anti-spoofing measures, and anti-hammering mechanisms (i.e., effectively limiting the number of possible brute-force attempts) are used.

[0085] Given that scalable attacks are the primary concern, one implementation focuses on countermeasures against physical attacks after implementing countermeasures against scalable attacks.

[0086] While robust authentication protection on the client side is beneficial, the remote party (i.e., the server side) is also interested in understanding the security measures employed. Therefore, one embodiment of the invention "verifies" client-side security features to the remote server. For this to be effective, these authentication techniques need to be at least as robust as the client-side protection.

[0087] For practical solutions, verified privacy is also important. Direct Anonymous Verification (DAA) is a good option. Unfortunately, the original DAA method is too slow when implemented on standard hardware. Improved pair-based DAA schemes are much faster. TCG has used it in TPMv2 (Liqun Chen, HP Labs, and Jiangtao Li, Intel, 2013).

[0088] A typical signature consists of an object to be signed controlled by the application and a signature computed using a private key. Therefore, for a verifier, any data within the object to be signed is only as trustworthy as the application that controls the content of the object.

[0089] like Figure 9 As shown, in one embodiment, private key 905 is protected by a verified verifier 902, which is more trustworthy than application 901. The verifier may include a transaction confirmation component 909 (e.g., to allow a user to confirm the confirmation text described herein) and a user verification component 906 (e.g., to allow biometric or other types of user verification). In one embodiment, verification module 903 uses private key 905 to generate a signature 908 on an object, which includes verifier attributes and application data to generate a signed object 907. As shown, in one embodiment, the object to be signed includes a concatenation of verified attributes of the verifier and application data. Verified attributes used in the signed object may include, for example, (a) a transaction text confirmed by the user, (b) the actual personal identification number (PIN) length relative to a minimum PIN length, or (c) the firmware version of the verifier implementation.

[0090] The illustrated implementation is more secure than existing systems because it grants exclusive control of key 905 to verifier 902 (rather than to application 901). In one implementation, the object to be signed, exclusively controlled by verifier 902, has data controlled by application 901 (in... Figure 9The "time slot" is reserved for the application data (identified as "application data"). Therefore, in this implementation, application 901 is not allowed to arbitrarily create any form of object to be signed. Each signed object will look similar, so the object verification module 911 of the dependent party 910 can believe that the verified attributes were contributed by the trusted verifier 902. In one implementation, the object verification module 911 uses a public key and metadata 912 associated with verifier 902 (e.g., verifier type, model, and / or version) to verify the signature 908.

[0091] In one implementation, a set of typical building blocks is defined, which can be used to assemble, for example... Figure 9 The verification system shown. A specific set of building blocks includes:

[0092] 1. Hardware and / or software used to generate cryptographic keys and verify such keys to a remote party.

[0093] 2. Used to generate verified signed hardware and / or software.

[0094] 3. Used to verify the user's hardware and / or software.

[0095] 4. Hardware and / or software used to bind a key to an entity (e.g., restricting access to the “use” of such a key to a defined set of software applications).

[0096] Not all building blocks are required. A verification system can be built using only building block #1. Other building blocks can be added as needed. The overall security and usability characteristics depend on the specific implementation of the building blocks used.

[0097] Figure 10 A specific implementation is shown, which includes a client-side authenticator 1001, a client-side platform 1002 (e.g., a mobile device using Android OS or Windows OS), a remote party 1003, and metadata 6304. One implementation of authenticator 1001 generates an authentication key and supports verifying the authentication key to the remote party 1003. Various authentication methods are supported, including those described above. See also FIDO Basic Authentication (Rolf Lindemann, Davit Baghdsaryan, and Eric Tiffany, 2014), DAA (Ernie Brickell, Intel Corporation; Jan Camenisch, IBM Research; Liqun Chen, HP Labs, 2004), and ECDAA (Ernie Brickell, Intel Corporation; Jiangtao Li, Intel Labs).

[0098] The remote party has access to metadata 1004, which it uses to verify the verifier object. The verifier can be implemented as a physically separate entity (e.g., an encrypted SD card, a USB encrypted token, etc.), or it can be physically embedded in the client-side platform (e.g., an embedded secure element, a TPM, a TEE).

[0099] Verifier 1001 may optionally have the ability to verify users. However, the basic principles of the invention are not limited to any particular user verification method. Nevertheless, a remote party can learn about the user verification method by investigating the verification object and metadata 1004.

[0100] The embodiments of this invention do not depend on any specific wired protocol or protocol message encoding. The only requirement is that the assertions generated by the verifier 1001 (such as verified objects and verified signature objects) need to be "understood" by the remote party 1003. The specific wired format may depend on the specific platform.

[0101] This section aims to give a first impression of how these typical building blocks can be used.

[0102] In current verification frameworks (such as the FIDO UAF specification), the client is very "heavy." The approach described in this paper easily divides the client into two parts: (1) an application software development kit (AppSDK) that performs all protocol-related tasks (tasks too specific to be implemented in a platform); and (2) platform functionality that performs security-related tasks, such as binding keys to a set of software applications. With this approach, the client as a separate entity (such as a FIDO client) disappears.

[0103] The following is an example of FIDO UAF implemented on an Android platform that has been extended to support these typical building blocks.

[0104] Confirmation type No explicit setting is required. All Android applications will know that they can only use Android verification methods (e.g., via the FIDO AppSDK).

[0105] AAID A unique identifier for each type of validator (e.g., "Validator Verification ID" as described above). Essentially, the AAID is simplified to a specific Android keystore implementation using the user verification method specified when the key is created. The keystore will look up the AAID based on the user verification method (and static knowledge about its own keystore cryptographic implementation).

[0106] usernameOne implementation allows mobile applications (via AppSDK) to set KeyAlias ​​as a cascade of keyID and username (if present).

[0107] AppID Use appID binding (if supported) for addressing.

[0108] In summary, one embodiment of the present invention includes a system for verifying a client-side authenticator to a remote party, the system comprising:

[0109] (1) A client-side verifier, comprising (i) circuitry and / or program code for generating cryptographic key pairs (“verification keys”), and (ii) circuitry and / or program code for verifying the identity of the key-generating entity to a remote party.

[0110] (2) Data about the validator, which contains at least enough information to verify the authenticity available to the remote party. This data is referred to above as “metadata”.

[0111] (3) Circuit and / or program code that uses the generated verification private key to perform cryptographic operations to prove to a remote party that it possesses the private verification key.

[0112] Additionally, it may be known that the verifier limits the use of the private key to performing cryptographic signing operations only on objects explicitly defined as to be signed. This explicitly defined object contains data fields controlled by the verifier, and one or more data fields clearly marked as containing arbitrary data (not controlled by the verifier). The verifier can indicate such objects by starting the object with a magic number MN, followed by an explicitly defined data structure. This signing operation is referred to herein as a "verified signature." The magic number MN is freely chosen, but it must be fixed and well-known. An example of how to set this magic number is "ATTESTED_SIGNATURE".

[0113] Additionally, in one implementation, the client-side authenticator has the ability to authenticate users using any user authentication method, wherein the characteristics of the user authentication method are static (i.e., they do not change over time for any authenticator) and are described in metadata. The user authentication method can be arbitrarily complex and even include multiple biometric and non-biometric forms (e.g., PIN or fingerprint, speaker recognition combined with PIN / fingerprint, facial recognition, etc.).

[0114] Furthermore, in one implementation of the system, (a) the key can only be used for verified signatures, and (b) the verifier has the ability to verify users using user verification methods, wherein the characteristics of the user verification methods are described in data fields controlled by the verifier (e.g., in verified signatures). It should be noted that user verification methods can be arbitrarily complex and may even include multiple biometric and non-biometric forms (e.g., PIN or fingerprint, speaker identification combined with PIN / fingerprint, facial recognition, etc.).

[0115] In one implementation, access to the private verification key 905 is restricted to a specified set of applications. Alternatively, this set can be limited to applications deemed equivalent by the platform (e.g., an operating system). For example, the operating system may restrict access to the verification key to applications that sign using the same block signing key as the application that generated the trigger key. Furthermore, this set of applications may include those considered equivalent by the application developers through a list of application aspects deemed equivalent.

[0116] In yet another implementation, validator 902 supports securely displaying transaction text and requiring the user to confirm (or reject) the specific transaction. The transaction text can be cryptographically bound to a verified signature (i.e., the cryptographic hash of the transaction text will be included in one of the fields controlled by the validator).

[0117] One embodiment of the invention implements security-related tasks of the FIDO UAF / U2F stack on a platform (e.g., an OS or a web browser) that are not part of the verifier, and leaves the implementation of other protocol processing tasks to the application, thereby removing the need to implement specific protocols in the platform (i.e., removing the need for a FIDO client).

[0118] Systems and methods for guiding user binding

[0119] Today, any user can register with a new FIDO authenticator or a device with a keystore being shipped / purchased, including both legitimate owners and potential attackers. Generally, once a user first receives physical access to a device with a keystore, the FIDO authenticator and the device are bound to the user (i.e., the user registers with the authenticator / device). This contrasts with smart cards (e.g., EMV bank cards and SIM cards) that are personalized for the user before delivery. This personalization typically includes a user-specific Personal Identification Number (PIN).

[0120] Sometimes, users are identified / screened before the FIDO authenticator (or device with a keystore) is shipped. It is desirable to utilize identity verification performed in a store (or elsewhere) and to bind the authenticator to the user before the authenticator actually reaches the user. Embodiments of the present invention provide a technique to address this requirement.

[0121] In one implementation, it is assumed that a trusted identification system has access to (a) user verification reference data (e.g., a biometric template or PIN), or (b) some data from which the user verification reference data can be derived, or (c) some data bound to the user through some other system. For example, a copy of the user's facial image obtained from a photo ID card verified at a branch office, or a photograph of the user's fingerprint obtained from a government identification database or through a SIM card bound to a authenticator and by a mobile network operator (MNO) to the account owner. Method (a) applies to the "what you know" factor; method (b) applies to the "who you are" factor; and method (c) applies to the "what you own" factor, as described below.

[0122] One implementation includes some form of secure communication channel to the validator, allowing user verification reference data to be injected into the validator once and initially (i.e., in a state where no other user has registered verification reference data). The secure communication channel can be a Trusted Service Manager (TSM) that securely communicates with a SIM card-based validator, or a TSM that securely communicates with a Trusted Execution Environment (TEE)-based validator, or it can be implemented by some cryptographic or private key used by the validator to decrypt such data. In any case, one implementation of the validator may include a preprocessing engine that transforms the initial reference data into the form required by the validator. It should be noted that this preprocessing can also be performed by a trusted system.

[0123] Figure 11 One specific implementation is shown, in which the user U being reviewed... V The initial verification of the user's identity is provided to the first dependent party 1104. For example, dependent party 1104 could be a physical store where the user purchased a new mobile device. During this process, a PIN or other identification code may be generated by dependent party 1104 (e.g., randomly generated or generated by the user being verified). V (Optional). This identification code is one form of Initial User Verification Reference Data (IUVRD) used herein to verify user identity during user registration. Furthermore, the dependent party 1114 may store identification data associated with the user and / or client device within the identity database 1120.

[0124] Subsequently, at 1101, user verification data is securely provided to user 1112. For example, the identification code can be mailed to the user via a tamper-proof or tamper-proof (e.g., sealed) envelope. Alternatively, the dependent party 1114 can provide the identification code to user 1114 at the store where the device was purchased. At 1102, the IUVRD is provided from dependent party 1114 to verifier 1110 via a secure communication channel (e.g., at the store and / or encrypted using a key or key pair known to dependent party 1114 and verifier 1110). In one embodiment, the communication can be encrypted into a verifier model / instance to prevent abuse. At 1103, when verifier 1110 is first registered with dependent party 1115, verifier user U is prompted. A User 1111 enters verification data. In one embodiment, validator 1110 includes a FIDO validator, and dependent party 1115 includes a FIDO server. If user 1111 enters the correct verification code, validator 1110 can include that verification code as evidence of user 1111's identity in transactions with dependent party 1115 (e.g., when registering validator 1110 with dependent party). Furthermore, in one embodiment, dependent party 1115 can perform a lookup in an identity database to confirm validator 1110 and / or validator user U. A The identity of 1111.

[0125] Figure 12 Another implementation is shown, in which biometric data is initially presented to the user being reviewed, U. V The IUVRD is captured during the KYC process between 1112 and the dependent party 1114. For example, at 1201, an image of the user's face may be captured, and a facial recognition template may be generated; the user's fingerprint may be captured; and / or voice recognition may be performed. At 1202, the IUVRD is provided to the authenticator 1110 via a secure communication channel. This may be done, for example, at the store and / or may be encrypted and transmitted over a network to the authenticator 1110 (e.g., using a key or key pair known to the dependent party 1114 and the authenticator 1110). At 1203, the authenticator is prompted with the user U. A 1111 Biometric data is collected, such as by analyzing images of the user's face, collecting the user's fingerprints, and / or recording the user's voice. Verifier 1110 compares the collected data with IUVRD biometric data, and if a match is detected, provides evidence of the user's identity during registration with dependent party 1115. Furthermore, dependent party 1115 can perform a lookup in the identity database 1120 initially populated by dependent party 1114 to further verify the identity of user 1111.

[0126] Figure 13Another embodiment is shown, in which an identity module 1310, which may contain a symmetric key known to the dependent party 1114, is provided to user 1111 during or after the KYC process. In one embodiment, identity module 1310 includes a User Identity Module (SIM) card; however, the basic principles of the invention are not limited to any particular form of identity module. At 1302, the dependent party 1114 provides a challenge (e.g., a randomly generated random number) to the verifier 1110. At 1303, the verifier verifies the presence of identity module 1310 by generating a signature on the random number using the symmetric key. The verifier then provides this signature to the dependent party 1115 during registration. The dependent party 1115 can then verify the identity of user 1111 by transmitting the signature to the dependent party 1114, who can verify the signature using the symmetric key. The dependent party 1115 may also perform a lookup in the identity database 1120, as previously described.

[0127] One implementation of the verifier 1110 supports new IUVRD, one-time UVRD, and / or one-time identity binding handle (OT-IBH) extensions for FIDO registration. This extension includes encrypted user verification data (or data from which user verification data can be derived, or a hashed or encrypted identity binding handle).

[0128] In the case of the IUVRD extension, if no user has yet registered, verifier 1110 will use the data as Initial User Verification Reference Data (IUVRD) and treat the user as having registered with that data. In one implementation, verifier 1110 proceeds as specified in the FIDO specification (e.g., verifying the user, generating a Uauth key pair specific to the AppID / dependent party ID, generating a registration assertion and signing it with the verification key). Additionally, one implementation of verifier 1110 includes an extension that includes a success indicator in the signed registration assertion to indicate that the data has indeed been used by the verifier (and dependent party 1115 may assume the relevant user is registered with the verifier). This result indicator can be a simple Boolean value (i.e., the extension was processed or not processed), or it can be a cryptographic hash of the extension passed to verifier 1110. The latter is relevant if the extension includes a value encrypted to verifier 1110 but not verified by the initiator (e.g., asymmetric encryption of a PIN). If some users have already registered with validator 1110, then that validator will not process the IUVRD extension and therefore will not include it in the response assertion.

[0129] In the case of a one-time UVRD extension used in one implementation, the user verification reference data included in the extension is precisely applicable to its respective registration operation. As for the OT-IBH extension, this extension includes a random number and a possible additional identifier, followed by a hash value of a handle H concatenated with a random number and a possible additional identifier ID. More formally, it can be described as: OT-IBH = (Nonce, ID, Hash(H|Nonce|ID)).

[0130] Figure 13 The implementation shown (sometimes referred to herein as the "You Own" implementation) can utilize One-Time Identity Binding Handle Extension (OT-IBH). This concept will be described using a more specific scenario involving a SIM card that supports scalable authentication protocols, authentication and key agreements (EAP-AKA, see RFC4187 https: / / tools.ietf.org / html / rfc4187) for verification to mobile network operators (MNOs).

[0131] In this example, the dependent party 1114 could be a mobile network operator that has vetted account owners and issued them a SIM (or a personalized embedded SIM; generally, a "you-own" token). The MNO also (via the mobile network) receives a device identifier (e.g., an International Mobile Equipment Identity, IMEI) and verifies the SIM (and thus the International Mobile Subscriber Identity, IMSI, which is bound to it). Therefore, the MNO already has a good understanding of the account owner bound to a particular mobile device. If an authenticator is bound to such a mobile device, this existing identity binding can be used for the registration of authenticator 1110.

[0132] The FIDO specification carefully avoids exposing any globally associated handles through the validator 1110. Therefore, instead of simply having the validator add the IMEI or IMSI as an extension of the registration assertion or signature assertion, one embodiment of the present invention uses a different approach.

[0133] In the OT-IBH method, it is assumed that there exist some handles H bound to the user (e.g., via IMSI or IMEI, or both). Such handles H that are password-verified or encrypted may even be supported (e.g., H = MAC(IMEI|IMSI) or H = Enc(key, IMEI|IMSI)). This handle H is owned by the mobile network operator that issued the SIM.

[0134] Since the handle H does not depend on any specific dependent party (RP), H can be considered a globally associated handle. For privacy reasons, such a globally associated handle should not be known to multiple dependent parties. To achieve this, one implementation derives a dependent party-specific handle from it: Hd = Hash(H|Nonce|IDrp), where IDrp is the dependent party identifier, and the random number and IDrp are provided by the owner of H. The random number is some random value, and IDrp is some identifier associated with the dependent party that wants to utilize the identity binding performed by the MNO.

[0135] The MNO can use a backend service to publish the exported handle Hd to some RPs. The RP will provide some user identification information IDu (e.g., MSISDN) to the backend service. Users can provide this user identification information directly, or the RP application can retrieve this user identification information through some existing local APIs on the device.

[0136] Figure 14 A specific implementation is shown, in which the dependent application 1402 transmits User Identification Information (IDu) to the dependent party 1430 at 1401. At transaction 1402, the dependent party 1430 transmits the Idu to the MNO 1431, which responds at 1403 with a dependent-specific handle Hd. At 1404, the dependent party 1430 sends a FIDO request to the dependent application 1412. In response, the dependent application 1412 sends a FIDO registration content or verification request to the validator 1410 at 1405, and at 1406, the validator performs verification with the SIM 1413. If the verification at 1406 is successful, the FIDO transaction at 1407-1408 includes Hd. If the verification fails, Hd will not be included in the FIDO response.

[0137] The above implementation is more secure than using H as a bearer token because the validator cryptographically binds H to an assertion generated by a specific validator. This prevents man-in-the-middle (MITM) attacks, thus allowing for a longer lifespan for H.

[0138] This implementation is also more privacy-preserving because the verifier 1410 will not disclose H; if the application 1412 receives access to H through other means such as a contractual relationship with the entity that issued H (e.g., MNO) or via some API available to the application 1412 on the mobile device 1411 (to which the user has granted access), the verifier will only allow the application to verify H.

[0139] The following exemplary use cases can be implemented. However, it should be noted that the basic principles of the invention are not limited to these specific use cases.

[0140] Use Case 1 :

[0141] In some branches / stores, users can be vetted by identification systems such as electronic ID card readers, fingerprint scanners, or cameras. The identification system verifies the authenticity of the ID card (whether the ID card is being used) and then converts the captured data (either directly captured from the user or from a trusted credential such as a government-issued ID card) into the format required by the authenticator.

[0142] The identification system encrypts the IUVRD data (as described above) and stores it along with the validator's customer order. The order details are sent to the fulfillment center, and the validator is delivered to the customer.

[0143] Once a customer uses the validator for the first time, it will automatically trigger the validator to register with the server, providing an order number (or similar identifier) ​​that allows the server to learn about potential users. The server will then add the appropriate IUVRD extension to the FIDO registration request, and the validator will process the registration request as specified above.

[0144] Use Case 2 :

[0145] If the user is at home and orders the authenticator online, the user can provide a scan of his / her photo ID card as proof of identity. The server-side identification system verifies the integrity of the scan and extracts the IUVRD from it. This is done as in Use Case 1, where the identification system verifies authenticity.

[0146] Use Case 3 :

[0147] Similar to use case 2, but using a PIN and a PIN-based validator (e.g., SIM-based) or a validator that supports PIN and some other user verification methods.

[0148] Use Case 4 :

[0149] Sometimes, a device and / or an entity bound to the device (e.g., something a user owns such as a SIM card) is already bound to a user (e.g., a mobile phone account holder). This binding may already be represented by some generic handle H (e.g., some holder token and / or globally associated handle, such as a user's phone number or device IMEI), and may even be encrypted or hashed, such as a MAC (phone number #+IMEI) or HMAC (MSN+IMEI) held by a particular dependent party (e.g., an MNO). One implementation allows the dependent party to query the validator in a privacy-preserving manner whether the validator is bound to this handle H in some way, rather than revealing such a handle H directly to a dependent party via the validator. See the OT-IBH section for details.

[0150] Because at least one of the above implementations is only valid once for an unused validator (unless a factory reset is performed), it only allows validator vendors (not necessarily manufacturers) to effectively use it from the outset. In a typical implementation, this would be a mobile network operator selling validators tied to smartphones. The “one-time UVRD” implementation allows validator manufacturers to use the method at any time, while the “selective UVM” implementation allows any RP or may be limited to using the method for a specific RP.

[0151] Encryption details

[0152] Multiple cryptographic implementation options are possible. In one implementation, a symmetric encryption key for the IUVRD / One-Time UVRD / OT-IBH is shared between the validator and the identification system. In this case, the IUVRD / One-Time UVRD / OT-IBH is protected by verification encryption. Alternatively, an asymmetric encryption / decryption key combined with an asymmetric public key can be used as a trust anchor within the validator. The IUVRD / One-Time UVRD / OT-IBH can be signed by the identification system and then encrypted using the public encryption / decryption key. In both cases, it can be assumed that the key is validator-specific to prevent replay attacks on other validators.

[0153] Privacy impact

[0154] Privacy impact is minimal when the RP can perform identity binding on its own Uauth key. The IUVRD extension allows the first RP to perform identity binding to the validator if it possesses validator-specific cryptographic material.

[0155] One-time UVRD extensions allow any RP to perform identity binding to a validator if it has validator-specific cryptographic material.

[0156] The OT-IBH implementation allows any RP that has been granted access to handle H via some other existing means (e.g., some native APIs already available to the application or some backend APIs that have access to the RP's "own" handle H) to cryptographically verify that the validator is indeed bound to it.

[0157] In one implementation, one or more of the following privacy policies shall be followed: Private UAuth keys shall never be exposed outside the validator boundary. User verification reference data registered to the validator shall never be disclosed by the validator. The validator shall never disclose the number or name of the dependent party to which it is registered. The validator shall never disclose any globally associated handles. No RP can modify the user verification reference data of an existing key at any time.

[0158] An RP can query a validator to determine if it is bound to a particular user (specified by the extension). However, users participate in such queries (through user verification) and may also know the name of the relevant RP, depending on the validator model.

[0159] Systems and methods for sharing keys across validators

[0160] motivation

[0161] Current FIDO specifications (UAF, U2F, and FIDO2 / Web Authentication) expect authentication keys (e.g., UAuth keys) to be dedicated to individual validator instances. Users can register multiple validators for each account / dependency. If a user loses any validator (other than the one they registered last time), they can simply authenticate with one of the remaining validators and then register a new / replaced validator.

[0162] In reality, users face two pain points. First, if a user loses the authenticator they registered with, the relying party needs to push the user through the account recovery process. Account recovery is a troublesome process, and may even involve out-of-band checks. Account recovery is sometimes a risky process and is not as secure / trustworthy as FIDO verification.

[0163] In addition to registering new validators, users must also individually revoke the registration of lost / stolen validators at each dependent party and register new validators at each dependent party. The process of registering new validators or revoking the registration of old validators can be quite tedious, as users typically have multiple accounts.

[0164] The embodiments of the present invention described herein address the aforementioned issues using a client-side biometrics solution.

[0165] method

[0166] One approach is to keep each UAuth key dedicated to a single validator and propose a standardized registration / removal API for dependent parties to automatically add / remove validators (as described above relative to some implementations). However, standardizing the Web API across dependent parties is challenging and time-consuming. Therefore, success cannot be guaranteed.

[0167] One embodiment of the present invention extends the above-described specific implementation to share keys across multiple validators.

[0168] Traditional FIDO verifier

[0169] Registering additional validators requires a manual action for each dependent party. This manual action can even include multiple steps (e.g., opening the application, clicking "Register Additional Validator," and performing user verification). This is the traditional FIDO model known in the art.

[0170] UAuth key of package synchronized via cloud service

[0171] In one embodiment of the invention, a user uses different instances of the same authenticator model (e.g., identified by AAID / AAGUID). According to the FIDO specification, such authenticators will have similar security characteristics, with no authenticator offering lower security than declared in the metadata statement. Therefore, for example, authenticators of this category may require Trusted Execution Environment (TEE) security, and some implementations may even use secure elements for key protection. More specifically, an authenticator may be bound to a smartphone using a TEE for key protection, matcher protection, and transaction confirmation display, and may use fingerprints as a user authentication method. Another authenticator sharing the AAID may be implemented as a smart card with an integrated fingerprint sensor and e-ink transaction confirmation display, and using secure elements for key and matcher protection.

[0172] In addition, these validators allow users to:

[0173] a) A copy of the validator's persistent storage (i.e., private key material, along with the associated username and AppID) is stored in a package on the cloud service. Only validators belonging to the same user-defined group can unpack these packaged persistent data blocks.

[0174] (b) The first validator defines the group, represented by a symmetric wrapper key. Users can add other validators to the group by approving the "join" process on the first validator.

[0175] Validator Encryption Details

[0176] In one implementation, the validator supports FIDO functionality (e.g., it has a FIDO verification key and supports the generation of FIDO Uauth keys). However, it should be noted that the basic principles of the invention are not limited to specific FIDO implementations. Figure 15 An exemplary embodiment is shown, wherein a first client device 1518 includes a validator that has joined group Aj, and a second client device 1519 includes a validator that has joined group Ag. Each validator in Aj and Ag includes physical verification devices 1521-1522, verification engines 1511-1512 with key synchronization logic components 1520-1521 for implementing the techniques described herein, and secure storage devices 1625-1626 for storing the various types of encrypted data described herein. Although some details are not shown, client device 1519 may store all the same data as client device 1518. Figure 15 As shown, in one implementation, each validator:

[0177] a) Has public cloud storage access ID encryption keys (CSEK) 1501, 1511 (e.g., as a trust anchor).

[0178] b) Has a random group ID (e.g., UUID) overwritten by each joining procedure, 1502,

[0179] 1512, each joining procedure is implemented by key synchronization logic components 1520 to 1521 of the verification engines 3710 to 1511.

[0180] c) It has separate asymmetric package key encryption keys (WKEK) 1503, 1513. These can be generated by verifiers 3710 to 1511 upon first use and are inaccessible outside of the verifiers.

[0181] d) Having symmetric package keys (WK) 1504, 1514, which can be generated upon first use and overwritten by each joiner.

[0182] e) In one specific implementation, key synchronization logic units 1520-1521 implement the following joining procedure. There is an API function that can request validator Aj to join an existing group of validators. The validator Aj to join generates a random value, requests permission from the user (i.e., triggers user verification by displaying a joining procedure indicator and the random value on the screen), appends its AAID1505 and public WKEK 1503 to the random value, and uses its verification key.

[0183] 1506 signed it. This data block is called the "join block" or "trust block".

[0184] f) A validator in group Ag receives an join block verified by key synchronization logic unit 1521. This is possible because the validators know the acceptable public verification key (trust anchor) used for signature verification. Verification engine 1511 displays a random number, AAID 1505, and join request indicator on its display. If the user approves the action (e.g., through normal user verification), key synchronization logic unit 1521 uses the public WKEK 1503 encrypted package key (WK) 1514 and group ID 1512 received in the join block. This data block is invoked in the join response block.

[0185] g) Aj decrypts the added response block and stores the package key (WK) 1514 and group ID 1512.

[0186] h) One implementation supports an API function to retrieve a synchronization pull request from validator Aj (given a random value retrieved from cloud service 1550). The key synchronization logic unit 1520 on validator Aj returns a concatenation of a random number provided by the server, a group ID 1502, and a hash value (e.g., the synchronization pull request) from internal persistent storage encrypted by CSEK 1501. This function is triggered by an external module (e.g., ASM, validator configuration application). Once cloud service 1550 receives the synchronization pull request, secure transaction service 4004 decrypts the block and compares the state hash value with the hash value received along with the latest data block. If the results differ, it returns a synchronization pull response, i.e., the latest packaged data block encrypted by WKEK 1503; otherwise, it returns a "no changes" code.

[0187] i) Supports API functions to handle synchronous pull responses. The key synchronization logic unit 1520 decrypts the block using its proprietary WKEK1503 and then uses the symmetric wrapping key (WK).

[0188] 1504 Unpack the data. If both operations are successful, the verification engine 3710 updates its internal persistent storage accordingly. Note that this update process supports merging various components (i.e., keys generated on this verifier that have not yet been synchronized to cloud 1550).

[0189] j) Support another API function to trigger the generation of a synchronization push request in the validator. This API function triggers the key synchronization logic unit 1520 to return a random number, group ID 1502, and a hash value of the internal persistent storage cascaded with the wrapped persistent storage, all of which are used...

[0190] CSEK 1501 encryption (i.e., allowing cloud service 1550 to read the random number, group ID 1502, and hash value, but not to unpack the persistent storage containing the private key material). Note that the validator first needs to perform a synchronous pull with cloud service 1550 to merge changes before generating a synchronous push request.

[0191] characteristic

[0192] Using the method described above, a new validator can be easily added to the group in a single operation. The joining process can be performed independently of the cloud service. However, a drawback is that if a user loses their last registered validator, a full account recovery is required, which can be cumbersome for the user.

[0193] Synchronize password-protected Uauth keys via cloud service

[0194] One embodiment of the invention is similar to the method described above, with one difference being that the symmetric wrapping key (WK) can be derived from a user-provided password. Specifically, step (d) above is supplemented with the ability to overwrite the current WK with a WK derived from the password (e.g., via a dedicated API function). In one embodiment, the password is always entered on the authenticator's secure display.

[0195] Furthermore, in one implementation, step (h) above is modified as indicated in bold in the following paragraph. Specifically, the key synchronization logic unit 1520 returns a concatenation of the server-supplied random number, group ID 1502, WKEK 1503, and a hash value (synchronization pull request) of internal persistent storage, first signed by the verification key 1506 and then encrypted by CSEK 1501. This function is triggered by an external module (e.g., ASM, validator configuration application). Once received by the cloud service, it decrypts the block, verifies the verification signature, and compares the state hash value with the hash value received along with the latest data block. This method (combined with encryption of the WKEK) allows the cloud service to restrict access to the wrapped storage block to validators with the correct model (e.g., preventing brute-force attacks on the password by other validators / attackers). If the results differ, it returns a synchronization pull response, i.e., the latest wrapped data block encrypted by WKEK 1503; otherwise, it returns a "no changes" code.

[0196] Apart from the differences highlighted above, the remaining operations in (aj) are performed as previously described.

[0197] characteristic

[0198] Using the method described above, a new validator can be easily added to the group with a single operation. If a user loses their last validator, they can recover it by providing their password. Brute-force attacks on the password are prevented by encrypting the wrapped storage block with the corresponding verified WKEK. However, a drawback is that the cloud service provider still retains access to the wrapped storage block, making brute-force password cracking possible.

[0199] Adding a validator to the rollback function in the cloud

[0200] In one implementation, to address the aforementioned limitations, a special authenticator 1540 used by cloud service 1550 protects the packaged data and the CSEK 1501 private key. This authentication module is a unique type of authenticator with the following characteristics:

[0201] 1. This authenticator supports multiple users in a single hardware box, similar to the bound UAF authenticator used by tablets that support multiple OS accounts.

[0202] 2. This authenticator only supports remote user verification via another authenticator that happens to have the model used during the initial registration.

[0203] 3. This validator does not allow users to actually use any Uauth key for verification; it only supports approving other validators to join the group.

[0204] Therefore, the cloud-based validator 1540 can join the group just like any other validator.

[0205] Validator Encryption Details

[0206] One embodiment of the invention is similar to the prior art, but utilizes additional technologies for registering with a cloud service and using a cloud-based joining authenticator. These new technologies are highlighted in bold. In this embodiment, each authenticator:

[0207] a) Has public cloud storage access ID encryption keys (CSEK) 1501, 1511 (e.g., as a trust anchor).

[0208] b) Has a random group ID (e.g., UUID) overwritten by each joining procedure, 1502,

[0209] 1512, each joining procedure is implemented by key synchronization logic components 1520 to 1521 of the verification engines 3710 to 1511.

[0210] c) It has separate asymmetric package key encryption keys (WKEK) 1503, 1513. These can be generated by verifiers 3710 to 1511 upon first use and are inaccessible outside of the verifiers.

[0211] d) Having symmetric package keys (WK) 1504, 1514, which can be generated upon first use and overwritten by each joiner.

[0212] e) It can be "registered" with cloud service 1550 to create new partitions. One implementation of this process may include FIDO registration:

[0213] 1. The user obtains an authenticator Aj and registers it with cloud service 1550. The user also provides his email address to identify his partition.

[0214] 2. Based on the cloud, Validator 1540 creates a "partition" for registered Validator Aj. This partition is identified by the associated UAuth public key. Each "partition" has its own set of persistent data (including key material).

[0215] f) Can be "registered" to an existing partition of the cloud service (restore joining):

[0216] 1. The user enters his / her email address for the existing partition.

[0217] 2. The user obtains a validator Aj and registers it with the cloud service.

[0218] 3. Note that this authenticator has not yet been approved. The only action a user can trigger is the join process using this authenticator as Aj (and using the cloud-based join authenticator 1540 as Ag). In one implementation, only when the authenticator's AAID 1505 matches the AAID of the authenticator that originally created the partition (e.g.,

[0219] The process will only succeed if the values ​​of AAID 1515 are the same.

[0220] g) The following joining procedures are supported:

[0221] 1. There exists an API function that can request a validator to join an existing validator group. The validator to be joined (Aj) will generate a random value, request permission from the user (i.e., trigger user verification by displaying a join process indicator and the random value on the screen), append its AAID and public WKEK to the random value, and sign it using its verification key. This data block is called the "join block" or "trust block".

[0222] 2. This feature is also supported by the cloud-based Join Validator 1540.

[0223] a. The user first requests the cloud-based joiner 1540 to join the group (initialized by the authenticator Aj who first "registered" with the cloud service).

[0224] b. In this case, the cloud-based joining validator acts as Aj, and the user's initial validator acts as Ag.

[0225] c.Ag authenticates with the cloud service and calls the Aj.join API function. When calling the API function, cloud service 1550 passes Ag's AAID 1515 to Aj.

[0226] Aj responds by joining a block (see above).

[0227] d.Ag performs step h below and sends the appended response block to Aj.

[0228] e.Aj stores group ID 1502 and WK 1504 in the relevant "partition". h) A validator Ag in the joining group receives the join block, and the key synchronization logic unit 1521 verifies it. This is easily implemented because the validators know the acceptable public verification key (trust anchor) used for signature verification. Ag displays a random number, AAID 1515, and a join request indicator on its display. If the user approves the action (verified by a normal user), the validator uses the public WKEK 1513 encrypted package key (WK) 1514 and group ID 1512 received in the join block. This data block is invoked in the join response block.

[0229] i) Aj will decrypt the response block and store the package key (WK) 1504 and group ID 1502.

[0230] j) One implementation supports an API function to retrieve a synchronization pull request from validator Aj (given a random value retrieved from cloud service 1550). Specifically, key synchronization logic unit 1520 returns a concatenation of a random number provided by the server, group ID 1502, WKEK 1503, and a hash value (synchronization pull request) first signed by verification key 1506 and then encrypted by CSEK 1501 in internal persistent storage. This function is triggered by an external module (e.g., ASM, validator configuration application). Once received by the cloud service, it decrypts the block, verifies the verification signature, and compares the state hash value with the hash value received along with the latest data block. This approach (combined with encryption of the WKEK) allows the cloud service to restrict access to the wrapped storage block to validators with the correct model (e.g., preventing brute-force attacks on the password by other validators / attackers). If the results differ, it returns a synchronous pull response, which is the latest package data block encrypted with WKEK 1503; otherwise, it returns a "no changes" code.

[0231] k) Supports API functions for handling synchronous pull responses. The key synchronization logic unit 1520 decrypts the block using its proprietary WKEK1503 and then uses the symmetric wrapping key (WK).

[0232] 1504 Unpack the data. If both operations are successful, the verification engine 3710 updates its internal persistent storage accordingly. Note that this update process supports merging various components (i.e., keys generated on this verifier that have not yet been synchronized to cloud 1550).

[0233] (l) Another API function is supported to trigger the generation of a sync push request in the validator. This API function triggers the key synchronization logic unit 1520 to return a random number, group ID 1502, and a hash value of the internal persistent storage cascaded with the wrapped persistent storage, all encrypted with CSEK 1501 (i.e., allowing the cloud service 1550 to read the random number, group ID 1502, and hash value, but not to unpack the persistent storage containing the private key material). Note that the validator first needs to perform a sync pull with the cloud 1550 to merge changes before generating the sync push request.

[0234] characteristic

[0235] Using this method, adding a new validator to the group with a single operation is relatively easy. If a user loses their last validator, they can recover it by providing their password. Brute-force attacks on passwords are prevented by encrypting the wrapped storage block using the corresponding verified WKEK. Cloud service providers would have to compromise cloud-based join validators to brute-force passwords. Therefore, cloud-based join validators should use security element-based security. The verification statement reflects its security.

[0236] Unfortunately, users cannot revoke the individual validator members in their recovery group.

[0237] The rollback policy in the cloud includes adding validators and automatic key deletion policies within validators.

[0238] This method supplements the previous method as follows: Each validator (except for cloud-based joining validators) will delete its persistent private key store (WK, WKEK, Uauth key, etc.), except for the confirmation private key after a configurable time period, unless the validator persistent storage is resynchronized to cloud storage. Therefore, validators require a reliable internal clock / timer.

[0239] Users have the ability to remove individual validators from a group via cloud storage. If a validator has been removed, it can no longer be synchronized.

[0240] Validator Encryption Details

[0241] This method complements the previous method as follows (where key features are highlighted in bold). The validator supports another API function to retrieve a synchronous pull request from the validator (given a random value retrieved from the cloud service). The validator returns a synchronous pull response, a concatenation of the random number provided by the server, Group ID 1502, WKEK 1503, and a hash value (synchronous pull request) that is first signed by the verification key and then encrypted by CSEK 1501 in internal persistent storage. This function is triggered by an external module (e.g., ASM, validator configuration application). Once received by the cloud service 1550, it decrypts the block, verifies the verification signature, and compares the state hash value with the hash value received along with the latest data block. It returns a synchronous pull response, the latest wrapped data block encrypted by WKEK 1503. In one implementation, if the hash values ​​do not match, the cloud service 1550 increments a mismatch counter. A very high counter value indicates an increased risk.

[0242] In one implementation, the validator supports API functions to handle synchronous pull responses. The validator decrypts the block using its private WKEK and then unpacks the data using a symmetric wrapping key WK. If both operations are successful, the validator updates its internal persistent storage accordingly and resets its internal cloud sync pointer.

[0243] characteristic

[0244] Using this method, new validators can be easily added to the group with a single operation. If a user loses their last validator, they can recover it by providing their password. Brute-force attacks on passwords are prevented by encrypting the wrapped storage blocks with the corresponding verified WKEK.

[0245] Cloud service providers would have to compromise cloud-based join authenticators to brute-force passwords. Therefore, cloud-based join authenticators should use secure element-based security. The authentication statement reflects its security.

[0246] Furthermore, in this specific implementation, users can "revoke" validators from the recovery group by removing each validator member from the group.

[0247] Sensitive Data Migration Card

[0248] One embodiment of the present invention uses a dedicated chip card (ICC) instead of a cloud service, the dedicated chip card in Figure 16 The diagram shows a Data Migration Card (DMC) with secure storage 1626, used to store protected backups of all UAuth keys and even all other sensitive data stored on client device 1518. To “back up” sensitive data, the user connects to client device 1518 (or directly to the authenticator) containing the bound authenticator Aj via the secure storage interface 1610 of the DMC 1601. The user confirms to authenticator Aj that they want to back up the data to the DMC 1601. This step erases all existing data on the DMC.

[0249] Depending on the configuration, the secure storage interface 1610 can remember the validator model (AAID, AAGUID) or a model with similar security features (e.g., a key + matcher protected by a TEE, etc.) and will only restore the data to the same model or a model with similar security features.

[0250] In one implementation, validator Aj will only back up the key to a DMC 1601 with acceptable security features (e.g., a model configured in the validator). The DMC 1601 will only restore the key to a validator with acceptable security features (e.g., a model identical to the original validator). Security mechanisms can be implemented using validator / DMC verification.

[0251] In one implementation, the second verifier can act as a DMC (e.g., via NFC+BLE). For example, in Figure 15 In this process, all keys stored in the secure storage 1525 of the client device 1518 can be securely migrated to the secure storage 1526 of the client device 1519.

[0252] DMC Encryption Details

[0253] In one implementation, the DMC is similar to a traditional (external) validator. Therefore, the DMC and each validator supporting it can perform the same key synchronization techniques described above for joining and managing join blocks or trusted blocks.

[0254] For example, in one implementation, a validator can be "registered" with the DMC. This can be achieved via FIDO registration, where a user acquires a validator and registers it with the DMC. The user also provides an identifier (e.g., their email address) to identify their partition within the DMC (only required if the DMC supports multiple partitions). Furthermore, the DMC can create a "partition" for each registered validator (if it supports multiple partitions; otherwise, it uses its unique, pre-configured partition). This partition is identified by the associated Uauth public key. Each "partition" has its own set of persistent data (including key material).

[0255] Validators can also be "registered" to existing partitions on the DMC (restore join). The user enters an identifier for the existing partition (e.g., an email address) and registers a validator with the DMC. Note that the validator has not yet been approved. The only action a user can trigger is to use that validator as the join Validator for Aj (and the DMC as the join Validator for Ag). The process will only succeed if the validator's AAID is the same as the AAID of the validator that originally created the partition.

[0256] Furthermore, in one implementation, there is an API function that allows a validator to join an existing validator group. This functionality is also supported by DMC joining validators. The user first requests DMC joining validators to join the group (initialized by the validator that was first "registered" to the cloud service). In this case, the DMC joining validator acts as Aj, and the user's initial validator acts as Ag. Ag validates with DMC and calls the Aj.join API function. DMC passes Ag's AAID to Aj when calling the API function. Aj responds with a join block (see above). Ag performs step h below and sends the join response block to Aj. Aj then stores the group ID and WK in the relevant "partition".

[0257] Exemplary data processing device

[0258] Figure 17 This is a block diagram illustrating exemplary clients and servers that can be used in some embodiments of the present invention. It should be understood that, although... Figure 17 Various components of a computer system are illustrated, but they are not intended to represent any particular architecture or manner of interconnecting the components, as such details are not closely related to the present invention. It should be understood that other computer systems with fewer or more components can also be used with the present invention.

[0259] like Figure 17 As shown, computer system 1700, a type of data processing system, includes a bus 1750 coupled to a processing system 1720, a power supply 1725, memory 1730, and non-volatile memory 1740 (e.g., hard disk drive, flash memory, phase-change memory (PCM), etc.). Bus 1750 can be interconnected with each other via various bridges, controllers, and / or adapters well known in the art. Processing system 1720 can retrieve one or more instructions from memory 1730 and / or non-volatile memory 1740 and execute these instructions to perform the operations described above. Bus 1750 interconnects the above components together and also interconnects those components to an optional docking station 1760, a display controller and display device 1770, input / output devices 1780 (e.g., NIC (Network Interface Card), cursor controls (e.g., mouse, touchscreen, touchpad, etc.), keyboard, etc.), and one or more optional wireless transceivers 1790 (e.g., Bluetooth, WiFi, infrared, etc.).

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

[0261] According to one embodiment of the present invention, an exemplary architecture of the data processing system 1800 can be used in the mobile device described above. The data processing system 1800 includes a processing system 1820, which may include one or more microprocessors and / or systems on integrated circuits. The processing system 1820 is coupled to a memory 1810, a power supply 1825 (which includes one or more batteries), an audio input / output 1840, a display controller and display device 1860, optional input / output 1850, one or more input devices 1870, and one or more wireless transceivers 1830. It should be understood that in some embodiments of the present invention, Figure 18 Other components not shown may also be part of the data processing system 1800, and in some embodiments of the invention, a ratio may be used. Figure 18 Fewer components are shown. Additionally, it should be understood that... Figure 18 One or more buses, not shown, can be used to interconnect various components well known in the art.

[0262] Memory 1810 may store data and / or programs for execution by data processing system 1800. Audio input / output 1840 may include a microphone and / or speaker to play music, and / or provide telephone functionality via a speaker and microphone. Display controller and display device 1860 may include a graphical user interface (GUI). Wireless (e.g., RF) transceiver 1830 (e.g., WiFi transceiver, infrared transceiver, Bluetooth transceiver, wireless cellular transceiver, etc.) may be used to communicate with other data processing systems. The one or more input devices 1870 allow a user to provide input to the system. These input devices may be keypads, keyboards, touch panels, multi-touch panels, etc. Optional additional input / output 1850 may be connectors to the dock.

[0263] Systems and methods for validator accreditation

[0264] In some cases, especially those involving electronic payments, multiple merchant applications need to verify payment credentials from users. Currently, simple holder tokens, such as master accounts (PANs) or tokenized PANs, are used for this purpose. This approach offers very limited security because such information can be used and exploited by malicious actors for phishing attacks.

[0265] Alternatively, stepwise verification schemes (e.g., three-domain security or 3DS) are sometimes used. These schemes essentially implement a “decoupled” model, requiring the issuer to trigger stepwise verification via an out-of-band channel. Currently, one-time passwords via SMS are primarily used for this type of stepwise verification, resulting in high cart abandonment rates (e.g., estimated at 15%).

[0266] Modern authentication concepts similar to FIDO offer significantly higher security and are supported by 3DS v2 for user-to-merchant authentication. Unfortunately, FIDO authentication is designed to verify credentials in an application-specific manner, resulting in a separate authenticator registration step for each merchant, which increases unwanted friction.

[0267] One embodiment of the invention uses a highly secure authentication technology such as FIDO, but allows seamless recognition of merchant-specific authentication credentials associated with a payment card or account instead of merchant-associated authentication credentials. Privacy is not an issue in this case because, by definition, the payment provider will be aware that a particular merchant has received payment from a user. Therefore, this embodiment avoids the need for authenticator registration for each application, while still allowing authenticators to be implemented within the merchant application via an embedded AppSDK.

[0268] The embodiments of the invention described herein may optionally utilize the techniques described in U.S. Patent No. 10,091,195 ('195 patent) published October 2, 2018, and U.S. Patent No. 9,413,533 ('533 patent) published September 2016.

[0269] One implementation of this validator-centric approach extends the FIDO validator with various new features, including secure (initial) sharing of user verification reference data between validators bound to the same platform. Furthermore, one implementation allows for the synchronization of user verification reference data between validators bound to the same platform.

[0270] Reference Figure 19 The architecture shown describes an implementation that includes a client device 1930 having a secure keystore 1925 for securely storing verification data (e.g., keys), a legacy application 1901 associated with a validator instance 1911, a first new application 1902 associated with a validator instance 1912, and a third new application associated with a validator instance 1913.

[0271] The applications used in these implementations may belong to different merchants, but still support the same payment scheme. To reduce user friction, the application aims to seamlessly recognize the user's verification credentials when verifying with the backend service 1940.

[0272] In one implementation, the user initially installs a legacy application 1901, which checks if another application supporting the same "scheme" and having a registered authenticator is already installed. If not, in one implementation, the user enters their user identifier (e.g., username, email address, or even possibly a tokenized PAN) and also enters a holder token such as a password or one-time password (e.g., a password received via SMS). The user is then authenticated by a backend service 1940, which issues a session token to application 1901.

[0273] In one implementation, application 1901 triggers the registration of its authenticator instance 1911 (e.g., via AppSDK). This operation may include requesting the user to provide user verification reference data (e.g., a PIN) and generating a verification key (FIDO credential).

[0274] See now Figure 20 In one implementation, the synchronization processor 1921 on the legacy application 1901 and the synchronization processor 1922 in the new application 1902 implement the techniques described herein. Specifically, when a user installs the new application 1902, application 1902 checks whether another application 1901 supporting the same "scheme" and having a registered validator instance 1911 is already installed. If so, the synchronization processor 1922 of the new application 1902 sends an approval request 1926 to the legacy application 1901 to "approve" the validator instance 1912 of that application. The synchronization processors described herein may be implemented in circuits, program code executing on circuits, or any combination thereof.

[0275] The approval request 1926 may include a public verification key and a verification object generated by the verifier instance 1912 of the new application 1902. The approval request may include a public encryption key for initial user verification reference data used to access the private verification key.

[0276] In one implementation, when the validator instance 1911 of the legacy application 1901 receives a request from the synchronization processor 1921, it verifies the source of the request against a list of trusted FacetIDs (e.g., using caller identification data associated with the request). This list may have been retrieved by the legacy application 1901 from the backend service 1940, or it may have been provided by the new application 1902 as a signed object with some version indication to prevent attacks that replay outdated versions of the FacetID list.

[0277] If the approval request is verified positively, the validator instance 1911 of the legacy application 1901 generates an approval response 1927. This response 1927 may be a session token retrieved from the "schema" backend service 1940, or it may be a signed approval object created by the validator instance 1911 without access to any backend servers, but including the public verification key and possibly some or all of the verification object as described above. See also... Figures 2 to 6 And associated text. It may also include initial user verification reference data for obtaining user access to the relevant private verification key. This data may be encrypted using the public encryption key included in the aforementioned authorization request.

[0278] In one implementation, the approval response 1927 returns to the synchronization processor 1922 that invoked the new application 1902, which then passes the approval response 1927 to the validator instance 1912. The validator instance 1912 retrieves the user verification reference data included in the response 1927, decrypts it using the keystore 1925, and updates its own state to request the new user verification reference data before using the private verification key.

[0279] Once a network connection to backend service 1940 is available, the synchronization processor 1922 of new application 1902 transmits an approval response 1927 to backend service 1940 and retrieves the verification session directly or after proving that it possesses one or more private keys associated with the verification keys generated by verifier instance 1912 as described above.

[0280] In one implementation, using relative to Figure 21 The following series of operations are used to synchronize user verification reference data. In this embodiment, the application's verifier instance 1912 receives a request from the user to change the verification reference data. The synchronization processor 1922 sends synchronization requests 2126A-B to each of the other applications 1901, 1903 installed on the same device 1930 that supports the same "scheme".

[0281] Each of the other applications 1901 and 1903 includes synchronization processors 1921 and 1923, respectively, which transmit synchronization responses 2127A-B and messages indicating interest in receiving updates. These responses 2127A-B may include an encryption key for the user verification reference data to be updated, and may also include the latest version of the list of signed FacetIDs known to the other applications 1901 and 1903.

[0282] The application's validator instance 1912 verifies the source of the message against a list of trusted FacetIDs (e.g., using the caller's identifier). This list may have just been retrieved from the server by application 1902, or it may have been provided by one of other applications 1901, 1903 as a signed object with some version indication to prevent attacks that replay outdated versions of the FacetID list.

[0283] At points 2128A-B, synchronization processor 1922 provides updated user authentication reference data to other synchronization processors 1921, 1923, making the reference data available to other validator instances 1911, 1913. In one implementation, the updated user authentication reference data can be encrypted using a public encryption key received in synchronization responses 2127A-B.

[0284] One implementation uses an ASM-centric approach based on a FIDO authenticator that supports client PINs, as described in the Client-to-Authenticator Protocol (CTAP) implementation draft of February 27, 2018 (see, for example, https: / / fidoalliance.org / specs / fido-v2.0-id-20180227 / fido-client-to-authenticator-protocol-v2.0-id-20180227.html#authenticatorClientPIN). This can include, for example, a PIN entered into the ASM (or platform) and sent to the authenticator via an API. This implementation uses the ASM embedded in an application to collect the PIN and share it with other suitable applications installed on the same device.

[0285] The ASM-centric approach can be implemented using the same or similar technologies as those described above. The difference is that it is the ASM, not the authenticator, that remembers and shares the PIN. Therefore, any FIDO authenticator that supports client PINs can be used, as long as it is possible to interface with an ASM that uses a client PIN-specific API.

[0286] Embodiments of the present invention may include various steps as described 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 a specific hardware component containing hard-wired logic for performing these steps, or by any combination of programmed computer components and custom hardware components.

[0287] The elements of the present invention can also be provided as a machine-readable medium for storing machine-executable program code. Machine-readable media may include, but are not limited to, floppy disks, optical disks, CD-ROMs and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic cards or optical cards, or other types of media / machine-readable media suitable for storing electronic program code.

[0288] Throughout the foregoing description, numerous specific details have been set forth for illustrative purposes in order to provide a thorough understanding of the invention. However, those skilled in the art will readily recognize that the invention can be practiced without some of these specific details. For example, those skilled in the art will readily recognize that the functional modules and methods described herein can be implemented as software, hardware, or any combination thereof. Furthermore, while some embodiments of the invention have been described herein within the context of a mobile computing environment, the fundamental principles of the invention are not limited to specific mobile computing implementations. In some embodiments, virtually any type of client or peer-to-peer data processing device can be used, including, for example, desktop computers or workstations. Therefore, the scope and spirit of the invention should be determined in accordance with the appended claims.

[0289] Embodiments of the present invention may include various steps as described 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 a specific hardware component containing hard-wired logic for performing these steps, or by any combination of programmed computer components and custom hardware components.

Claims

1. A device for verifier endorsement, the device comprising: a first instance of a verifier, the first instance being associated with a first application, the first instance allowing a user of the first application to authenticate to a first relying party; a hardware secure key store, the secure key store being accessible by the first instance of the verifier, the secure key store securely storing authentication data related to the first application; a first synchronization handler associated with the first application, the first synchronization handler sharing at least a portion of the authentication data with a second instance of the verifier, the second instance of the verifier being associated with a second application to be executed on the device, wherein sharing the portion of the authentication data comprises providing initial user authentication reference data to the second instance of the verifier; and a second synchronization handler associated with the second application, the second synchronization handler transmitting an endorsement request to the first synchronization handler, the endorsement request including an authentication public key, an attestation object generated by the second synchronization handler, and an encryption public key of an encryption public / private key pair; wherein in response to a positive verification of the endorsement request, the first synchronization handler transmits an endorsement response to the second synchronization handler, the endorsement response including at least a portion of the attestation object and the initial user authentication reference data encrypted using the encryption public key; and wherein the second instance of the verifier receives the endorsement response from the second synchronization handler and retrieves the initial user authentication reference data from the endorsement response.

2. The device of claim 1, wherein the initial user authentication reference data includes at least one of a personal identification number (PIN), a password, a pattern, and a biometric template.

3. The device of claim 1, wherein the at least a portion of the authentication data includes a first key associated with the first instance of the verifier.

4. The device of claim 1, wherein the first synchronization handler and the second synchronization handler are to exchange messages to share updated user authentication reference data.

5. The device of claim 1, wherein the endorsement response includes a session token.

6. The device of claim 1, wherein the endorsement request and / or the endorsement response includes a signature generated on some object including the authentication public key.

7. The device of claim 1, wherein the first synchronization handler is to perform encryption of the at least a portion of the authentication data.

8. The device of claim 1, wherein the second synchronization handler is to transmit the at least a portion of the authentication data received from the first synchronization handler to a backend service to establish an authentication session with the backend service.

9. A method for verifier endorsement, the method comprising: installing, on a client device, a first instance of a verifier associated with a first application to allow a user of the first application to authenticate to a first relying party, the first instance of the verifier securely storing authentication data related to the first application; sharing, via a first synchronization handler associated with the first application and a second synchronization handler associated with a second application to be executed on the client device, at least a portion of the authentication data including initial user verification reference data with a second instance of the verifier, the second instance of the verifier being associated with the second application; transmitting, from the second synchronization handler to the first synchronization handler, a validation request including a validation public key, an attestation object generated by the second synchronization handler, and an encryption public key of an encryption public / private key pair; transmitting, from the first synchronization handler to the second synchronization handler, a validation response including at least a portion of the attestation object and the initial user verification reference data encrypted using the encryption public key in response to a positive verification of the validation request; and retrieving, by the second instance of the verifier, the initial user verification reference data from the validation response using an encryption private key of the encryption public / private key pair.

10. The method of claim 9, wherein the initial user verification reference data includes at least one of a personal identification number (PIN), a password, a pattern, and a biometric template.

11. The method of claim 9, wherein the at least a portion of the authentication data includes a first key associated with the first instance of the verifier.

12. The method of claim 9, wherein the first synchronization handler and the second synchronization handler are to exchange messages to share updated user verification reference data.

13. The method of claim 9, wherein the validation response includes a session token.

14. The method of claim 9, wherein the validation request and / or the validation response includes a signature generated on some object including the validation public key.

15. The method of claim 9, wherein the first synchronization handler is to perform encryption of the at least a portion of the authentication data.

16. A machine-readable medium having stored thereon program code, which, when executed by one or more computing devices, causes the one or more computing devices to perform operations of: installing, on a client device, a first instance of a verifier associated with a first application to allow a user of the first application to authenticate to a first relying party, the first instance of the verifier securely storing authentication data related to the first application; sharing, with a second instance of the verifier, at least a portion of the authentication data including initial user verification reference data via a first synchronization handler associated with the first application and a second synchronization handler associated with a second application to be executed on the client device, the second instance of the verifier being associated with the second application; transmitting, from the second synchronization handler to the first synchronization handler, a validation request including a validation public key, a proof object generated by the second synchronization handler, and an encryption public key of an encryption public / private key pair; transmitting, from the first synchronization handler to the second synchronization handler, a validation response including at least a portion of the proof object and the initial user verification reference data encrypted using the encryption public key in response to a positive verification of the validation request; and retrieving, by the second instance of the verifier, the initial user verification reference data from the validation response.

17. The machine-readable medium of claim 16, wherein the initial user verification reference data includes at least one of a personal identification number (PIN), a password, a pattern, and a biometric template.

18. The machine-readable medium of claim 16, wherein the at least a portion of the authentication data includes a first key associated with the first instance of the verifier. ​

Images