Device binding using encryption keys

Abstract

A method is disclosed. The method includes receiving a first attestation message from a user device storing a private key of a public-private key pair, the first attestation message including a first attestation packet, the public key, a user device identifier of the user device, and a credential. The method also includes binding the credential to the user device identifier and transmitting the first attestation packet to a token service computer. The token service computer previously bound a first token from a first token requestor interacting with the user device to the user device identifier. The method includes receiving a second attestation message including a second attestation packet from a second token requestor interacting with the user device, verifying the second attestation packet using the public key, and transmitting verification data to the second token requestor. The second token requestor transmits the verification data to the token service computer.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2025 / 027583, international application date of May 2, 2025, Chinese national phase application number 202580002235.0, entitled "Device Binding Using Encryption Key".

[0002] Cross-references to related applications

[0003] This application is a PCT application claiming priority to U.S. Provisional Application No. 63 / 642,585, filed May 3, 2024, which is incorporated herein by reference in its entirety. Background Technology

[0004] Token requesters can request a token associated with their credentials from a token service computer. However, current protocols can contain numerous authentication processes. For example, each token provision process may require an escalating authentication process, where the token service computer requires additional authentication of the user associated with the credentials. For instance, if a user is associated with three different token requesters (e.g., an online streaming platform, a digital wallet, and a resource provider), then three different escalating authentication processes might be required. These authentication steps can unnecessarily consume system resources and time, leading to system inefficiency.

[0005] The implementation scheme disclosed herein addresses these and other issues individually and collectively. Summary of the Invention

[0006] One embodiment includes a method comprising: receiving a first proof message from a user device storing a private key in a public-private key pair, the first proof message including a first proof data packet, a public key in the public-private key pair, a user device identifier of the user device, and a credential; binding the credential to the user device identifier; transmitting the first proof data packet to a token service computer, wherein the token service computer has previously bound a first token from a first token requester interacting with the user device to the user device identifier; receiving a second proof message including a second proof data packet from a second token requester interacting with the user device; verifying the second proof data packet using a public key; and transmitting the verification data to a second token requester, the second token requester transmitting the verification data to the token service computer, wherein the token service computer binds a second token associated with the second token requester to the user device identifier.

[0007] Another embodiment includes a server computer comprising: a processor; and a non-transitory computer-readable medium including code that, when executed by the processor, causes the processor to perform a method comprising: receiving a first authentication message from a user device storing a private key in a public-private key pair, the first authentication message including a first authentication data packet, a public key, a user device identifier of the user device, and credentials; binding the credentials to the user device identifier; transmitting the first authentication data packet to a token service computer, wherein the token service computer has previously bound a first token from a first token requester interacting with the user device to the user device identifier; receiving a second authentication message including a second authentication data packet from a second token requester interacting with the user device; verifying the second authentication data packet using a public key; and transmitting the verification data to a second token requester, the second token requester transmitting the verification data to the token service computer, wherein the token service computer binds a second token associated with the second token requester to the user device identifier.

[0008] Another embodiment includes a method comprising: receiving, by a token service computer, a first device binding request message from a first token requester computer, the first device binding request message including a user device identifier of a user device and a first token, wherein the first token is associated with credentials; initiating progressive authentication of a user device by the token service computer via an authorized entity computer associated with the credentials; receiving an authentication response message by the token service computer; storing the user device identifier and the first token by the token service computer; receiving, by the token service computer, a registration message from a server computer, the registration message including a registration data packet, the user device identifier of the user device, and credentials; receiving, by the token service computer, a second device binding request message from a second token requester, the second device binding request message including verification data, the user device identifier, and the second token by the token service computer; determining, by the token service computer, that the second token is associated with credentials; determining, by the token service computer, that credentials are associated with the user device identifier; and storing, by the token service computer, the second token and the user device identifier without initiating subsequent progressive authentication of the user via an authorized entity computer.

[0009] Another embodiment of the present invention includes a token service computer, the token service computer including a processor and a computer-readable medium coupled to the processor. The computer-readable medium includes code executable by the processor to perform a method. The method includes: receiving a first device binding request message from a first token requester computer, the first device binding request message including a user device identifier of a user device and a first token, wherein the first token is associated with credentials; initiating progressive authentication of a user of the user device via an authorized entity computer associated with the credentials; receiving an authentication response message; storing the user device identifier and the first token by the token service computer; receiving a registration message from a server computer, the registration message including a registration data packet, a user device identifier of the user device, and credentials; receiving a second device binding request message from a second token requester, the second device binding request message including verification data, a user device identifier, and a second token; determining that the second token is associated with credentials; determining that the credentials are associated with the user device identifier; and storing the second token and the user device identifier by the token service computer without initiating subsequent progressive authentication of the user via an authorized entity computer.

[0010] These and other implementation schemes are described in further detail below. Attached Figure Description

[0011] Figure 1 A system and process flow for initial device binding of a first token associated with a first token requester, according to an embodiment, are shown.

[0012] Figure 2 The system and process flow according to the embodiments for registering with a server computer and generating key pairs are illustrated.

[0013] Figure 3 This demonstrates a system and subsequent device binding process involving a second token associated with a second token requester, according to an embodiment.

[0014] Figure 4 This illustrates the interaction between a user operating a user device and a second token requester using a second token, according to an embodiment.

[0015] Figure 5 A block diagram illustrating an exemplary user device according to an embodiment.

[0016] Figure 6 A block diagram illustrating an exemplary server computer according to an embodiment.

[0017] Figure 7 A block diagram illustrating an exemplary token service computer according to an embodiment. Detailed Implementation

[0018] the term

[0019] Before discussing the embodiments of this disclosure, some terms may be described in further detail.

[0020] An "authorized entity" can be the entity requesting authorization. Examples of authorized entities include publishers, government agencies, document repositories, access administrators, etc. An authorized entity can operate the authorized entity's computer.

[0021] "Issuer" can refer to a commercial entity (such as a bank) that issues and optionally maintains user accounts. An issuer may also issue payment credentials that can be stored on a user's device to a consumer.

[0022] "Processor" can refer to any suitable one or more data computing devices. A processor can include one or more microprocessors that work together to perform a desired function. A processor can include a CPU, which includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor, such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processors; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0023] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory can include non-transient computer-readable media storing instructions executable by a processor to implement the desired method. Examples of memory can include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0024] "User" can include an individual. In some embodiments, a user can be associated with one or more user devices.

[0025] A “user device” can be a device operated by a user. Examples of user devices include mobile phones or devices, smartphones, cards, personal digital assistants (PDAs), laptops, desktop computers, server computers, thin client devices, tablet PCs, etc. Furthermore, a user device can be any type of wearable technology device, such as a watch, headphones, glasses, etc. A user device can include one or more processors capable of processing user input. A user device can also include one or more input sensors for receiving user input. Examples of input sensors include accelerometers, cameras, microphones, etc. User input obtained by input sensors can come from a variety of data input types, including but not limited to audio data, visual data, or biometric data. A user device can include any electronic device that can be operated by a user, and said electronic device can also provide remote communication capabilities to a network. Examples of remote communication capabilities include using mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, 5G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to networks such as the Internet or private networks.

[0026] A "resource provider" can be an entity that provides resources such as goods, services, information, and / or access to a location (e.g., a parking space, a transit point, etc.). Examples of resource providers include businesses, government agencies, and secure data providers. A resource provider may operate one or more access devices.

[0027] "Resource provider computer" can be a computer operated by a resource provider. An example of a resource provider computer can be an access device.

[0028] A "credential" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential can be a string of numbers, letters, or any other suitable characters that can be presented or contained in any object or document that can serve as authentication.

[0029] A "value certificate" can be information associated with value. Examples of value certificates include payment vouchers, coupon identifiers, and information required to obtain promotional offers.

