Secure Remote Token Issuance Using Online Authentication

Abstract

This document describes a system and technology for providing authentication. The technology includes registering user authentication data, such as biometric data, through a communication device. The authentication data is linked to an account or service provider and is used to verify the identity of the user when accessing the account. The communication device can obtain a public key / private key pair, where the public key can be stored on a secure remote server. When the user attempts to access the account or service provider, the user can provide the authentication data to authenticate the user to the communication device. Thereafter, the communication device can sign an authentication indicator using the private key and send the authentication indicator to the secure remote server. After verifying the signature using the public key, the secure remote server can grant the user's access, for example, by issuing a token.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit and priority of U.S. Provisional Patent Application No. 62 / 639,652, filed on Mar. 7, 2018, entitled "SECURE REMOTE TOKEN RELEASE WITH ONLINE AUTHENTICATION", which is hereby incorporated by reference in its entirety. BACKGROUND OF THE INVENTION

[0003] As the number of online or computer - accessible accounts that a user can have continues to grow, usernames and passwords as a form of authentication are no longer sufficient to protect user accounts. For example, remembering usernames and passwords for many sites can be challenging, and setting the same password for multiple accounts may increase the likelihood that if one account is compromised, all accounts are at risk. Password managers may be inconvenient, and storing all user passwords in one place may be risky. Passwords can also be easily spoofed or captured by malware, and data breaches at service providers may result in passwords being spread on the dark web.

[0004] In addition, while an authorizing entity can determine whether to authorize a transaction based on account information, such authorizing entities cannot authenticate the user of the user device. Thus, an authorizing entity typically must rely on another entity, such as a resource provider, to perform user authentication. Not all resource providers can provide the same level of authentication quality, which can lead to data security issues.

[0005] Another problem to be solved in the field of data security is the problem of transmitting sensitive credentials (e.g., social security numbers, account numbers, etc.) over a data network. The transmission of such data may be subject to man - in - the - middle attacks.

[0006] Various embodiments of the present invention, alone and in combination, solve these and other problems. SUMMARY OF THE INVENTION

[0007] A system and technique for authenticating a user while ensuring that the authentication is performed by a legitimate device are described herein. The authentication technique may include registering authentication data of a user, such as biometric data, through a communication device. The authentication data may be linked to an account or a service provider and used to verify the identity of the user when accessing the account. The communication device may be associated with a public - key / private - key pair, where the public key is stored on a secure remote server. When a user attempts to access an account or a service provider, the user may provide authentication data to authenticate the user to the communication device. Thereafter, the communication device may sign an authentication indicator using the private key and send the authentication indicator to the secure remote server. After verifying the signature using the public key, the secure remote server may grant the user access, for example, by issuing a token.

[0008] One embodiment of the present disclosure relates to a method performed by a secure remote transaction server, the method comprising: receiving a request to register an account from a client device; verifying whether the client device has the right to access the account; associatively storing at least the public key of a cryptographic key pair with the account, wherein at least the private key of the cryptographic key pair is stored on the client device in association with the account; and generating a token associated with the account, the token being associatively stored with the account. In some embodiments, the method may further comprise: receiving a request to complete a transaction associated with the account from an access device, the request including a signed authentication indicator; verifying the authentication indicator using the public key associatively stored with the account; and after verifying the authentication indicator, providing the token to the access device.

[0009] Another embodiment of the present disclosure relates to a secure remote transaction server, which includes a processor and a memory, the memory including instructions that, when executed by the processor, cause the secure remote transaction server to: at least receive a request to register an account from a client device; verify that the client device has the right to access the account; associatively store at least the public key of a cryptographic key pair with the account, wherein at least the private key of the cryptographic key pair is stored on the client device in association with the account; and generate a token associated with the account, the token being associatively stored with the account. In some embodiments, the instructions may further cause the secure remote transaction server to: receive a request to complete a transaction associated with the account from an access device, the request including a signed authentication indicator; verify the authentication indicator using the public key associatively stored with the account; and after verifying the authentication indicator, provide the token to the access device.

[0010] Yet another embodiment of the present disclosure relates to a method performed by a communication device, the method comprising: receiving a request to register authentication data for an account associated with a service provider; prompting the user to provide the authentication data; receiving the authentication data from the user; registering the authentication data on the communication device; obtaining the private key of a cryptographic key pair; associating the private key with the account and the authentication data, wherein a secure remote server links the public key of the cryptographic key pair to a token associated with the account.

[0011] In some embodiments, the method described above may further include: receiving a request to access an account; prompting a user to provide authentication data; receiving the authentication data from the user; comparing the received authentication data with the registered authentication data; determining that the received authentication data matches the registered authentication data; generating an authentication indicator indicating the match; signing the authentication indicator using a private key; and sending the signed authentication indicator in the access request to a secure remote server, wherein in response to verifying the signed authentication indicator using a public key, the secure remote server issues a token to a service provider to grant the user access to the account.

[0012] Other details regarding embodiments of the present invention can be found in the detailed description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 Depicts several components that may be involved in a system for implementing at least some embodiments of the present disclosure;

[0014] Figure 2 Depicts an example system architecture that may be implemented according to an embodiment of the present disclosure to provide secure remote transactions;

[0015] Figure 3 Illustrates a registration process of an authentication system according to some embodiments;

[0016] Figure 4 Depicts an example provisioning process according to some embodiments, whereby a user can manually add their account to be processed by the SRT platform and a private key and / or token can be provisioned to a client device;

[0017] Figure 5 Illustrates a process of authenticating a user to a service provider using an authentication system according to some embodiments;

[0018] Figure 6 Illustrates a process of authenticating a user to a service provider using multiple devices according to some embodiments;

[0019] Figure 7 Illustrates a flowchart of a process of performing authentication of a user according to at least some embodiments;

[0020] Figure 8 Illustrates a flowchart of a process of registering authentication data according to at least some embodiments; and

[0021] Figure 9 Illustrates a flowchart of a process of accessing an account according to some embodiments. DETAILED DESCRIPTION

[0022] Describes enhanced authentication techniques that do not rely on the use of passwords. In some embodiments, a two-factor authentication scheme may be used, where biometrics are used to authenticate a user on a communication device, and public key / private key cryptography is used to authenticate the communication device to a remote server to grant the user access to accounts, services, and / or functions associated with a service provider. In some embodiments, the service provider may be a token service provider, and the two-factor authentication scheme is used by the system to issue a token from the remote server. The token can then be used, for example, to conduct a transaction using the user account. The various embodiments described herein may be implemented on a Secure Remote Transaction (SRT) platform. An example of the SRT platform on which the above embodiments may be implemented is described in more detail in U.S. Patent Application No. 15 / 927754, filed on Mar. 21, 2018, which is hereby incorporated by reference in its entirety.

[0023] Before discussing specific embodiments of the invention, some terms may be described in detail.

[0024] An "access device" may be any suitable device for communicating with a merchant computer or a transaction processing network and for interacting with a transaction device (e.g., a payment device), a user computing device, and / or a user client device. The access device may generally be located at any suitable location, such as at the location of the merchant. The access device may be in any suitable form. Some examples of the access device include a POS device, a cellular phone, a PDA, a personal computer (PC), a tablet, a handheld dedicated reader, a set-top box, an electronic cash register (ECR), an automated teller machine (ATM), a virtual cash register (VCR), an information kiosk, a security system, an access system, a website, etc. The access device may use any suitable contact or non-contact operation mode to send or receive data from or associated with a portable communication device. In some embodiments where the access device may include a POS terminal, any suitable POS terminal may be used and it may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or non-contact operation mode. For example, an exemplary card reader may include a radio frequency (RF) antenna for interacting with a portable communication device, an optical scanner, a barcode reader, or a magnetic stripe reader.

[0025] An "account credential" may include any suitable information associated with an account (e.g., the account and / or a portable device associated with the account). Such information may be directly related to the account or may be derived from information related to the account. Examples of account credentials may include a PAN (primary account number or "account number"), a user name, an expiration date, a CVV (card verification value), a dCVV (dynamic card verification value), a CVV2 (card verification value 2), a CVC3 card verification value, etc.

[0026] An "acquiring party" can generally be a business entity (e.g., a commercial bank) having a business relationship with a particular merchant or other entity. Some entities can perform both the issuer and acquirer functions. Some embodiments can cover such a single entity issuer - acquirer.

[0027] "Authentication" can be a process of proving or verifying certain information and / or verifying the identity of the source of the information. For example, a user can provide authentication data that is unique to the user or known only to the user to prove the user's identity. Examples of different types of authentication data can include biometrics (e.g., fingerprint, palmprint, facial recognition, iris and / or retina recognition, voice recognition, gait or other human characteristics), passwords, PINs, answers to security questions, password responses to challenges, human and / or device signatures, etc.

[0028] An "authorizing entity" can be an entity that authorizes a request. Examples of authorizing entities can be an issuer, a government agency, a document repository, an access administrator, etc. An "issuer" generally can refer to a business entity (e.g., a bank) that maintains a user account associated with a client device - e.g., an account registered in a mobile application installed on the client device. The authorizing entity can also send account parameters associated with the account to the client device. The authorizing entity can be associated with a host system that performs some or all of the functions of the issuer on behalf of the authorizing entity.

[0029] An "authorization request message" can be an electronic message that is sent to request authorization of a transaction. The authorization request message can be sent to a transaction processing network and / or the issuer of a transaction card (e.g., a payment card). According to some embodiments, the authorization request message can conform to ISO 8583, which is a standard for a system for exchanging electronic transaction information associated with transactions made by a user using a transaction device or a transaction account. The authorization request message can include information that can be used to identify the account. The authorization request message can also include additional data elements, e.g., one or more of a service code, an expiration date, etc. The authorization request message can also include transaction information, e.g., any information associated with the current transaction, such as a transaction amount, a merchant identifier, a merchant location, etc., and any other information that can be used to determine whether to identify and / or authorize the transaction. The authorization request message can also include other information, e.g., information identifying the access device that generated the authorization request message, information about the location of the access device, etc.

[0030] "Authorization response message" can be an electronic message reply to an authorization request message. The authorization response message can be generated by the issuing financial institution or the transaction processing network. By way of example only, the authorization response message can include one or more of the following status indicators: Approved - the transaction is approved; Declined - the transaction is not approved; or Call Center - for more information on a pending response, the merchant must call a toll-free authorization telephone number. The authorization response message can also include an authorization code, which can be a code returned by the credit card issuing bank to the merchant's computer in response to an authorization request message in an electronic message (either directly or through the transaction processing network) indicating an approved transaction. The code can serve as evidence of authorization. As noted above, in some embodiments, the transaction processing network can generate or forward an authorization response message to the merchant.

[0031] "Communication device" can be a device that includes one or more electronic components (e.g., integrated chips) that can communicate with another device or entity. For example, a communication device can be a computing device that includes at least one processor coupled to a memory that stores instructions or code for execution by the processor, and the communication device can include a communication interface that allows the communication device to interact with other entities. The communication device can be a portable communication device that can be transported and operated by a user and can include one or more electronic components (e.g., integrated chips). The portable communication device can provide remote communication capabilities with a network. The portable communication device can be configured to transmit data or communications to other devices and receive data or communications from other devices. The portable communication device can be in the form of a client device, such as a mobile phone (e.g., a smart phone, a cellular phone, etc.), a tablet computer, a portable media player, a personal digital assistant device (PDA), a wearable device (e.g., a watch, a health monitoring device such as a fitness tracker, etc.), an electronic reader device, etc., or in the form of a card (e.g., a smart card) or a fob, etc. Examples of portable communication devices can also include portable computing devices (e.g., a laptop computer, a netbook, a ultrabook, etc.). The portable communication device can also be in the form of a vehicle (e.g., an automobile), or integrated as part of a vehicle (e.g., the information system of a vehicle). Other examples of communication devices can include IoT devices, smart devices, and electronics, etc.

[0032] A "service provider" can be any entity that can authenticate the user of a client device. The service provider may include a client-side application (e.g., a service provider application) and a backend server (e.g., a service provider server) that can support the client-side application. In some cases, the service provider application can be executed after receiving an instruction from the service provider server to authenticate the user of the client device. The service provider application can enable the client device on which the service provider application is installed to obtain user-specific data. Then, this user-specific data can be compared with the expected user-specific data by the service provider application on the client device or by the service provider server to determine whether the obtained user-specific data matches the expected user-specific data. In some embodiments, the service provider can be an electronic wallet provider (e.g., Apple Pay). It should be noted that the service provider can be independent of the SRT platform and / or the initiator.

[0033] An "initiator" can be any entity that can facilitate communication between a resource provider and one or more SRT platforms. The initiator can operate several servers that provide at least a part of the functions described herein. In some cases, the initiator can obtain approval and / or recognition from one or more SRT platforms to operate in conjunction with those SRT platforms. A resource provider can register with the initiator to obtain access to at least a part of the processes described herein. The initiator can provide a link embedded within a checkout element for each resource provider that it has registered with. The link can initiate the processes described herein when activated by a user who wishes to transact with the resource provider, so as to facilitate the transaction between the user and the resource provider. It should be noted that the initiator can be independent of the SRT platform and / or the service provider.

[0034] A "issuer" generally can refer to a business entity (e.g., a bank) that maintains a user account associated with a portable communication device - such as an account registered in a mobile application installed on the portable communication device. The issuer can also send account parameters associated with the account to the portable communication device. The issuer can be associated with a host system that performs some or all of the functions of the issuer on behalf of the issuer.

[0035] A "key" can refer to a piece of information used in a cryptographic algorithm to transform input data into another representation. The cryptographic algorithm can be an encryption algorithm that transforms the original data into an alternative representation, or a decryption algorithm that transforms the 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.

[0036] A "merchant" generally can be an entity that participates in a transaction and can sell goods or services or provide access to goods or services.

[0037] "Real account identifier" may refer to the original account identifier associated with an account. For example, a real account identifier can be the primary account number (PAN) issued by an issuer for a card account (e.g., credit card, debit card, etc.). For example, in some embodiments, the real account identifier may include a sixteen-digit numerical value, e.g., "4147 0900 0000 1234". The first six digits of the real account identifier (e.g., "414709") may represent the actual issuer identifier (BIN) that can identify the issuer associated with the real account identifier.

[0038] The term "resource" generally refers to any asset that can be used or consumed. For example, a resource can be a computer resource (e.g., stored data or networked computer accounts), a physical resource (e.g., a tangible object or a physical location), or other electronic resources or communications between computers (e.g., a communication signal corresponding to an account used to perform a transaction). Some non-limiting examples of resources can be goods or services, physical buildings, computer accounts or files, or payment accounts. In some embodiments, a resource may refer to a financial product, such as a loan or a line of credit.

[0039] A "resource provider" can be an entity that can provide resources such as goods, services, information and / or access to such resources. Examples of resource providers include merchants, online or other electronic retailers, access devices, secure data access points, etc. A "merchant" can generally be an entity that participates in a transaction and can sell goods or services or provide access to goods or services. A "resource provider computer" can be any computing device operated by a resource provider.