[0030] A "payment credential" may include any suitable information associated with an account (e.g., the payment account and / or payment device associated with the account). This information may be account-related or derived from account-related information. Examples of account information may include bank account number, PAN (primary account number or "account number"), username, expiry date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, etc. CVV2 is generally understood to be a static verification value associated with a payment device. CVV2 values ​​are typically visible to the user (e.g., a consumer), while CVV and dCVV values ​​are typically embedded in memory or authorization request messages and are not easily known to the user (although they are known to the issuer and payment processor). A payment credential may be any information identifying a payment account or associated with a payment account. A payment credential can be provided to make payments from a payment account. A payment credential may also include a username, expiry date, gift card number or code, and any other suitable information.

[0031] A "token" can be an alternative value for a credential. A token can be a string of numbers, letters, or any other suitable characters. Instances of tokens include access tokens, such as payment tokens, and data that can be used to access a secure system or location.

[0032] A "token requester" can be an application, device, or system configured to perform actions associated with a token. For example, a token requester may perform processes related to registering with a network token system, requesting token generation, token activation, token deactivation, token exchange, other token usage period management, and / or any other token-related processes. The token requester may interface with the network token system through any suitable communication network and / or protocol (e.g., using HTTPS, Simple Object Access Protocol (SOAP), and / or Extensible Markup Language (XML) interfaces, using secure communication channels such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS). In some embodiments, the token requester may be an application provider that provides a software application for using a token to a user device. For example, the application provider may be a third-party wallet provider offering a digital wallet application, or an issuer, acquirer, merchant, and / or payment processing network operator providing payment requests to a user device. The token requester may also be an original equipment manufacturer (OEM), a communications network operator (e.g., a mobile network operator), etc. In some embodiments, the token requester may request tokens for multiple domains and / or channels.

[0033] Tokenization is the process of replacing data with alternative data. For example, a payment account identifier (e.g., a master account number (PAN)) can be tokenized by replacing the master account identifier with a substitute number (e.g., a token) that can be associated with the payment account identifier. Additionally, tokenization can be applied to any other information that can be replaced with a substitute value (i.e., a token). Tokenization improves the efficiency and security of transactions.

[0034] A "password" can include encrypted information. For example, a password can be a set of text encrypted with an encryption key.

[0035] An "authorization request message" can be a message requesting permission to interact. For example, an authorization request message may include an electronic message sent to a payment processing network and / or an issuer associated with a payment credential to request authorization for a transaction. According to some embodiments, the authorization request message may conform to ISO 8583, a standard for systems for exchanging information about electronic transactions associated with payments made by a consumer using a payment device or payment account. The authorization request message may include a payment credential, such as a PAN or master account, or a payment token. The authorization request message may also include additional data elements corresponding to "identification information," including, for example only, a service code, CVV (card verification value), dCVV (dynamic card verification value), expiry date, etc. The authorization request message may also include "transaction information," such as the transaction amount, merchant identifier, merchant location, and any other information associated with the current transaction, as well as any other information that may be used to determine whether to identify and / or authorize the transaction.

[0036] An "authorization response message" can be an electronic message reply to an authorization request message. In some embodiments, the authorization response message may be generated by the issuing financial institution or a payment processing network. For example only, the authorization response message may include one or more of the following status indicators: Approval - the transaction is approved; Rejection - the transaction is not approved; or Call Center - further information is pending, and the merchant must call the toll-free authorization number. The authorization response message may also include an authorization code, which may be a code returned by the issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via the payment processing network), indicating that the transaction has been approved. The code can serve as evidence of authorization. As described above, in some embodiments, the payment processing network may generate or forward authorization response messages to the merchant.

[0037] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers operating as a single unit. In one example, a server computer can be a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers. A server computer can be a cloud computer.

[0038] A "key" can be a piece of information used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms the original data into an alternative representation, or a decryption algorithm that transforms encrypted information back into the original data. Examples of cryptographic algorithms can include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), etc.

[0039] A "public key" can include an encryption key that can be openly and publicly shared. A public key can be configured such that any information encrypted with the public key can only be decrypted using the private key associated with the public key (i.e., a public-private key pair).

[0040] A "private key" can include any encryption key that can be protected and secure. The private key can be securely stored at the entity's location and can be used to decrypt any information encrypted with the associated public key in a public-private key pair associated with the private key.

[0041] A "public-private key pair" can refer to a pair of associated cryptographic keys generated by an entity. The public key can be used for public functions, such as encrypting messages to be sent to the entity, or for verifying digital signatures made by the entity. The private key, on the other hand, can be used for private functions, such as decrypting received messages or applying digital signatures. In some embodiments, the public key may be authorized by a subject called a Certificate Authority (CA), which stores the public key in a database and distributes it to any other entity that requests it. The private key may typically be kept in a secure storage medium and is generally known only to the entity in question. The public and private keys can be in any suitable format, including formats based on Rivest-Shamir-Adleman (RSA) or Elliptic Curve Cryptography (ECC).

[0042] "Fast Identification Online (FIDO) Authentication" is a set of open technical specifications that define user authentication mechanisms that reduce reliance on passwords.

[0043] An "authenticator" is something that authenticates an entity. An authenticator can be a standalone authentication device or authentication software on a user device.

[0044] A FIDO Authenticator is an authentication entity that meets the requirements of the FIDO Alliance and possesses relevant metadata. The FIDO Authenticator is responsible for user authentication and maintains the cryptographic materials required for authentication by dependent parties.

[0045] A "Platform Authenticator" is an authenticator integrated with a user device and capable of capturing authentication factors. Platform Authenticators are referred to as internal authenticators and are used as part of the FIDO2 authentication standard of the FIDO Alliance. Platform Authenticators include features embedded in the device as well as biometric scanning, although in some cases, biometrics may not be required. Main devices utilizing platform authenticators, such as laptops or smartphones, contain necessary components of a Trusted Platform Module (TPM), such as the Secure Enclave in the Apple example, along with a fingerprint or facial scanner. When a user actively or passively authenticates, a request is made to match encrypted information on the TPM, and access to the same device can be granted to the user.

[0046] An "Application Programming Interface" or "API" can include software that specifies how components of a system should interact. An API can include a set of routines, protocols, and tools on which software applications can be built. APIs can be used on network-based systems, operating systems, database systems, computer hardware, or software libraries, and may contain specifications for routines, data structures, object classes, variables, and / or remote calls.

[0047] A “user device identifier” may contain a series of characters used to identify or refer to a user device. A user device identifier may be associated with a specific user device. A user device identifier may contain alphanumeric characters that refer to the user device. Instances of user identifiers may include telephone numbers, IP addresses, IMEI numbers, random numbers associated with a user device, or derivatives thereof (e.g., hashes).

[0048] "Interaction" can refer to mutual interaction, effect, or influence. For example, an interaction can be an exchange or transaction between two or more parties.

[0049] Many tokenization methods use cloud tokens for interaction, where a token requester exchanges credentials for the token. For example, the token requester might be a service provider, storing credentials (e.g., a master account) in a database, and tokens can be batch-to-batch tokenized using a token service computer. Once a token is generated, the token requester can use the token instead of the credentials in the authorization request message. Because the user associated with the credentials doesn't exist to authenticate themselves as the account owner when the token is provided, the user may need to authenticate themselves each time the token is used. Therefore, each time the token requester uses the token instead of the credentials in a transaction, the authorizing entity for the transaction may still need to authenticate the user associated with the credentials. Implementations can eliminate this step, thereby reducing friction in the interaction process, while still allowing the token requester to continue with the batch tokenization method.

[0050] In addition, to reduce the number of redundant authentication requests, users can specify a "trusted" user device. This specification initiates a device binding process, where the token requester can request the token service computer to bind an existing token to the user device.

[0051] However, users may still need to provide consent and authentication for each device-bound token. Tokens often change between different token requesters. For example, the first token associated with one token requester may be different from the second token associated with another token requester. Therefore, users may need to provide consent and authenticate multiple times for multiple tokens.