[0040] A "Secure Remote Transaction (SRT) platform" can be any entity that can facilitate a transaction in the described manner. The SRT platform is capable of communicating with an initiator, a service provider, and a transaction processing network. In some embodiments, the SRT platform may include an SRT server, a token provider, and a transaction processing network. The SRT platform can be configured to perform one or more processes, including: receiving a transaction request from an initiator; identifying an account associated with the transaction; determining an appropriate service provider for the account; causing the determined service provider to authenticate a user associated with the account; generating a token to be used in the transaction; and providing the token to the initiator to complete the transaction.

[0041] A "server computer" may include a powerful computer or a computer cluster. For example, a server computer can be a mainframe, a small computer cluster, or a group of servers operating as a unit. In one example, a server computer can be a database server coupled to a web server. The server computer can be coupled to a database and can include any hardware, software, other logic, or a combination of the foregoing for servicing requests from one or more client computers. The server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to service requests from one or more client computers.

[0042] A "token" may refer to a substitute identifier for some information. For example, a transaction token can include an identifier for a transaction account, which identifier substitutes for an account identifier such as a primary account number (PAN). For example, a token can include a series of alphanumeric characters that can be used as a substitute for the original account identifier. For example, the token "49000000 0000 0001" can be used to replace the PAN "4147 09000000 1234". In some embodiments, a token can be "in a reserved format" and can have a numeric format consistent with the account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a token can be a random string. In some embodiments, a token can be used to replace a PAN to initiate, authorize, settle, or resolve a transaction. In other systems where the original credential is typically provided, a token can also be used to represent the original credential. In some embodiments, a token value can be generated such that it may not be computationally possible to recover the original PAN or other account identifier from the token value. Additionally, in some embodiments, the token format can be configured to allow an entity receiving the token to identify it as a token and to identify the entity that issued the token.

[0043] "Tokenization" may refer to the process of replacing data with substitute data. For example, an account identifier (e.g., a primary account number (PAN)) can be tokenized by replacing the account identifier with a substitute number associated with the account identifier (e.g., a token). Additionally, tokenization can be applied to other information that can be replaced with a substitute value. Tokenization can be used to improve transaction efficiency, improve transaction security, improve service transparency, or provide a method for third-party implementation.

[0044] A "token service provider" may refer to an entity that includes one or more server computers that generate, process, and maintain tokens. The token service provider may include a token library or communicate with a token library, where generated tokens are stored. Specifically, the token library may maintain a one-to-one mapping between tokens and the data represented by the tokens (e.g., real account identifiers). The token service provider may provide reports or data outputs to reporting tools regarding approved, pending, and / or rejected token requests. The token service provider may provide data outputs related to token-based transactions to reporting tools and applications and appropriately present tokens and / or the data replaced by the tokens (e.g., real account identifiers) in the report output.

[0045] A "token library" may refer to a repository that maintains an established token to PAN mapping. According to various embodiments, the token library may also maintain other attributes of the token requester, which may be determined at registration and may be used by the token SRT server to impose domain restrictions or other controls during transaction processing. The token library may be part of the token service system. In some embodiments, the token library may be provided as part of the token SRT server. Alternatively, the token library may be a remote repository accessible to the token SRT server. The token library may be protected by strong underlying physical and logical security due to the sensitive nature of the data mappings stored and managed therein.

[0046] A "transaction" may be any interaction or exchange between two or more parties. For example, a transaction may include a first entity requesting a resource from a second entity. In this example, the transaction is complete when the resource is provided to the first entity or the transaction is rejected.

[0047] A "transaction processing network" or "processing network" may refer to an electronic payment system for accepting, transmitting, or processing transactions made by a payment device for funds, goods, or services. The processing network may transfer information and funds between an authorizing entity (e.g., issuer), an acquirer, a merchant, and a payment device user.

[0048] Figure 1 Depicts several components that may be involved in a system for implementing at least some embodiments of the present disclosure; in Figure 1 , the client device 102 may communicate with several remote entities via a network connection (wireless or physical). For example, the client device 102 may be used to access a website maintained by a resource provider server 104 or an authorizing entity server 106 (e.g., via a browser application). In this example, the website may embed a checkout element that is configured to cause the client device 102 to initiate communication with an initiator server 108. The initiator server 108 may then communicate with multiple Secure Remote Transaction (SRT) platforms 110.

[0049] In some embodiments, a plurality of service provider applications 112 may be installed on the client device 102. The service provider applications may be configured to enable the client device 102 to communicate with a plurality of service provider application servers 114 to authenticate a user of the client device 102. In some embodiments, the client device 102 may store one or more cryptographic keys in its memory, associated with the service providers installed on the client device 102 and / or the client device 102 itself.

[0050] In some embodiments of the present invention, the client device 102 may be a mobile device (such as a mobile phone). The mobile device is capable of communicating with a cell tower (such as via cellular communication like GSM, LTE, 4G, etc.) and a wireless router (such as via WiFi). The mobile device may store user account credentials, such as PAN (primary account number), tokens, names, addresses, CVV, expiration dates, and any other suitable information. The mobile device may also store one or more private cryptographic keys associated with the mobile device itself or the applications installed on the mobile device. Such data may be stored securely either by hardware (such as a secure element) or software.

[0051] In some embodiments, the resource provider server 104 may be associated with an online retailer having an electronic catalog or another suitable resource provider. The resource provider server 104 may provide one or more pages of the resource provider website to a browser installed on the client device 102. In some embodiments, the website provided to the browser application may contain a portal website or a link that initiates communication with the originator server 108 when accessed using the browser application.

[0052] In some embodiments of the present invention, the authorization entity server 106 may be any computing device configured to determine whether to approve a transaction to be conducted by a specific user. The authorization entity server 106 may maintain a plurality of accounts, one or more of which are associated with a specific user. Each account may be associated with a certain amount of resources (such as a balance), and the authorization of a transaction may be based on such resources. However, although the authorization entity server 106 is capable of determining whether to authorize a user's transaction, the authorization entity server 106 may not be able to authenticate the user because it is in a remote location of the user. Therefore, the authorization entity server 106 may be configured to use the embodiments of the system described herein to authenticate the user. In some embodiments, after successfully registering a user into the system described herein, the authorization entity server 106 may generate a token associated with the user and provide the token to the SRT platform 110 to be bound to the client device 102 together with a pair of cryptographic keys.

[0053] The initiator server 108 can be any suitable computing device configured to identify a user, identify the user's accounts, receive a selection of one of those accounts, communicate the selected account to an SRT platform 110 associated with the account, and complete a transaction using the selected account. In some embodiments, the initiator server 108 can also be configured to verify signed data received from the client device 102. For example, the initiator server can use a public cryptographic key associated with the client device 102 or an application installed on the client device 102 to verify the data when the data is received from the client device 102.

[0054] In some embodiments, the system can be implemented across one or more SRT platforms 110. Each SRT platform can be associated with a transaction processing network. Each SRT platform can include some combination of an SRT server (or servers) 110(A), token data 110(B), and a processing network 110(C). Multiple accounts can be associated with a single SRT platform. For example, a user can be associated with two different accounts each associated with a different authentication entity, and both accounts can be processed using a single SRT platform. The SRT server 110(A) can be configured to identify one or more service provider applications 112 associated with an account and cause a user to be authenticated using one of those service provider applications 112. This can involve communicating an authentication request to a service provider application server 114 associated with a particular service provider application 112.

[0055] Additionally, once a user has been authenticated, the client device 102 or the SRT server 110(A) can be configured to generate a cryptographic key and / or a token to be bound (or otherwise associated) with a particular client device 102, and the cryptographic key and / or token are stored in the corresponding token data 110(B) such that data received from the client device 102 can be verified using the stored public key. When an indication that the client device 102 has been verified by the authorization entity server 106 is received, the token and the cryptographic key can be bound to the client device 102. In some embodiments, the SRT server 110(A) can pass the public key associated with the client device 102 to the initiator server 208, which can verify data received from the client device 102 and generate transaction information including a token to be used for the transaction. The mapping between the token and the transaction can be maintained by the SRT server 110(A) in its corresponding token data. In some embodiments, the SRT server 110(A) can receive several files from various authorization entities, and each file can include a mapping between an email address and various PANs. In this way, the SRT server 110(A) can maintain a mapping between user identifier information and accounts.

[0056] The service provider application 112 can be any suitable set of computer-executable instructions installed on the client device 102, which, when executed, causes the client device 102 to perform an authentication process. In some embodiments, the authentication process may involve a collection of biometric information associated with the user of the client device 102. For example, the service provider application 112 can obtain a voiceprint or fingerprint data to be used for authenticating the user. The service provider application can be associated with the hardware installed on the client device 102. Examples of the service provider application 112 can include fingerprint, retina, or voice scan applications. The hardware associated with those applications can include fingerprint, retina, or voice scan hardware, such as a fingerprint sensor, a retina sensor, or a voice sensor. Other types of service provider applications 112 can also include PIN and password service provider applications. In some embodiments, the service provider application 112 can be a wallet SRT server.

[0057] The service provider application server 114 can be any suitable computing device that provides support for the service provider application 112. In some embodiments, the service provider application server 114 can perform an authentication process on behalf of the service provider application 112. For example, the service provider application 112 can cause the client device 102 to obtain authentication data from the user of the client device 102. Once the authentication data is obtained, the authentication data can be transmitted to the service provider application server 114 corresponding to the service provider application for collecting the authentication data. Then, the authentication data can be compared by the service provider application server 114 with the recorded authentication data of the user. Once the user has been authenticated, the service provider application server 114 and / or the service provider application 112 can generate an authentication result indicating that the user has been authenticated. The client device 102 can use a private key specific to the client device 102 and stored by the client device 102 to sign the received authentication result.

[0058] For illustrative examples of at least some embodiments of the present disclosure, consider a scenario where a user wishes to register with the system described herein and conduct a transaction. In this scenario, the user may request to register with a particular authorization entity server 106. The request may be associated with a particular account maintained by the authorization entity server 106 (e.g., a credit card account maintained by a banking institution). The authorization entity server 106 may reference account data associated with the particular account to identify contact information. Once identified, the authorization entity server 106 may transmit a verification message to the user via the stored contact information. In some embodiments, the verification message may include a one-time password (OTP) or other dynamic verification data that the user may be required to enter via the client device 102 to be verified. Once verified, the authorization entity server 106 may provide an indication of the client device 102 to the SRT platform 110. A token and a cryptographic key may be generated for the client device 102 by the authorization entity server 106, the client device 102, or the SRT platform 110. Once generated, at least the private cryptographic key of the token and cryptographic key pair may be transmitted to the client device 102.

[0059] After registering the client device 102 using the illustrative scenario above, the user may access a merchant (resource provider 104) website to complete a transaction (e.g., make a purchase). In this scenario, after selecting multiple items for the transaction, the user may be presented with a checkout page of the merchant website. The checkout page may include a list of items, prices, quantities, or any other suitable transaction-related information. Additionally, the checkout page may include a checkout element that may be selected to initiate the transaction. Once the checkout element has been selected, the user may be able to select an account associated with the authorization entity server 106 to complete the transaction.

[0060] Upon receiving the selection of an account associated with the authorization entity server 106, the SRT platform 110 may cause the service provider application 112 to be executed to authenticate the user. The service provider application 112 may then perform an authentication process and, upon completion of the authentication process, may return an authentication indicator indicating whether the user has been authenticated to the client device 102. In this scenario, the client device 102 may then sign the authentication indicator by performing a cryptographic algorithm on the authentication indicator using the private cryptographic key of the cryptographic key pair. The signed authentication indicator may be provided to the SRT platform 110 via the initiator application server 108.

[0061] After verifying the authentication indicator and confirming that the user is authenticated, the SRT platform 110 may provide the token associated with the client device 102 back to the initiator application server 108. The initiator server 108 may then use the received token to complete the requested transaction.

[0062] For clarity Figure 1A specific number of components are shown. However, it should be understood that for each type of component, embodiments of the present invention may include more than one. Additionally, some embodiments of the present invention may include fewer or more components than all of the components shown in Figure 1 In addition, Figure 1 the components in may communicate via any suitable communication protocol over any suitable communication medium, including the Internet.

[0063] Figure 2 FIG. depicts an example system architecture that may be implemented in accordance with embodiments of the present disclosure to provide secure remote transactions. In Figure 2 , the SRT server 202 may communicate with a number of client devices 204 and an authorization entity server 206 via a network connection 208. The network connection 208 may include at least one transaction processing network. In some embodiments, the SRT server 202 may be an Figure 1 example SRT server 110 of.

[0064] In at least some embodiments, the SRT server 202 may include at least one memory 214 and one or more processing units (or processors) 216. The processor 216 may be implemented in hardware, computer-executable instructions, firmware, or a combination thereof, as appropriate. The computer-executable instructions or firmware embodiments of the processor 216 may include computer-executable instructions or machine-executable instructions written in any suitable programming language for performing the various functions described.

[0065] The memory 214 may store program instructions that may be loaded and executed on the processor 216, as well as data generated during the execution of these programs. Depending on the configuration and type of the SRT server 202, the memory 214 may be volatile (e.g., random access memory (RAM)) and / or non-volatile (e.g., read-only memory (ROM), flash memory, etc.). The SRT server 202 may also include additional storage devices 218, such as removable storage devices or non-removable storage devices, including but not limited to magnetic storage devices, optical disks, and / or tape storage devices. The disk drive and its associated computer-readable medium may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the SRT server 202. In some embodiments, the memory 214 may include multiple different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), or ROM.

[0066] Turning more specifically to the contents of the memory 214, the memory 214 may include an operating system and one or more applications or services for implementing the features disclosed herein. The memory includes at least one module (account binding module 220) for binding an account to a token and / or a cryptographic key. The memory 214 may also include: account data 222 that provides data stored in association with a user account; cryptographic key data 224 that provides at least a list of public cryptographic keys stored in association with the client device 204; and / or token data 220 that provides a mapping between generated tokens and transactions or accounts.

[0067] In some embodiments, the account binding module 220, in conjunction with the processor 216, may be configured to receive an indication from the authorization entity server 206 that the client device 204 is to be registered with respect to a particular account. In some embodiments, the indication may include a device identifier (e.g., a phone number) of the client device 204 and an account number (e.g., a primary account number (PAN)). In some embodiments, after receiving the indication, the account binding module 220 may generate a token to be associated with the client device 204. The token may be stored by the SRT server 202 in a token repository (e.g., token data 226) associated with the client device 204. Additionally, the account binding module 220 may generate a cryptographic key pair associated with the client device 204 and the account number. One key of the cryptographic key pair may be assigned as the private key 234, and the other key may be assigned as the public key 238. The cryptographic key assigned as the private key 234 may be delivered to the client device 204 using a known secure key delivery protocol. In some embodiments, the private key 234 may be provisioned onto the client device 204 via a message (e.g., via the received device identifier) transmitted by the SRT server 202 to the client device 204. In some embodiments, the private key 234 may be provisioned onto the client device 204 via a message transmitted by the authorization entity server 206 to the client device 204. In some embodiments, the public key 238 may be transmitted to the authorization entity server 206. In some embodiments, the account binding module 220 may be configured to verify the authenticity of an authentication indicator signed by the client device 204 using the private key 234.