[0052] Embodiments of this disclosure relate to a method for processing interactions using a device binding token and a key pair. When a device binding token is issued, the embodiments bind credentials to a user device. The embodiments also subsequently register the user of the user device associated with the credential in an authentication system using an encryption key pair. The authentication system may store the private key from the encryption key pair in the user device and the public key in a server computer. When a user registers in the authentication system, an authorizing entity may verify that the user is the owner of credentials for, for example, a primary account (PAN). After the authorizing entity verifies the user's ownership, the server computer may store the public key and map the user device identifier associated with the user device to credentials associated with the account. In subsequent interactions with a second token requester during a second device binding process, the user device signs a data packet with its private key instead of requesting the authorizing entity to re-authenticate the user. The server computer may use the public key to verify that the user was previously authenticated as the owner of the credentials.

[0053] Figure 1 A system and device binding method according to an embodiment is shown. Figure 1 The user device 102, the first token requester computer 104, the server computer 106, the token service computer 108, and the authorizing entity computer 110, which are operated by the user, demonstrate operational communication with each other.

[0054] User device 102 can be used to authenticate users. For example, user device 102 may include a platform authenticator for authenticating users. User device 102 can initiate interactions (e.g., transactions) with the first token requester computer 104. For example, a user operating user device 102 can use a website hosted by the first token requester computer 104 to initiate checkout or manage subscriptions to obtain one or more items.

[0055] The first token requester computer 104 may comprise any suitable computing device operated by a token requester (e.g., a merchant). The first token requester computer 104 may request a token from a token service computer 108 and use the token in interactions. For example, the first token requester computer 104 may request a token associated with a user device 102. In some embodiments, the first token requester computer 104 may comprise one or more server computers capable of hosting one or more websites associated with the token requester (e.g., a merchant). In some embodiments, the first token requester computer 104 may also be configured to generate authorization request messages for user interaction and route the messages to an authorization entity computer 110 for processing.

[0056] Authorizing entity computer 110 may be a server computer operated by an authorizing entity. Authorizing entity computer 110 may represent user authorization requests on behalf of user device 102. In some embodiments, authorizing entity computer 110 may issue and manage credentials on behalf of the user operating user device 102. For example, an instance of an authorizing entity may be an issuer that maintains accounts for users of user device 102. Accounts may have account numbers, which are instances of credentials.

[0057] Server computer 106 may be a computer capable of performing public-key-private key pair authentication (e.g., Fast Identifier Online (FIDO) authentication). Server computer 106 may maintain a mapping between credentials (e.g., PAN) and device identifiers. In some embodiments, server computer 106 may be a FIDO server computer.

[0058] The token service computer 108 may contain a computer that maintains tokens for credentials. The token service computer 108 may associate tokens with user devices to bind tokens to user devices. The token service computer 108 may also generate and provide tokens. The token service computer 108 may also store a mapping of tokens to credentials.

[0059] See the executable. Figure 1 The described method binds an existing token (e.g., a first token) associated with a first token requester computer 104 to a user device 102. The device binding process enables convenient interaction between the user device 102 and the first token requester computer 104.

[0060] The first token requester computer 104 may store a first token for credentials associated with a user on user device 102. The first token can be used to prevent the exposure of underlying credentials. Prior to device binding, whenever the first token is used for interaction, ascending authentication can be used to verify the association between the user and the credentials / token. For example, each time the first token is used, the authorizing entity may send a one-time password to the user via user device 102 for verification.

[0061] Figure 1 Each entity in the network can communicate through any suitable communication channel or communication network. A suitable communication network can be any and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an Operational Mission as a node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., employing, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.); etc.

[0062] To simplify the explanation, Figure 1 A specific number of components are shown. However, it should be understood that embodiments of this disclosure may include more than one of each component. Furthermore, some systems according to embodiments of this disclosure may include more than one of each component. Figure 1 The components shown may have fewer or more components.

[0063] During device binding, user device 102 is designated as a "trusted" device and can act as an authentication factor. The user device identifier can be stored in association with the first token, allowing the presence of user device 102 to be recognized in future interactions. Conveniently, after device binding, escalating authentication is not required each time the first token is used.

[0064] Prior to step S102, the first token requester computer 104 may store a first token associated with the user of user device 102. For example, the first token requester computer 104 may use the token service computer 108 to tokenize credentials (e.g., PAN) associated with the user. The first token can be used to replace credentials during interactions. Additionally, prior to step S102, a unique user device identifier may be assigned to user device 102. The user device identifier may be pre-existing (e.g., phone number, IMEI number, etc.) or may be provided by the token service computer 108 upon request from the first token requester computer 104 or another token requester.

[0065] In step S102, user device 102 may initiate a device binding process. For example, user device 102 may access a website provided by the first token requester computer 104 and prompt the user to agree to the device binding process. The user may agree, and user device 102 may notify the first token requester computer 104. For example, the user may designate user device 102 as a "trusted device" so that future interactions initiated by user device 102 do not require escalating authentication.

[0066] At step S104, after receiving consent for device binding from user device 102, the first token requester computer 104 may request the token service computer 108 to bind the first token to user device 102 (e.g., a first device binding request message). For example, the first token requester computer 104 may transmit the user device identifier associated with user device 102 and the first token from the device binding request message to the token service computer 108. The first token may be an existing token previously provided before step S102. The first token may be associated with the first token requester computer 104 and may replace the credentials associated with the user of user device 102.

[0067] At step S106, after receiving a device binding request including a first token and a user device identifier from a first token requester, the token service computer 108 may determine the authorized entity computer 110 based on the credentials associated with the first token. The token service computer 108 may have a mapping between credential portions (e.g., PAN or BIN of a primary account or bank identifier number) and authorized entity computer identifiers or addresses. The token service computer 108 may then transmit the device binding request to the authorized entity computer 110 that manages the account associated with the credential. The token service computer 118 may provide a token provision request message to the authorized entity computer 110 via an ISO 0100 message or via an application programming interface (API).

[0068] In step S108, after receiving the token provision request message, the authorizing entity computer 110 may request the token service computer 108 to perform or initiate ascending authentication before binding the first token to the user device 102.

[0069] In step S110, after receiving the token offering response message, the token service computer 108 may generate a retrieval verification method message and provide the retrieval verification method message to the authorization entity computer 110. The retrieval verification method message may be a request to retrieve the cardholder authentication method (CVM) associated with the credential.

[0070] In step S112, the authorizing entity computer 110 may obtain one or more authentication methods in response to the authentication method acquisition message. The authorizing entity computer 110 may then provide one or more authentication methods to the token service computer 108.

[0071] At step S114, after receiving the verification method from the authorizing entity computer 110, the token service computer 108 may provide the verification method to the first token requester computer 104 (e.g., a list in the format of verification methods).

[0072] At step S116, after receiving the verification method from the token service computer 118, the first token requester computer 104 may present the verification method to the user device 102 (e.g., via a webpage).

[0073] At step S118, the user of user device 102 can select one of one or more authentication methods. User device 102 can provide the selected authentication method to the first token requester computer 104. For example, the user can select an authentication method such as a one-time password (OTP) authentication method.

[0074] At step S120, after receiving the selected verification method, the first token requester computer 104 may provide the selected verification method from the Identity and Verification (ID&V) message to the token service computer 108. The token service computer 108 may also present an input field that allows the user device 102 to enter authentication information (e.g., a password).

[0075] In step S122, after receiving the selected verification method, the token service computer 108 may initiate the selected verification method. For example, the token service computer 108 may generate a password according to a one-time password verification method. After generating the password, the token service computer 108 may send it to the authorized entity computer 110.

[0076] At step S124, the authorizing entity computer 112 may directly provide the password to the user device 102. Alternatively, the authorizing entity computer 110 may provide the password to the user device 102 via a communication channel separate from the communication channel formed between the user device 102 and the first token requester computer 104. For example, the authorizing entity computer 110 may provide the password to the user device 102 via Short Message Service (SMS), email, or other communication channels.

[0077] At step S126, after receiving the password, user device 102 may provide authentication information (e.g., the password) to first token requester computer 104 to authenticate the user. For example, the user may enter the password into a password input field on a webpage provided by the first token requester computer 104.

[0078] At step S128, after receiving authentication information (e.g., password), the first token requester computer 104 may provide the authentication information to the token service computer 108 in an authentication response message.

[0079] The token service computer 108 can verify the received authentication information (e.g., a password). The token service computer 108 can compare the received password with the generated password. If the received password and the generated password do not match, the token service computer 108 can terminate the process. If the received password and the generated password match, the token service computer 108 can proceed to step S130.

[0080] At step S130, after verifying the authentication information, the token service computer 108 may bind the first token to the user device 102. For example, the token service computer 108 may store the user device identifier (and the credentials associated with the first token) associated with the first token in a database.

[0081] In step S132, after binding the first token to the user device 102, the token service computer 108 may generate a device binding success message and provide it to the authorizing entity computer 110. The token service computer 108 may determine, obtain, or generate a transaction identifier (transaction ID) for identifying the transaction. Optionally, the token service computer 108 may record the time of performing authentication and initial device binding. The token service computer 108 may include the transaction ID and time in the device binding success message sent to the authorizing entity computer 110. The authorizing entity computer 110 may store the authentication transaction ID and time received from the token service computer 108.

[0082] In step S134, the token service computer 108 may provide a device binding success message to the server computer 106. In step S136, the token service computer 108 may notify the first token requester computer 104 that the device binding is successful. In step S138, the first token requester computer 104 may notify the user device 102 that the device binding is successful.

[0083] Figure 2 A system and method for registering with a server computer and generating key pairs are shown according to embodiments.

[0084] refer to Figure 2The described registration process can be accessed via... Figure 1 The initial device binding occurs within the same or different sessions. Similar to... Figure 1 , Figure 2 The user device 102, the first token requester computer 104, the server computer 106, the token service computer 108, and the authorizing entity computer 110 are shown communicating with each other.

[0085] User device 102 may perform a registration process similar to the FIDO registration process. During the registration process, user device 102 may generate a proof blob (e.g., in a metadata blob file) and a public key. In some embodiments, the public key may be a FIDO public key.

[0086] In step S202, the first token requester computer 104 may display a user interface on the user device 102 requiring the user to register with the server computer 106. The user can confirm via the user interface.

[0087] In step S204, after receiving user confirmation, the first token requester computer 104 may initiate a user authentication process with the server computer 106.

[0088] In step S206, the server computer 106 may transmit a message to the user device 102 that initiates the registration interface. The server computer 106 may also generate a verification request packet and transmit it to the user device 102. The verification request packet may include a challenge, a server computer identifier, an authenticator selection, verification settings, user authentication settings, user presence settings, etc. The challenge may be a random number generated to prevent replay attacks. The server computer identifier may be a unique identifier that identifies the server computer domain (e.g., a valid domain string, application address, etc.).

[0089] The authenticator selection may be specific authenticator information that the server computer 106 may need to verify. For example, the server computer 106 may need a specific type of platform authenticator (e.g., a biometric scanner for capturing user biometrics). In this embodiment, the server computer 106 may need a platform authenticator that is a FIDO authenticator.

[0090] The proof settings allow the first token requester computer 104, server computer 106, or other entities to specify whether proof data is required. Proof data may include an authenticator proof globally unique ID (AAGUID) indicating the authenticator of the FIDO device. The same AAGUID can be assigned to the same security key for the product type and firmware.

[0091] In some embodiments, server computer 106 may set the authentication setting to "direct". This setting specifies the authentication required for FIDO certification; for example, user device 102 must be an authenticated FIDO device with an AAGUID.

[0092] User authentication settings and user presence settings allow server computer 106 to instruct user device 102 whether user authentication and user presence are required. In an embodiment, user authentication settings and user presence settings may be set by server computer 106 to indicate that user authentication and user presence are required.

[0093] At step S208, upon receiving an authenticator verification request packet, user device 102 may facilitate user authentication. For example, user device 102 may authenticate the user (e.g., by using a PIN provided by the user, user biometric information, etc.). In addition to user authentication, user device 102 may determine the presence of the user during authentication, which may involve affirmative user gestures (e.g., touching user device 102) or may be achieved by an image sensor (e.g., a biometric scanner) included in user device 102 to capture a real-time image of the user (e.g., user biometrics).

[0094] In some embodiments, user device 102 may generate new encryption key pairs, such as public-private key pairs specific to server computer 106. User device 102 may store the assertion private key and server computer identifier in a database within user device 102 (e.g., in the secure element of user device 102).

[0095] User device 102 may generate a credential identifier (ID) containing information about a public key, a private key, and / or a server computer identifier. For example, the credential ID may contain information about the location of the new private key and the server computer identifier in the database of user device 102.

[0096] User device 102 can generate a first authentication data packet that may contain client data and authentication objects. The user authentication flag and user presence flag can be set to "true," indicating successful user authentication (e.g., PIN or biometric authentication) and user presence. For example, the value of "true" can be 1, either 0 or 1.

[0097] For example, client data may contain one or more of a challenge, a server computer identifier, or a hash and extension of a server computer identifier. Authenticator data may contain a user authentication flag, a user presence flag, an AAGUID, the public key in a public-private key pair, a credential ID, etc. In some embodiments, authenticator data may also contain an encryption algorithm identifier for the encryption algorithm used to generate the public-private key pair.

[0098] In some embodiments, the proof object may include a proof format, authenticator data, and a proof statement. In some embodiments, the proof format may be used to determine how to verify the proof statement. For example, the proof format may be "packed", "fido-u2f", "none", "android-key", "android-safetynet", "tpm", "apple", etc.

[0099] The structure of a proof statement and the procedure for verifying it can depend on the type of proof format defined in the proof object. In some embodiments, a proof statement may include a proof signature and a proof certificate.

[0100] In some embodiments, user device 102 may use a private key and a first concatenated value to generate a proof signature. For example, the first concatenated value may be signed using a proof signature to generate the proof signature. The first concatenated value may be a concatenation of hashes of authenticator data and client data hashes, determined by applying a hash algorithm to the authenticator data and client data hashes. Alternatively, the first concatenated value may be a concatenation of hashes of authenticator data and client data, determined by applying a hash algorithm to the authenticator data and client data. The hash algorithm may be SHA-256 or any other suitable hash algorithm.

[0101] At step S210, user device 102 may send a first proof message, including a first proof data packet, a public key, a user device identifier, and credentials, to server computer 106 as a response to receiving the proof request packet. Credentials may be referenced... Figure 1 The same credential as the credential under the first token described.

[0102] In step S212, upon receiving the first proof message from the user device 102, the server computer 106 can verify the first proof data packet, which includes client data and the proof object.

[0103] As described in detail below, in some embodiments, server computer 106 may verify the server computer identifier, challenges in client data, proof signatures, user verification flags, user presence flags, AAGUIDs, and proof certificates. If any verification fails, the registration process may be aborted.

[0104] For example, server computer 106 can verify that the server computer identifier in the client data is the same as the source server computer identifier (e.g., URL) of server computer 106 to verify that there is no phishing or man-in-the-middle attack between user device 102 and server computer 106.

[0105] Server computer 106 can verify that the challenge in the client data matches the challenge sent in the authenticator proof request packet, and confirm that the user verification flag and user presence flag are set to "true".

[0106] Server computer 106 can use a public key to verify the proof signature of the proof object. For example, server computer 106 can use the proof signature and the proof public key to determine a first concatenated value. Server computer 106 can generate a second concatenated value. If a client data hash is received, the second concatenated value can be a concatenation of the hashes of the received authenticator data and the received client data hash, determined by applying a hash algorithm to the received authenticator data and the received client data hash. Alternatively, if unhashable client data is received, the second concatenated value is a concatenation of the hashes of the received client data and the authenticator data, determined by applying a hash algorithm to the received client data and the authenticator data. If the first concatenated value matches the second concatenated value, the proof signature is considered verified.