[0068] In some embodiments, the account binding module 220 may also be configured to generate a token after receiving an indication that an authentication indicator received from the client device 204 has been verified. In some embodiments, the token may be a one-time use token that is only authorized to be used with a related specific transaction. In some embodiments, the token may be specific to both the client device 204 and the resource provider, as the token may be used by the resource provider multiple times for the client device 204 (e.g., an "archival card" token). For example, when operating with a specific client device 204 for the first time, the resource provider may receive a token generated in the manner described herein. The resource provider may then store the token in memory for use in conjunction with the client device 204 until an expiration date (or some other suitable expiration condition) associated with the token. The account mapping module 220 may store the generated token in a token repository (e.g., token data 226) that has a mapping to the account for which the token was generated. After receiving an authorization request message that includes the token, the SRT server 202 may query the token repository to identify the account associated with the token. The SRT server 202 may then continue the transaction of the authorization request message using the identified account information.

[0069] The SRT server 202 may also include a communication interface 228 that enables the SRT server 202 to communicate with a stored database, another computing device or server, one or more remote devices, other application servers, and / or any other suitable electronic device. In some embodiments, the communication interface 228 may enable the SRT server 202 to communicate with other electronic devices on a network (e.g., a private network). The SRT server 202 may also include input / output (I / O) devices and / or ports 230, such as for enabling connections to a keyboard, mouse, pen, voice input device, touch input device, display, speaker, printer, etc.

[0070] The client device 204 may be any electronic device capable of communicating with other electronic devices. For example, the client device 204 may be a mobile phone capable of wirelessly communicating with several other electronic devices. In some embodiments, the client device 204 may be Figure 1An example of the client device 102 depicted. The client device 204 may have several software modules installed thereon, including an authentication application 231 and at least one service provider application 232. In some embodiments, the client device may also include at least one private key 234 in its memory. In some embodiments, the authentication application 231 may include computer-executable instructions that cause the client device 204 to perform at least a portion of the functions described herein. For example, in some embodiments, the authentication application 231 of the client device 204 may be configured to generate a private key 234 (and associated public key 238) in response to verifying received authentication data.

[0071] In some embodiments, the service provider application 232 may be a mobile application installed on and executed from the client device 204. According to at least some embodiments, the service provider application 232 may be configured to authenticate a user and generate an authentication indicator indicating whether the user has been authenticated. Subsequently, the authentication application 231 of the client device 204 may be configured to sign the authentication indicator by performing a cryptographic algorithm on the authentication indicator using the private cryptographic key 234, which is provided to the client device by the account binding module 220 described above. It should be noted that there are several techniques known to those skilled in the art for signing data in this manner. In some embodiments, the client device 204 may store a token generated by the account binding module 220 described above. However, it should be noted that in at least some embodiments, it is not necessary to provide a token to the client device.

[0072] In some embodiments, the authorization entity 206 may be Figure 1 An example of the authorization entity server 106 depicted, which may be configured to determine whether a particular transaction should be authorized. The authorization entity 206 may maintain several accounts, at least one of which may be associated with the client device 204. In some embodiments, the authorization entity 206 may maintain several tokens 236 that are mapped to the accounts maintained by the authorization entity. In some embodiments, the authorization entity 206 may maintain one or more public keys 238 associated with a particular client device 204. It should be noted that in some embodiments, the authorization entity 206 may not store the token data 236 or the public key 238 (e.g., the data may be stored on the SRT server 202).

[0073] Figure 3Illustrates the registration process of an authentication system 300 according to some embodiments. The authentication system 300 may include a communication device operated by a user, such as a client device 310, and a secure remote server 320. In some embodiments where the system 300 is used to authenticate a user for a transaction, the system 300 may also include an issuer 330 (an example of an authorizing entity) associated with the user account. The client device 310 may have an authentication application installed therein. The authentication application may be downloaded from an application store or pre-installed on the client device 310, for example. In some embodiments, the authentication application may be compatible with multiple service providers and may be used to authenticate a user in the case of different service providers. The secure remote server 320 may securely store credentials associated with the user account and may be configured to release the user's credentials after successfully authenticating the client device 310 to the secure remote server 320. In some embodiments, the secure remote server 320 may be associated with or operated by a token service provider.

[0074] The registration process may begin by the user starting the authentication application on the client device 310. The user may select a biometric service provider to register with the authentication application. Examples of biometric service providers may include service provider applications configured to enable the client device 310 to obtain a fingerprint, a retina scan, facial recognition, voice recognition, or other unique human characteristics detectable by the client device 310. In some embodiments, the presence of a secondary device coupled to or near the client device 310 may be used as an alternative service provider. The user may register multiple types of service providers with the authentication application and only needs to register each specific service provider once. Then, the registered service providers may be selected to authenticate the user to one or more compatible service providers.

[0075] Next, the user may select a compatible service provider and configure which service provider will be used to authenticate the user to the service provider. One or more service providers may be selected for a particular service provider. In some embodiments, different service providers or different combinations of service providers may be used for different service providers. When multiple service providers are selected for a particular service provider, the user may be authenticated when all of the multiple service providers have been verified or when one of the multiple service providers has been verified. In some embodiments, the service providers may be prioritized such that higher-priority service providers are requested first and lower-priority service providers may be requested after a predetermined number of unsuccessful attempts. In some embodiments, the user may also optionally register the phone number or other device identifier of the client device 310 with the service provider.

[0076] When linking a selected service provider to a specific service provider, the authentication application can generate a public / private key pair and associate the public / private key pair with the service provider. Subsequently, the public key can be sent to a secure remote server 320 associated with the service provider for storage. In some embodiments, the public key can also optionally be sent to the issuer 330, and the issuer 330 can generate a one-time password (OTP) and send the OTP to the client device 310 for verification. The client device 310 can send the OTP back to the secure remote server 320 to verify that the client device 320 is a valid device of the user. The issuer 330 and / or the secure remote server 320 can then provision a token for the user account and associate the token with the selected service provider and the public key. In some embodiments, the token does not need to be stored on the client device 310. Instead, the token can be stored at the secure remote server 320 and released by the secure remote server 320 after authenticating the user and the client device 310 to the secure remote server 320. This can enhance the security of the system because the token does not reside on the client device 310 and thus cannot be compromised by malware on the client device 310.

[0077] Figure 4 Depicts an example provisioning process according to some embodiments, whereby a user can manually add their account to be processed by the SRT platform and a private key and / or a token can be provisioned to the client device.

[0078] In this example provisioning process, the user can provide an indication of one or more accounts associated with the user to the SRT platform. In some embodiments, the SRT platform can identify and contact an authorized entity (such as an issuer) associated with the indicated account. For example, the SRT platform can identify the authorized entity associated with a specific account indicated by the user based on an indicator within the provided account information. The SRT server can then communicate with the authorized entity to verify the account. The authorized entity associated with the account can then verify that the user is associated with the account. Subsequently, the authentication process can be performed as described herein.