[0107] In some embodiments, server computer 106 can verify a received authentication certificate used to verify the authenticity of a signature. The authentication certificate can be verified using a received AAGUID. The AAGUID can be used to look up metadata statements in a service such as a metadata service (MDS) to verify the authenticator's certification and prove the authenticity of the device model. The metadata statement may contain a root certificate and metadata about user device 102, such as device security and biometrics. The root certificate can be used to check the authenticity of the authentication certificate. In some embodiments, additional metadata containing security and biometrics can be checked by server computer 106 to determine the security level of user device 102.

[0108] The proof completes several security checks. For example, if an attacker intercepts the authenticator's proof response packet, the attacker will be unable to exchange a new public key with their own public key because the proof signature will not match. As another example, knowing the origin of user device 102 can provide the relying party with information about the security of the encryption key, the security of the biometric verification process, etc.

[0109] In step S214, upon successful verification, the server computer 106 may store the user device identifier along with the credential in memory, thereby binding the user device 102 to the credential. The server computer 106 may also store the credential ID, AAGUID, and public key in memory. The server computer 106 may also store, in correspondence with the public key, an encryption algorithm identifier for the encryption algorithm used to generate the public-private key pair.

[0110] At step S216, server computer 106 may transmit a registration message, including a registration authentication data packet (e.g., a registration blob or a registration payload), to token service computer 108. The registration authentication data packet may contain one or more of the following: authentication time, server computer identifier, public key, AAGUID, a flag for this transaction, a user presence flag, a user verification flag, an algorithm identifier for the encryption algorithm used to generate the public-private key pair, and a transaction ID.

[0111] At step S218, the token service computer 108 can verify the information provided in the registration authentication data packet, and if the verification is successful, store the registration blob in memory.

[0112] As described in detail below, in some embodiments, the token service computer 108 may validate (e.g., verify) the AAGUID (e.g., by looking up the AAGUID using an MDS), the time period between the registration time and the authentication time (i.e., the time of previous authentication), and the transaction ID. For example, the transaction ID may include the time of previous authentication.

[0113] For example, the token service computer 108 can retrieve previously stored transaction IDs (e.g., from...). Figure 1 Step S132) verifies the transaction ID in the registered blob by comparing the transaction ID in the registered blob with the previously stored transaction ID. For example, in order for successful verification (e.g., validation), a match must be determined.

[0114] The token service computer 108 can verify that the time interval between the registration time (e.g., the registration time) and the authentication time is less than a threshold time interval value. For example, the threshold time interval value can be set to 2 minutes, 5 minutes, 10 minutes, etc. For instance, if the difference between the previously authenticated time and the registration time recorded in the registration blob is greater than the threshold time interval value, then the token service computer 108 does not verify the time interval. Otherwise, the token service computer 108 verifies the time interval.

[0115] After successful verification of the AAGUID, time period, and transaction ID (if available), the token service computer 108 may store the registered blob in memory associated with the token service computer 108. For example, the cryptographic algorithm identifier used to generate the assertion public-private key pair may be stored corresponding to the assertion public key.

[0116] At step S220, the token service computer 108 may send a registration authentication data packet with an indication that the user has successfully registered to the authorized entity computer 110.

[0117] In some embodiments, the authorizing entity computer 110 may store the registration blob in memory associated with the authorizing entity computer 110. Upon receiving the registration blob, the authorizing entity computer 110 may retrieve the previously stored transaction ID (from...). Figure 1 Step S132) and verify the transaction using the transaction ID from the registered blob.

[0118] In step S222, the token service computer 108 may notify the first token requester computer 104 that registration was successful. In step S224, the first token requester computer 104 may notify the user device 102 that registration was successful.

[0119] In subsequent interactions that may require a password, the user may alternatively provide biometrics to user device 102. Each time the user submits biometrics, the user device can sign a verification packet with its private key and send the signed verification packet for verification by server computer 106 using its public key. Successful verification of the verification packet results in positive authentication by server computer 106.

[0120] Figure 3 This demonstrates the process of binding the second token to the system and device of the second token requester after the registration process is completed. Figure 3 The process shown can be Figure 1 and Figure 2 It occurs at any point after the process is completed. Similar to... Figure 1 and Figure 2 , Figure 3 It may involve user device 102, server computer 106, token service computer 108 and authorized entity computer 110. Figure 3 It also includes a second token requester computer 304.

[0121] The second token requester computer 304 can be used for reference. Figure 1 The first token requester computer 104 is a separate entity. The second token requester computer 304 may store a second token, which is a credential associated with the user of user device 102. The second token and reference... Figure 1 The first token described can all be associated with the same credential.

[0122] exist Figure 3 During the device binding process, the user of user device 102 does not need to authenticate with the authorized entity computer 110 to bind the second token to user device 102, because Figure 1 Authentication has been performed during the initial device binding process.

[0123] In step S302, user device 102 may initiate a device binding process. For example, user device 102 may access a website provided by the second token requester computer 304 and prompt the user to agree to the device binding process. The user may agree, and user device 102 may notify the second token requester computer 304. For example, to facilitate login, the user may designate user device 102 as a "trusted device".

[0124] In step S304, after receiving consent for device binding from user device 102, the second token requester computer 304 may transmit instructions to perform the verification process on user device 102 to server computer 106.

[0125] At step S306, server computer 106 may generate a second assertion request packet to include credential parameters (e.g., server computer identifier, credential ID, and challenge). The assertion request packet may specify that user authentication and / or user presence are required. Credential parameters have been described above.

[0126] At step S308, the server computer 106 may send a second proof request data packet containing the server computer identifier, credential ID, and challenge to the user device 102.

[0127] At step S310, upon receiving the second proof request data packet, the user device 102 may execute an assertion process and generate an assertion response data set as a response to the assertion request data packet.

[0128] User device 102 can compare the server computer identifier with its source (e.g., URL) to verify that there is no phishing or man-in-the-middle attack between user device 102 and server computer 106. If the server computer identifier does not match its source (e.g., URL), the process is aborted.

[0129] User device 102 can use the credential ID to retrieve the assertion private key and server computer identifier stored in the database. The server computer identifier received from server computer 106 is then compared with the server computer identifier stored in user device 102 to verify that the correct assertion private key has been retrieved.

[0130] User device 102 may generate client data that includes any one of challenge, server computer identifier, extension, and hash algorithms. In some embodiments, user device 102 may generate a client data hash.

[0131] User device 102 can then perform user presence and user authentication, similar to the above reference. Figure 2The process is described below. After successful user authentication and user presence check, the user presence flag and user authentication flag can be set to "true". User device 102 can also generate a signature counter, which increments each time user device 102 authenticates a user. The signature counter can be used by server computer 106 to detect cloned authenticators. User device 102 can then generate authenticator data containing AAGUID, user presence flag, user authentication flag, extension, and signature counter.

[0132] User device 102 can use an assertion private key on the first concatenated value to generate an assertion signature. For example, the first concatenated value can be signed with the assertion private key to generate an assertion signature. The first concatenated value can be a concatenation of hashes of authenticator data and client data obtained by applying a hash algorithm to authenticator data and client data. Alternatively, the first concatenated value can be a concatenation of hashes of authenticator data and client data obtained by applying a hash algorithm to hash authenticator data and client data. The hash algorithm can be SHA-256 or any other suitable hash algorithm.

[0133] User device 102 may generate a second proof message including a second proof data packet. The second proof data packet may include a server computer identifier, authenticator data, client data, credential ID, and assertion signature.

[0134] At step S312, user device 102 may send a second proof message, including a second proof data packet, to server computer 106 as a response to a second proof data request packet.

[0135] In step S314, the server computer 106 can verify the second proof data packet.

[0136] As described in detail below, in some embodiments, server computer 106 can verify the server computer identifier, challenges, assertion signatures, user authentication flags, user presence flags, credential IDs, and AAGUIDs in the client data. If any verification fails, the process aborts.

[0137] Server computer 106 can verify that the challenge in the client data matches the generated challenge, the user authentication flag and the user presence flag are set to "true", the AAGUID of the authenticator data matches the AAGUID used during registration, and assert that the credential ID of the data response packet matches the stored credential ID.

[0138] Server computer 106 can also validate (e.g., verify) the assertion signature. For example, server computer 106 can use the assertion public key and the assertion signature to determine a first concatenation value. In some embodiments, server computer 106 can apply a predefined algorithm to the assertion public key and the assertion signature to determine the first concatenation value. In some embodiments, the predefined algorithm may be a cryptographic algorithm used to generate the assertion public-private key pair. Server computer 106 can further generate a second concatenation value. In some embodiments, the second concatenation value may be a concatenation of hashes of received authenticator data and client data. If the received client data is hashed, then the second concatenation value may be a concatenation of hashes of received authenticator data and received client data. The hash algorithm may be SHA-256 or any other suitable hash algorithm. If the first concatenation value matches the second concatenation value, then the assertion signature is validated (e.g., verified).

[0139] In some embodiments, server computer 106 can ensure (e.g., determine) that all verifications are successful; otherwise, assertion / authentication can be aborted.

[0140] At step S316, in response to successful validation and verification, server computer 106 may generate verification data. Verification data may include authentication data packets, such as authentication payloads or authentication blobs. For example, the authentication data packet transmitted to token service computer 108 contains the requester's authentication method and authentication data.

[0141] The requester's authentication method can be represented by a string corresponding to, for example, the authentication method of 3DS.

[0142] The authentication data includes authentication time, server computer identifier, authenticator ID (e.g., AAGUID), transaction flag, user presence flag, user verification flag, assertion signature, client data, and authenticator data. Each of the authentication time, server computer identifier, AAGUID, transaction flag, user presence flag, user verification flag, assertion signature, client data, and authenticator data can be set in the corresponding data field of the authentication packet. For example, each of the authentication time, server computer identifier, AAGUID, transaction flag, assertion signature, client data, and authenticator data can be represented by a string. Each of the user presence flag and user verification flag can be a Boolean bit flag.

[0143] The preceding text describes the authentication time, server computer identifier, AAGUID, user presence flag, user verification flag, assertion signature, client data, and authenticator data. If the server computer identifier and AAGUID match those previously used, then processing continues. The user presence flag and user verification flag can be set to "true," for example, 1. Flags used for this transaction can be set to true, indicating that the same authenticator is used for authentication with the resource provider's current session.

[0144] At step S318, the server computer 106 may transmit the verification data, including the authentication data packet, to the second token requester computer 304.

[0145] In step S320, upon receiving verification data, the second token requester computer 304 may generate a second device binding request message and transmit it to the token service computer 108. The second device binding request message may include the user device identifier of user device 102, a second token, and verification data including authentication data packets. The second token may be an existing token previously provided before step S302. The second token may be associated with the second token requester computer 304 and replace the credentials associated with the user of user device 102.

[0146] At step S322, the token service computer 108 may verify the information in the authentication data packet. In some embodiments, if the verification / validation described below is successful, the token service computer 108 may store the authentication data packet in a database, for example, corresponding to the user device ID.

[0147] As described in detail below, in some embodiments, the token service computer 108 may validate (e.g., verify) the server computer identifier, AAGUID, assertion label, user presence flag, and user verification flag.

[0148] For example, token service computer 108 can use AAGUID to check whether the authentication device used for the assertion (e.g., user device 102) is the same as that used during registration. Token service computer 108 can check whether the user presence flag and user verification flag are set to true. Token service computer 108 can check whether the server computer identifier matches the resource provider. Token service computer 108 can verify the assertion signature using the assertion public key, similar to operation S222.

[0149] In some embodiments, the token service computer 108 may ensure (e.g., determine) that all authentications are successful; otherwise, the device binding process may be aborted.

[0150] The token service computer 108 can identify the initial device binding process performed on the user device 102. For example, the token service computer 108 can determine that the user device identifier is stored in association with a first token, and that the first token is associated with the same credentials as the second token. The token service computer 108 can determine that the authorizing entity computer 110 has performed escalating authentication on the credentials and the user device 102. The token service computer 108 can determine that the authorizing entity computer 110 does not need to re-authenticate the combination of credentials and user device 102 for the second device binding.

[0151] At step S324, after successful verification at step S322, the token service computer 108 can bind the second token to the user device 102. For example, the token service computer 108 can store the user device identifier associated with the second token (and the credentials associated with the first and second tokens).

[0152] In step S326, the token service computer 108 may generate a device binding notification for the second token and provide the device binding notification to the authorized entity computer 110.

[0153] In step S328, the token service computer 108 may generate a device binding notification for the second token and provide the device binding notification to the second token requester computer 304.

[0154] In step S330, the second token requester computer 304 may notify the user device 102 that the device binding is complete.

[0155] Figure 4 This demonstrates the interactive process following the initial device binding and registration processes. Figure 4 Available Figure 1 , Figure 2 and Figure 3 This will be done after the process is completed. (Reference) Figure 4 The described interactions may involve Figure 3 The same entity and second token described herein. In some embodiments, the interaction may involve [the entity / token] from [the entity / token]. Figure 1 The first token requester computer 104 and the first token.

[0156] In step S402, user device 102 may initiate an interaction with the second token requester computer 304. For example, when a user wishes to pay for goods or services, the user of user device 102 may interact with the second token requester computer 304.

[0157] At step S404, the server computer 106 may receive instructions from the second token requester computer 304 to perform a verification process associated with the interaction.

[0158] Steps S406 to S418 can be similar to Figure 3 S306 to S318, and their descriptions will not be repeated here.

[0159] In step S420, after receiving authentication data from server computer 106, second token requester computer 304 may request interaction data from token service computer 108. Second token requester computer 304 may transmit authentication data packets to token service computer 108. For example, second token requester computer 304 may transmit an API request for interaction data including authentication data packets to server computer 106.

[0160] At step S422, after receiving the authentication data packet from the second token requester computer 304, the token service computer 108 can use the authentication data packet to generate a password or message (e.g., ECI 05 / CAVV) for interaction to indicate successful authentication. For example, the password could be an authentication password. The token service computer 108 can then transmit an API response including the password to the second token requester computer 304.

[0161] At step S424, the second token requester computer 304 may send an authorization request message to the token service computer 108 via a transmission computer (e.g., an acquiring computer). The token service computer 108 may be located in a payment processing network and may handle transaction authorization, clearing, and settlement transactions. The authorization request message may contain an interaction quantity, a second token, and a password. The password in the authorization request message informs the token service computer 108 about the user's previous successful authentication. For example, in some implementations, the password in the authorization request message may include the authentication password generated in step S430.

[0162] At step S426, the token service computer 108 can modify the authorization request message by including credentials. The token service computer 108 can detoxify the second token to obtain credentials and replace the second token with the credentials. The token service computer 108 can transmit the modified authorization request message including the credentials to the authorization entity computer 110.

[0163] At step S428, upon receiving the modified authorization request message, the authorization entity computer 110 may determine whether to authorize the transaction. In addition to determining whether the user has sufficient funds in their account, the authorization entity computer 110 may use data from the authentication data packet in the authorization request message to determine whether the current transaction is authorized. The authentication data is detailed and provides a guarantee of transaction reliability to the authorization entity (e.g., the issuer).

[0164] In step S430, the authorizing entity computer 110 may send an authorization response message containing an authorization request message, indicating acceptance or rejection, to the token service computer 108. If the authorizing entity computer 110 authorizes the authorization request message, the interaction is successful. If the authorizing entity computer 110 rejects the authorization request message, the interaction terminates.