[0079] In some embodiments, this process can involve requiring the user to provide at least one account number via the input area 402 at 404. The SRT platform can then determine the transaction processing network and / or authorized entity associated with the account based on the provided account number. It should be noted that at least some account identifiers can include a bank identification number (BIN) that can be used to identify both the transaction processing network and the authorized entity as part of the account number. The SRT platform can then communicate with the identified authorized entity associated with the identified transaction processing network.

[0080] In some embodiments, an identified authorization entity associated with an identified transaction processing network may identify one or more communication channels associated with a user of an account. For example, when opening an account with an authorization entity, the user may be associated with a specific communication channel. One or more communication channels, or at least a blurred version of those communication channels, may be presented to the user at 406 to enable the user to verify his or her ownership of the account through those communication channels. In some embodiments, multiple communication channels may be presented to the user for selection. In some embodiments, a default communication channel may be selected for communicating with the user.

[0081] Once the appropriate communication channels are identified, the authorization entity or the SRT platform may transmit verification details to the user through the identified communication channels. In some embodiments, the verification details may include a code or a pin. Then, at 408, the user may be required to provide those verification details back in order to verify that the user can at least utilize the communication channels.

[0082] In some embodiments, once the user has been verified as the owner of the account using the techniques depicted in Figure 4 a private cryptographic key may be provisioned to the client device that initiated the process. The private cryptographic key may be generated by the SRT server and may be used by the client device to sign authentication indicators in the future.

[0083] As an illustrative example, as depicted in Figure 4 at 404, the user may be prompted to enter an account associated with himself or herself. In this example, the authorization entity may initiate the verification process once contacted. For example, the authorization entity may provide verification details (such as a one-time code) to a communication channel known to be associated with the user. To this end, at 406, the authorization entity may provide the user with a choice of the communication channel to which the verification details will be transmitted. Then, at 408, the user may be required to retrieve the verification details in order to verify that the user is authentic. If the verification details provided by the user match the verification details sent through the selected communication channel, the account may be verified as being associated with the user at 410, and a private key may be provisioned to the client device. It should be noted that the verification process described herein may be separate from the authentication processes described elsewhere. In some embodiments, even if the user has verified his or her ownership of the account in the manner described in Figure 4 the user may still be authenticated using other techniques described herein. When authenticating using the techniques described herein, the provisioned private key may be used to sign the authentication indicators generated as a result of the authentication.

[0084] Figure 5Illustrates a process of authenticating a user to a service provider using an authentication system according to some embodiments. When a user intends to access an account, service, or function associated with a service provider, the user may initiate an application associated with the service provider on a client device 510. The application may be the same authentication application used to register the user with the service provider, a dedicated application provided by or associated with the service provider (such as a mobile wallet, mobile payment application, merchant application, etc.), or may be a web browser through which the user can access a web page or login page of the service provider. The application may determine one or more service providers previously linked to the service provider the user is attempting to access and request that the user provide the one or more service providers associated with the service provider. In some embodiments, the application may request that the user provide all service providers in the case where a combination of service providers is being used, or may request service providers according to a prioritized order. Subsequently, the user may provide the service providers to the client device 510. After verifying that the service providers provided by the user match the previously registered service providers, the client device 510 may use a private key linked to the user's account through the service provider to sign an authentication indicator.

[0085] Subsequently, an access request including the signed authentication indicator is sent to a secure remote server 520 to indicate to the secure remote server 520 that the user has been successfully authenticated to the client device 510. In some embodiments, the access request may include data representing the service providers or an indicator indicating which service provider(s) the user provided. Subsequently, the secure remote server 520 may verify the signature by using a stored public key linked to the user's account associated with the service provider. After verifying the signature, the secure remote server 520 may grant the user access to the service provider.

[0086] In embodiments where the secure remote server 520 is associated with a token service provider, the secure remote server 520 may issue a token associated with the user's account to a merchant 540 to enable the user to conduct a transaction with the merchant 540. In some embodiments, the access request may further include transaction details of the transaction, and the secure remote server 520 may generate a transaction authentication verification value and provide the transaction authentication verification value and the token. For example, the transaction authentication verification value may be a password generated based on the transaction details and / or the token. Subsequently, the merchant 540 may provide the token or the token and the transaction authentication verification value in an authorization request message to request authorization for the transaction.

[0087] In some scenarios, a user may access a service provider using a device different from the communication device used to register the user with the service provider. Thus, the device that the user is using to access the service provider may not have the service provider or sensor hardware previously stored necessary to authenticate the user. For example, a user may use a desktop computer instead of the user's client device to access a merchant website, and the desktop computer may not have a fingerprint reader or may not have access to the fingerprint data previously stored by the user to properly authenticate the user. In such scenarios, a cross-device authentication scheme may be used.

[0088] Figure 6 FIG. shows a process of authenticating a user to a service provider using multiple devices. When a user attempts to access a service provider from a different device, such as accessing a website of the service provider using a web browser on device 650 that does not have the service provider previously stored, the user may enter a device identifier such as a phone number or an IP address, which is associated with a communication device 610 that does have the device identifier. Then, device 650 may push an authentication request to communication device 610. In response, communication device 610 may request the user to provide the service provider associated with the service provider. Then, the user may provide the service provider to client device 610. After verifying that the service provider provided by the user matches the previously registered service provider, communication device 310 may sign the authentication indicator using a private key linked to the user account through the service provider.

[0089] Next, an access request including the signed authentication indicator is sent to a secure remote server 620 to indicate to the secure remote server 620 that the user has been successfully authenticated to communication device 610. In some embodiments, the access request may include data representing the service provider, or an indicator indicating which service provider(s) the user provided. Then, secure remote server 320 may verify the signature using a stored public key linked to the user account associated with the service provider. After verifying the signature, secure remote server 620 may grant the user access to the service provider.

[0090] In an embodiment where the secure remote server 620 is associated with a token service provider, the secure remote server 620 may issue a token associated with a user account to a token-releasing merchant 640. The user accesses the website of the merchant on the device 350 to enable the user to conduct transactions with the merchant 640. In some embodiments, the access request may further include transaction details of the transaction, and the secure remote server 620 may generate a transaction authentication verification value and provide the transaction authentication verification value in combination with the token. For example, the transaction authentication verification value may be a password generated based on the transaction details and / or the token. The transaction authentication verification value may accompany the token in an authorization request message and may serve as evidence that the token is being used in the appropriate corresponding transaction channel or mode (e.g., physical point of sale versus e-commerce). Subsequently, the merchant 640 may provide the token or the token and the transaction authentication verification value in the authorization request message to request authorization for the transaction.

[0091] Figure 7 FIG. 700 is a flowchart illustrating a process for performing authentication of a user according to at least some embodiments. Process 700 may be executed on the secure remote transaction server 202 depicted in Figure 2 FIG.

[0092] Process 700 may begin at 702, where a request to register an account with the system described herein is received. In some embodiments, the request may be submitted by a user of a client device via a mobile application installed on the mobile device. In some embodiments, the request may be conveyed from an authorization entity to the secure remote transaction server. For example, after submitting a request to register an account with the system described by the user, the request may be transmitted to the authorization entity. Subsequently, the authorization entity may forward the request to the secure remote transaction server. In this example, before or after the request is forwarded to the secure remote transaction server, the authorization entity may determine whether the user of the client device is authorized to access the account.

[0093] At 704, the process may involve determining that the user is authorized to access the account. In some embodiments, this may involve the secure remote transaction server or the authorization entity associated with the account contacting the user via a stored communication channel for the account. For example, when creating an account, the user may be required to provide a communication channel (e.g., an email address or a phone number) that will be associated with the account through a know-your-customer (KYC) process. In this example, the user may be contacted via the communication channel provided during account creation. In some embodiments, determining that the user is authorized to access the account may involve transmitting a one-time password to the user via the communication channel and causing the client device to prompt the user to enter the one-time password. In these embodiments, after determining that the one-time password entered by the user matches the transmitted one-time password, it may be determined that the user is authorized to access the account.

[0094] At 706, a password key pair associated with an account may be generated. At least the public key of the password key pair may be stored on a secure remote transaction server. At least the private key of the password key pair may be stored on a client device. In some embodiments, the password key pair may be generated by the client device. For example, the client device may generate the password key pair and then may transmit the public key to the secure remote transaction server. In some embodiments, the secure remote transaction server may generate the password key pair. For example, the secure remote transaction server may generate the password key pair and then may transmit the private key to the client device. In some embodiments, in addition to storing the public key, the secure remote transaction server may also forward the public key to an authorized entity associated with the registered account.

[0095] At 708, the process may involve generating a token associated with the account. In some embodiments, the token may be generated by the secure remote transaction server. In some embodiments, the token may be generated by an authorized entity server and transmitted to the secure remote transaction server. Then, the generated token may be stored in association with the account.

[0096] At 710, the process may involve receiving a request to complete a transaction. In some embodiments, the request may be received at the secure remote transaction server from an access device that manages access to one or more resources. The request may include various details related to the requested transaction and a signed authentication indicator. For example, after initiating the requested transaction, the user may be prompted to provide one or more biometric samples. The biometric samples provided by the user may be processed by a service provider application on the client device to determine the authenticity of the user. Once determined, the service provider application may generate an authentication indicator that indicates the likelihood that the user requesting the transaction is the user registered to the account. Then, the client device may sign the authentication indicator by performing a cryptographic operation on the authentication indicator using the private key generated and stored on the client device at 706. The signed authentication indicator may be provided to the secure remote transaction server within the request received at 710.

[0097] At 712, after receiving the signed authentication indicator, the secure remote transaction server may verify the signed authentication indicator by performing a second cryptographic operation on the signed authentication indicator using the public key generated at 706 and stored at the secure remote transaction server. In this process, the second cryptographic operation may result in the creation of an unsigned version of the authentication indicator, which may then be processed to determine whether the user is authenticated. In some embodiments, the unsigned version of the authentication indicator may be compared to an expected authentication indicator result. In some embodiments, a likelihood value in the unsigned version of the authentication indicator may be compared to an acceptable risk threshold to determine whether a transaction should proceed. For example, the unsigned version of the generated authentication indicator may include the likelihood that the user requesting the transaction is the user registered to the account. In this example, the likelihood may be compared to a predetermined threshold. If the likelihood is greater than the predetermined threshold, the signed authentication indicator may be verified. After verifying the signed authentication indicator, the process may involve initiating the requested transaction at 714. This may involve providing the token stored in association with the account at 708 to the access device and receiving the request from the access device at 710.

[0098] Figure 8 A flowchart illustrating a process 800 for registering authentication data according to at least some embodiments. Process 800 may be performed on a communication device operated by a user, which may be an example of the client device 102 depicted in Figure 1 FIG.

[0099] Process 800 may begin at block 802, receiving a request to register authentication data for an account associated with a service provider. In some embodiments, the user may indicate one or more accounts to register. For example, the user may select one or more credit card numbers or bank account numbers to register with the system.

[0100] At block 804, the user may be prompted to provide authentication data. In some embodiments, the user may select the type of authentication data to provide and the application (e.g., biometric service provider) used to authenticate the user. In some embodiments, the system may automatically select an application to authenticate the user. It should be noted that the application performing the authentication (e.g., service provider application) may be different from the application used to request registration with the system.

[0101] At block 806, authentication data is received from a user, for example, via a sensor on the communication device. For example, a user may provide a biometric sample to the client device, which includes a fingerprint, voiceprint, facial image, or other suitable biometric information. At block 808, the received authentication data may be registered and stored on the communication device or on a remote server (such as a service provider application server) of a service provider application installed on the supporting communication device. Subsequently, the authentication data may be processed to authenticate the user of the communication device. For example, the service provider application may generate an authentication indicator indicating whether the user has been authenticated.

[0102] At block 810, the communication device may obtain a public key and a private key pair. In some embodiments, at least one private key may be received by the communication device from a secure remote server (e.g., an SRT server). For example, the communication device may send the authentication indicator along with the registration data to the secure remote server and may receive a private key generated by the secure remote server. In some embodiments, the public key and the private key pair of the cryptographic key pair may be generated by the communication device. In some embodiments, information obtained from the secure remote server and / or information associated with the communication device may be used to generate the cryptographic key pair. For example, the communication device may receive a base key pair from the secure remote server and may use some algorithm that modifies the base key pair with information from the communication device to generate the cryptographic key pair. At block 812, the private key is associated with the account and the authentication data and is stored on the communication device.

[0103] At block 814, the generated public key is sent to the secure remote server, and the secure remote server links the public key to a token associated with the account. In some embodiments, the token may be used by the user to access services associated with the account and may serve as a substitute for the actual account identifier of the account.

[0104] Figure 9 A flowchart of a process 900 for accessing an account according to some embodiments is shown. According to at least some embodiments, the process 900 may be executed on a communication device, which may be an example of the client device 102 depicted Figure 1 in.

[0105] The process 900 may begin at block 902, receiving a request to access an account from a user communication device. At block 904, the user may be prompted to provide authentication data previously registered for the account. In some embodiments, the user may be prompted to provide authentication data via a mobile application (e.g., a service provider application) installed on the communication device, which is separate from the mobile application by which the user requests access to the account.

[0106] At block 906, authentication data is received from a user, for example, via a sensor on a communication device. At block 908, the received authentication data is compared with registered authentication data. At block 910, it is determined that the received authentication data matches the registered authentication data. In some embodiments, the registered authentication data may be stored on a remote server that supports a biometric service provider application, and this step may involve providing the received authentication data to the remote server for verification. In some embodiments, the registered authentication data may be stored on the communication device and verified on the communication device.

[0107] At block 912, in response to determining a match, an authentication indicator is generated to indicate that the user has been verified. At block 914, the generated authentication indicator may be signed using a private key stored on the communication device associated with the account.

[0108] At block 916, the signed authentication indicator may be sent within an access request to a secure remote server. The secure remote server may verify the signed authentication indicator using a public key associated with the account and, in response to determining that the authentication indicator is verified, issue a token associated with the account to a service provider to grant the user access to the account. In some embodiments, verification of the authentication indicator may involve performing a cryptographic operation on the signed authentication indicator using the public key that caused the generation of the unsigned version of the authentication indicator. Subsequently, the unsigned version of the authentication indicator may be compared with the expected unsigned version of the authentication indicator.

[0109] Embodiments of the present disclosure provide several technical advantages over conventional systems. For example, embodiments of the present disclosure implement user authentication by leveraging existing service provider applications on mobile devices while enabling the SRT platform and authorizing entities to ensure that the authentication is performed by a legitimate client device. Since authorizing entities currently do not have this assurance in conventional systems, this represents a technical improvement over such systems (as these systems do not include a technical method for providing this functionality). Additionally, as indicated by the process flow described above, embodiments of the present invention can be used to securely authenticate a device and the user of the device when conducting remote transactions without the need for the user to enter a PIN or password. Further, since tokens and transaction authentication verification values are used in embodiments of the present invention, sensitive data such as account numbers, PII (personally identifiable information), etc. can be protected during transmission.