[0165] At step S432, the token service computer 108 may modify the authorization response message to include the second token and send the modified authorization response message to the second token requester computer 304.

[0166] At a later date or time, the clearing and settlement process may take place between a transmission computer (not shown) operated by the acquirer associated with the second token requester computer 304, the token service computer 108, and the authorizing entity computer 110.

[0167] Figure 5 A block diagram of a user device 500 according to an embodiment is shown. The user device 500 may correspond to the user device 102 described above and may include device hardware 504 coupled to system memory 502, such as a computer-readable storage medium.

[0168] Device hardware 504 may include a processor 506, a short-range antenna 514, a long-range antenna 516, an input element 510, a user interface 508, and an output element 512 (which may be a portion of the user interface 508). Examples of input elements may include a microphone, a keypad, a touchscreen, a sensor, etc. Examples of output elements may include a speaker, a display screen, and a haptic device.

[0169] The long-range antenna 516 may include one or more RF transceivers and / or connectors that can be used by the user equipment 500 to communicate with other devices and / or connect to external networks. The user interface 508 may include any combination of input and output elements to allow a user to interact with the user equipment 500 and invoke the functions of the user equipment. The short-range antenna 509 may be configured to communicate with external entities via short-range communication media (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long-range antenna 516 may be configured for over-the-air communication with remote base stations and remote cellular or data networks.

[0170] System memory 502 may be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage media or combinations thereof. System memory 502 may be in the form of a memory element that stores data (e.g., resource provider applications) (or may be included in said memory element), and may be in any suitable form (e.g., microSD chip, SIM card, or other type of memory element).

[0171] System memory 502 may also store an interactive application 502A, an authentication module 502B, a cryptography module 508C, and credentials, keys, and tokens 502D. Interactive application 502A may contain instructions or code for initiating and interacting with an external device, such as a first token requester's computer. It may contain code executable by processor 506 for generating and transmitting a device binding request message and receiving a response message. The transaction initiation module may also include code executable by processor 506 for establishing a local connection or otherwise interacting with an external device (e.g., a carrier computer). Authentication module 502B may contain code executable by processor 506 for authenticating a user. This can be done using a user secret (e.g., a password), user biometrics, a public-private key, etc. System memory 502 may also store credentials, keys, and tokens 502C or references.

[0172] Cryptographic module 508C may include code that enables processor 506 to provide cryptographic functions. Cryptographic module 508C enables user device 500 to sign data using a private key. For example, cryptographic module 508C may encrypt or hash data elements to generate a proof data packet. For example, cryptographic module 508C may use encryption algorithms (e.g., DES, AES, TDES / TDEA, or similar) and / or hash functions such as SHA or similar to implement and perform encryption operations.

[0173] Figure 6 A block diagram of a server computer according to an embodiment is shown. Server computer 600 may include a computer capable of performing FIDO (Fast Identification Online) authentication. Server computer 600 may maintain the association between a master account (PAN) and the device, and manage account information. Server computer 600 may use public-private key cryptography to register and authenticate users.

[0174] Server computer 600 may include processor 604, network interface 606, and computer-readable medium 608 coupled to memory 602. Computer-readable medium 608 may include registration module 608A, communication module 608B, and authentication module 608C.

[0175] Memory 602 can be used to store data and code. Memory 602 may be coupled internally or externally to processor 604 (e.g., a cloud-based data storage device) and may include any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash memory, or any other suitable memory device. For example, memory 602 may store credentials, tokens, resource provider identifiers, account information, etc.

[0176] Computer-readable medium 608 may include code executable by processor 604 to perform a method comprising: receiving a first authentication message from a user device storing a private key in a public-private key pair, the first authentication message including a first authentication data packet, a public key, a user device identifier of the user device, and credentials; binding the credentials to the user device identifier; transmitting the first authentication data packet to a token service computer, wherein the token service computer has previously bound a first token from a first token requester interacting with the user device to the user device identifier; receiving a second authentication message including a second authentication data packet from a second token requester interacting with the user device; verifying the second authentication data packet using the public key; and transmitting the verification data to a second token requester, the second token requester transmitting the verification data to the token service computer, wherein the token service computer binds a second token associated with the second token requester to the user device identifier.

[0177] Registration module 608A may include code or software executable by processor 604 for registering users with server computer 600. For example, a user may provide registration data to registration module 608A containing a user device identifier, credentials, and a public key. Registration module 608A may, in conjunction with processor 604, store the registration data in a profile database.

[0178] The communication module 608B may include code that enables the processor 204 to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities. When the server computer 600 receives an electronic message via the network interface 206, the electronic message may be passed to the communication module 608B. The communication module 608B may, in conjunction with the processor 604, identify and parse relevant data based on a specific messaging protocol used in the system. The communication module 608B may then, in conjunction with the processor 604, transmit any received information to an appropriate module within the server computer 600 (e.g., via a data bus, etc.). The communication module 608B may also receive information from one or more modules in the server computer 600 and generate electronic messages in an appropriate data format in accordance with a transmission protocol, such that the messages may be sent to one or more entities. The electronic messages may then be passed to the network interface 606 for transmission.

[0179] The verification module 608C may include code that causes the processor 604 to perform a verification process to authenticate the user. For example, the verification module 608C may work with the processor 604 to compare received data with stored data to verify that the received data is reliable. The verification module 608C may work with the processor 604 to verify the data using a public key.

[0180] Network interface 606 may include an interface that allows server computer 600 to communicate with external computers. Network interface 606 enables server computer 600 to transfer data to and from another device. Some examples of network interface 606 may include a modem, a physical network interface (such as an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a PCMCIA slot and card, etc. Wireless protocols enabled by network interface 606 may include Wi-Fi. TM Data transmitted via network interface 606 may be in the form of signals, which may be electrical, electromagnetic, optical, or any other signal that can be received by an external communication interface (collectively, "electronic signals" or "electronic messages"). These electronic messages, which may include data or instructions, may be provided between network interface 606 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

[0181] Figure 7 A block diagram of a token service computer 700 according to an embodiment is shown. The exemplary token service computer 700 may include a processor 704. The processor 704 may be coupled to a memory 702, a network interface 706, and a computer-readable medium 708. The computer-readable medium 708 may include a tokenization module 708A, a communication module 708B, an interaction processing module 708C, and a device binding module 708D.

[0182] Memory 702 can be used to store data and code. For example, memory 702 can store tokens, keys, token maps, etc. Memory 702 can be coupled internally or externally to processor 704 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash memory, or any other suitable memory device.

[0183] Computer-readable medium 708 may include code executable by processor 704 for performing a method comprising: receiving a first device binding request message from a first token requester computer, the first device binding request message including a user device identifier of a user device and a first token, wherein the first token is associated with credentials; initiating progressive authentication of a user of the user device via an authorized entity computer associated with the credentials; receiving an authentication response message; storing the user device identifier and the first token; receiving a registration message from a server computer, the registration message including a registration data packet, the user device identifier of the user device, and credentials; receiving a second device binding request message from a second token requester, the second device binding request message including verification data, the user device identifier, and the second token; determining that the second token is associated with credentials; determining that the credentials are associated with the user device identifier; and storing the second token and the user device identifier without initiating subsequent progressive authentication of the user via an authorized entity computer.

[0184] The tokenization module 708A may include executable code for generating or determining a token for credentials. The communication module 708B may be similar to the communication module 608B. The interaction processing module 708C may be programmed to handle interactions. The device binding module 708D may include executable code for binding a token to a user device.

[0185] Network interface 706 may include an interface that allows token service computer 700 to communicate with external computers. Network interface 706 enables token service computer 700 to transfer data to and from another device. Some examples of network interface 706 may include a modem, a physical network interface (such as an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a PCMCIA slot and card, etc. Wireless protocols enabled by network interface 706 may include Wi-Fi. TM Data transmitted via network interface 706 may be in the form of signals, which may be electrical signals, electromagnetic signals, optical signals, or any other signals that can be received by an external communication interface (collectively, "electronic signals" or "electronic messages"). These electronic messages, which may include data or instructions, may be provided between network interface 706 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

[0186] The embodiments disclosed herein offer several technical advantages. The embodiments can identify devices through multiple interactive identifiers and devices associated with different tokens for different token requesters. The embodiments provide a secure method for interactive processing using tokenization and keys without sacrificing user convenience. Users can complete device binding and registration processes to reduce the need for subsequent escalating authentication of authorized entities. Compared to conventional protocols, the embodiments reduce the number of over-authentications, thereby saving time and computing resources.

[0187] Other technical advantages involve using tokens instead of credentials in embodiments of the invention. Tokens protect sensitive credentials (e.g., accounts) from hackers and man-in-the-middle attacks because the sensitive credentials are not exposed during transactions. Therefore, tokens provide data security for sensitive credentials.

[0188] Any software component or function described in this application may be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing techniques such as conventional or object-oriented methods. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as optical discs (CDs) or digital versatile optical discs (DVDs), flash memory, and the like. The computer-readable medium may be any combination of such storage or transmission means.

[0189] Such programs can also be encoded and transmitted using carrier signals suitable for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, a computer-readable medium according to an embodiment of the invention can be created using data signals encoded with such a program. Computer-readable media encoded with program code can be packaged with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing a user with any of the results mentioned herein.

[0190] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art after reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the above description, but rather by reference to the pending claims together with their full scope or equivalents.

[0191] Without departing from the scope of the invention, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0192] As used herein, unless explicitly indicated otherwise, the terms “a,” “an,” or “the” are intended to mean “at least one / a kind.”

Claims

1. A method comprising: A user device storing the private key in a public-private key pair provides a first authentication message to a server computer. The first authentication message includes a first authentication data packet, the public key in the public-private key pair, the user device identifier of the user device, and a credential, wherein the server computer is programmed to bind the credential to the user device identifier and subsequently send an authentication data packet to a token service computer. The user device interacts with the second token requester; After interacting with the second token requester, the user device provides a second proof message to the server computer, the second proof message including a second proof data packet, wherein the server computer is further programmed to verify the second proof data packet using the public key and to send verification data to the token service computer via the second token requester, wherein the token service computer is further programmed to bind a second token associated with the second token requester to the user device identifier.

2. The method of claim 1, wherein the second token is associated with the credential.

3. The method of claim 1, wherein the second proof data packet includes data signed by the private key, wherein the server computer verifies the second proof data packet by verifying the data signed by the private key using the public key.

4. The method of claim 3, wherein the data signed by the private key is signed after the user device receives the user's biometrics.

5. The method of claim 3, wherein the user device is a mobile phone.

6. The method of claim 1, wherein the token service computer is further programmed to bind the second token, the user device identifier, and the credential.

7. The method according to claim 1, further comprising: The user device receives a notification from the token service computer that the second token has been bound to the user device identifier.

8. The method of claim 1, wherein the first authentication data packet includes a challenge and a user authentication flag.

9. The method of claim 1, wherein the second token requester computer is programmed to obtain the second proof message from the user device after the user device receives the user's biometrics and signs the data in the second proof data packet using the private key.

10. The method of claim 1, wherein the user device is a mobile phone.

11. A user equipment, comprising: processor; and A computer-readable medium comprising code executable by the processor to perform the method according to any one of the preceding claims.

12. A method comprising: The second token requester computer sends an instruction to the server computer to perform the authentication process associated with the user device; The second token requester computer receives the authentication data packet from the server computer; The authentication data packet is sent from the second token requester computer to the token service computer; as well as The second token requester computer receives a device binding notification from the token service computer, which binds the second token to the user device identifier of the user device, and the second token is used by the second token requester computer for transactions.

13. The method of claim 12, wherein the authentication data packet includes an authentication method and authentication data.

14. The method of claim 13, wherein the authentication data includes authentication time, the identifier of the server computer, and user verification flag.

15. The method of claim 13, wherein the authentication data includes an assertion signature generated by the user device and authenticator data.

16. The method of claim 12, further comprising: The second token requester computer sends a prompt to the user device to solicit the user's consent to participate in the device binding process; The user's consent is received by the computer of the second token requester.

17. The method of claim 12, wherein the server computer is programmed to generate the authentication packet after sending a challenge to the user device, receiving a signed assertion from the user device, and verifying the signed assertion using a public key corresponding to the private key used to create the signed assertion.

18. The method of claim 12, wherein the server computer is programmed to bind the credentials associated with the second token to the user device identifier.

19. The method of claim 12, wherein the token service computer is programmed to look up the first token, the second token, and the user device identifier of the first token requester.

20. A second token requester computer, comprising: processor; and A computer-readable medium comprising code executable by the processor to perform the method according to any one of claims 12 to 19.

21. A method comprising: The server computer receives a first authentication message from the user device storing the private key in the public-private key pair. The first authentication message includes a first authentication data packet, the public key in the public-private key pair, the user device identifier of the user device, and credentials. The server computer binds the credential to the user device identifier; The server computer transmits the registration authentication data packet to the token service computer, wherein the token service computer previously bound a first token from a first token requester interacting with the user device to the user device identifier. After interacting with the second token requester, the server computer receives a second proof message, including a second proof data packet, from the user device; The server computer uses the public key to verify the second proof data packet; and The server computer transmits the verification data to the second token requester, who then transmits the verification data to the token service computer, wherein the token service computer binds the second token associated with the second token requester to the user device identifier.

22. The method of claim 21, wherein the first token and the second token are associated with the credential.

23. The method of claim 21, wherein the second proof data packet comprises data signed by the private key, wherein verifying the second proof data packet comprises verifying the data signed by the private key using the public key.

24. The method of claim 23, wherein the data signed by the private key is signed after the user device receives the user's biometrics.

25. The method of claim 23, further comprising, before binding the credential to the user device identifier, having the server computer verify the first authentication data packet.

26. The method of claim 21, wherein the token service computer binds the second token, the user device identifier, and the credential.

27. The method of claim 21, wherein the token service computer binds the second token to the user device identifier after determining that the second token is associated with the credential and the credential is associated with the first token bound to the user device identifier.

28. The method of claim 21, wherein the token service computer binds the first token to the user device identifier after performing progressive authentication of the user device via an authorized entity computer, and wherein the token service computer binds the second token to the user device identifier without the authorized entity computer performing subsequent progressive authentication of the user.

29. The method of claim 21, wherein after the user device receives the user's biometrics and signs the data in the second proof data packet using the private key, the second token requester obtains the second proof message from the user device.

30. The method according to claim 21, wherein, The user device is a mobile phone.

31. A server computer, comprising: processor; as well as A non-transient computer-readable medium comprising code that, when executed by the processor, causes the processor to perform a method comprising: A first authentication message is received from a user device storing the private key in the public-private key pair. The first authentication message includes a first authentication data packet, the public key in the public-private key pair, the user device identifier of the user device, and credentials. Bind the credential to the user device identifier; The registration authentication data packet is transmitted to the token service computer, wherein the token service computer previously bound a first token from a first token requester interacting with the user device to the user device identifier. After interacting with the second token requester, a second proof message including a second proof data packet is received from the user device; Use the public key to verify the second proof data packet; and The verification data is transmitted to the second token requester, who then transmits the verification data to the token service computer, wherein the token service computer binds the second token associated with the second token requester to the user device identifier.

32. The server computer of claim 31, wherein the first token and the second token are associated with the credential.

33. The server computer of claim 31, wherein the second proof data packet includes data signed by the private key, and wherein verifying the second proof data packet includes verifying the data signed by the private key using the public key.

34. The server computer of claim 31, wherein the first token has the same format as the credential.

35. The server computer of claim 31, wherein binding the credential to the user device identifier includes storing the credential in association with the user device identifier.

Images