[0110] Although some of the examples described above are described in the context of secure remote commercial transactions, it should be understood that embodiments of the present invention can be used in other contexts where authentication and data security issues exist. For example, embodiments of the present invention can be used to obtain access to secure data (such as medical records, personal data such as tax records, etc.), or can be used in situations where a user may wish to obtain access to a secure location such as a building or a transportation station.

[0111] A computer system that can be used to implement any entity or component described herein will now be described. Subsystems in the computer system are interconnected by a system bus. Additional subsystems include a printer, a keyboard, a fixed disk, and a monitor, which can be coupled to a display adapter. Peripheral devices and I / O devices that can be coupled to an input / output (I / O) controller can be connected to the computer system by any number of components known in the art - such as a serial port. For example, a serial port or an external interface can be used to connect a computer device to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via the system bus allows the central processor to communicate with each subsystem and control the execution of instructions from the system memory or the fixed disk and the exchange of information between subsystems. The system memory and / or the fixed disk can embody a computer-readable medium.

[0112] The techniques described herein may relate to implementing one or more functions, processes, operations, or method steps. In some embodiments, the functions, processes, operations, or method steps may be implemented as a result of executing an instruction set or software code by a suitably programmed computing device, microprocessor, data processor, etc. The instruction set or software code may be stored in a memory or other form of data storage element accessible by the computing device, microprocessor, etc. In other embodiments, the functions, processes, operations, or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.

[0113] Any software component or function described in this application can be implemented as software code executed by a processor using any suitable computer language, such as Java, C++, or Perl, which uses conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium, such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive, or a floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium can reside on or inside a single computing device and can be present on or inside different computing devices within a system or network.

[0114] Although certain exemplary embodiments have been described in detail and shown in the drawings, it should be understood that such embodiments are merely illustrative of the invention and not limiting, and the invention is not limited to the specific arrangements and configurations shown and described, as various other modifications may occur to those of ordinary skill in the art.

[0115] As used herein, unless expressly indicated to the contrary, the use of "a" or "the" is intended to mean "at least one".

Claims

1. A computer-implemented method, comprising: Receiving, at a secure remote transaction server, a request to register an account from a client device, wherein a user of the client device selects a prioritization order of a plurality of service providers to be used for authenticating the user; Verifying, by the secure remote transaction server, that the client device is authorized to access the account; Associatively storing, by the secure remote transaction server, at least a public key of a cryptographic key pair with the account, wherein at least a private key of the cryptographic key pair is stored on the client device in association with the account; Generating, by the secure remote transaction server, a token to be associated with the account, the token being associatively stored with the account; Receiving, by the secure remote transaction server, from an access device, a request to complete a transaction associated with the account, the request including a signed authentication indicator, wherein after one or more of the plurality of service providers authenticate the user of the client device in accordance with the prioritization order of the plurality of service providers, an authentication indicator is generated by an authentication application on the client device and then signed using the private key to form the signed authentication indicator; Verifying, by the secure remote transaction server, the signed authentication indicator using the public key associatively stored with the account; And After verifying the signed authentication indicator, providing the token to the access device.

2. The computer-implemented method according to claim 1, wherein the signed authentication indicator is generated by the client device by performing a first cryptographic operation using the private key.

3. The computer-implemented method according to claim 2, wherein verifying the signed authentication indicator using the public key comprises: Performing a second cryptographic operation on the signed authentication indicator using the public key.

4. The computer-implemented method according to claim 1, wherein verifying that the client device is authorized to access the account includes: Identifying, by the secure remote transaction server, an authorized entity associated with the account based on information in the request; And Verifying, by the secure remote transaction server, the authenticity of the account through the authorized entity associated with the account.

5. The computer-implemented method according to claim 4, wherein the authenticity of the account is determined by the authorized entity using a one-time password.

6. The computer-implemented method according to claim 5, wherein the authorized entity transmits the one-time password to the client device through a stored communication channel for the account.

7. The computer-implemented method according to claim 1, wherein the cryptographic key pair is generated on the client device, and the public key is received by the secure remote transaction server from the client device.

8. The computer-implemented method according to claim 1, wherein the cryptographic key pair is generated on the secure remote transaction server, and the method further includes transmitting the private key to the client device.

9. The computer-implemented method according to claim 1, wherein the public key is forwarded to an authorized entity associated with the account.

10. A secure remote transaction server, comprising: A processor; And A memory including instructions which, when executed by the processor, cause the secure remote transaction server to perform at least the following operations: Receive a request to register an account from a client device, wherein a user of the client device selects a priority order of a plurality of service providers to be used for authenticating the user; Verify that the client device has the right to access the account; Associate and store at least the public key of a cryptographic key pair with the account, wherein at least the private key of the cryptographic key pair is stored on the client device in association with the account; Obtain a token to be associated with the account, and store the token in association with the account; Receive a request to complete a transaction associated with the account from an access device, the request including a signed authentication indicator, wherein after one or more of the plurality of service providers authenticate the user of the client device in accordance with the priority order of the plurality of service providers, an authentication indicator is generated by an authentication application on the client device and then signed using the private key to form the signed authentication indicator; Verify the signed authentication indicator using the public key stored in association with the account; And After verifying the signed authentication indicator, provide the token to the access device.

11. The secure remote transaction server according to claim 10, wherein verifying the signed authentication indicator using the public key comprises: Generate an unsigned version of the signed authentication indicator and evaluate the unsigned version of the signed authentication indicator.

12. The secure remote transaction server according to claim 11, wherein evaluating the unsigned version of the signed authentication indicator comprises: Compare the unsigned version of the signed authentication indicator with an expected result.

13. The secure remote transaction server according to claim 11, wherein evaluating the unsigned version of the signed authentication indicator comprises: Determine whether a likelihood value in the unsigned version of the signed authentication indicator exceeds a threshold.

14. The secure remote transaction server according to claim 10, wherein the token is subsequently used by the access device to complete the transaction.

15. The secure remote transaction server according to claim 10, wherein the token is generated as a random string.

16. The secure remote transaction server according to claim 10, wherein obtaining the token to be associated with the account includes receiving the token from an authorizing entity associated with the account.

17. A computer-implemented method, comprising: Receiving, by a communication device, a request for authentication data for registering an account associated with a service provider; Prompting, by the communication device, a user of the account to provide the authentication data; Receiving, by the communication device, the authentication data from the user; Receiving a selection of a priority order of a plurality of service providers to be used for authenticating the user; Registering, by the communication device, the authentication data on the communication device; Obtaining, by the communication device, the private key of a cryptographic key pair; Associating, by the communication device, the private key with the account and the authentication data; Receiving, by a service provider among the plurality of service providers of the communication device, a request to access the account; Prompting, by the service provider among the plurality of service providers of the communication device, the user to provide the authentication data; Receiving, by the service provider among the plurality of service providers of the communication device, the authentication data from the user; The authentication data received is compared with the registered authentication data by a service provider among the multiple service providers of the communication device; A service provider among the multiple service providers of the communication device determines that the received authentication data matches the registered authentication data; A service provider among the multiple service providers of the communication device generates an authentication indicator indicating that the received authentication data matches the registered authentication data; The communication device signs the authentication indicator using the private key; And The communication device sends the signed authentication indicator in an access request to a secure remote server, wherein in response to verifying the signed authentication indicator using the public key, the secure remote server issues a token to the service provider to grant the user access to the account.

18. A communication device, comprising: A processor; And A computer-readable medium including code executable by the processor to perform the method of claim 17.

Images