Systems and methods for preventing token authentication replay attacks

Abstract

A method includes a server computer receiving a request message from a token requester computer representing a user device. The request message includes a first current token tracking value and a first function index value. The server computer may determine a second function index value. The server computer may then compare the first function index value with the second function index value. If the first function index value matches the second function index value, the server computer may determine a function based on the first function index value and a stored function table associated with the user device. The server computer may then determine a second current token tracking value based on the function and compare the first current token tracking value with the second current token tracking value. The server computer may generate a response message in response to the comparison.

Description

Background Technology

[0001] Replay attacks during token authorization are a phenomenon where an attacker performs a man-in-the-middle attack to steal a token and then use that token to gain authorization. In some cases, attackers can use various channels (e.g., phishing emails, social media, internet add-ons, etc.) to establish a connection with a user device (e.g., a host), ultimately attempting to steal that device via a replay attack. This allows the attacker to snoop on the host's protected data and use that data for their own purposes. When the host initiates token authorization (e.g., within an application or online based on token authorization), the attacker steals a copy of the protected password. The protected password contains cryptographic credentials for the user device, verified and authenticated by the authorizing entity to approve the interaction. The attacker then uses the same protected data to initiate authorization. This is a form of identity theft, where the attacker steals the user's identity and uses it for theft. These attacks increase with the prevalence of token authorization.

[0002] The embodiments of this disclosure address this problem and other problems individually and collectively. Summary of the Invention

[0003] The embodiments relate to methods and systems for preventing replay attacks (e.g., for token authentication).

[0004] One embodiment relates to a method comprising: receiving a request message from a user device by a server computer, the request message including a first current token tracking value and a first function index value; determining a second function index value by the server computer; comparing the first function index value with the second function index value by the server computer; if the first function index value matches the second function index value, determining a function by the server computer based on the first function index value and a stored function table associated with the user device; determining a second current token tracking value by the server computer based on the function; comparing the first current token tracking value with the second current token tracking value by the server computer; and generating a response message by the server computer in response to the comparison.

[0005] Another embodiment relates to a server computer, including: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to implement a method comprising: receiving a request message from a user device, the request message including a first current token tracking value and a first function index value; determining a second function index value; comparing the first function index value with the second function index value; if the first function index value matches the second function index value, determining a function based on the first function index value and a stored function table associated with the user device; determining a second current token tracking value based on the function; comparing the first current token tracking value with the second current token tracking value; and generating a response message in response to the comparison.

[0006] Further details regarding embodiments of this disclosure can be found in the detailed description and accompanying drawings. Attached Figure Description

[0007] Figure 1 A block diagram of a replay attack prevention system according to an embodiment is shown.

[0008] Figure 2 A block diagram of the components of a server computer according to an embodiment is shown.

[0009] Figure 3 A flowchart illustrating the pre-fitting process according to an embodiment is shown.

[0010] Figure 4 A flowchart illustrating the authorization process according to an embodiment is shown.

[0011] Figure 5 A flowchart illustrating a secure location access process according to an embodiment is shown. Detailed Implementation

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

[0013] "User" can include an individual. In some embodiments, a user can be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may also be referred to as a cardholder, account holder, or consumer.

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

[0015] A “user identifier” may include any data field that can identify a user. A user identifier may include any suitable alphanumeric string. In some embodiments, a user identifier may be derived from user identification information. In some embodiments, a user identifier may include an account identifier associated with the user.

[0016] The term "verification" and its derivatives can include the process of using information to determine whether an underlying subject is valid under a given set of conditions. Verification can include any comparison of information to ensure that certain data or information is correct, valid, accurate, legitimate, and / or credible.

[0017] A "resource provider" can be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, transportation departments, government entities, site and residential operators, etc.

[0018] "Interaction" can include reciprocal effects or influences. "Interaction" can include communication, contact, or exchange between parties, devices, and / or entities. Example interactions include transactions between two parties and data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, secure web pages, secure locations, etc. In other embodiments, an interaction can include a payment transaction in which two devices and / or entities may interact to facilitate a payment.

[0019] An "authorization request message" can be an electronic message requesting authorization for an interaction. In some embodiments, the authorization request message may be sent to a network processing computer and / or an authorization entity computer to request authorization for the interaction. According to some embodiments, the authorization request message may comply with International Organization for Standardization (ISO) 8583, which is a standard for systems that exchange information related to electronic transactions associated with payments made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): service code, card verification value (CVV), dynamic card verification value (dCVV), primary account number or "account number" (PAN), token, username, expiration date, etc. The authorization request message may also include interaction information, such as any information associated with the current interaction, such as transaction value, merchant identifier, merchant location, acquiring bank identifier (BIN), card acceptor ID, information identifying the item being purchased, etc., and any other information that may be used to determine whether to identify and / or authorize the interaction.

[0020] An "authorization response message" can be a message responding to an authorization request message. In some cases, an authorization response message can be an electronic message reply to an authorization request message generated by an authorization entity's computer or a network processing computer. By way of example only, an authorization response message may include one or more of the following status indicators: Approval – the transaction is approved; Rejection – the transaction is not approved; or Call Center – further information is pending, and the merchant must call the toll-free authorization number. An authorization response message may also include an authorization code, which may be a code indicating approval of the transaction returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via a network processing computer). This code can serve as evidence of authorization.

[0021] "Authorizing entity" can be the entity requesting authorization. Examples of authorizing entities include issuers, government agencies, document repositories, access administrators, etc. Authorizing entities can operate authorized entity computers. "Issuer" can include commercial entities (e.g., banks) that issue and optionally maintain user accounts. Issuers can also issue payment credentials stored on user devices, such as cellular phones, smart cards, tablets, or laptops, to consumers, or in some embodiments to portable devices.

[0022] A "token" can be a substitute for a credential. A token can be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc.

[0023] A "payment token" may include an identifier for a payment account, which is an alternative to an account identifier such as a primary account number (PAN) and / or an expiry date. For example, a token may include a series of alphanumeric characters that can be used as an alternative to the original account identifier. For example, the token "4900 0000 0000 0001" may be used in place of the PAN "4147 0900 00001234". In some embodiments, the token may be "formatted" and may have a numerical format consistent with account identifiers used in existing transaction processing networks (e.g., the ISO 8583 Financial Transaction Message Format). In some embodiments, the token may replace the PAN in initiating, authorizing, processing, or resolving payment transactions, or represent the original credentials in other systems where the original credentials would typically be provided. In some embodiments, a token value may be generated such that the original PAN or other account identifier may not be computably recoverable from the token value. Furthermore, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and to identify the entity issuing the token.

[0024] "Tokenization" is the process of replacing data with alternative data. For example, a payment account identifier (e.g., PAN) can be tokenized by replacing the master account identifier with a replacement number (e.g., a token) that can be associated with the payment account identifier.

[0025] A “token provider” or “token service computer” may include a system that serves payment tokens. In some embodiments, the token service system may facilitate the requesting, determining (e.g., generating), and / or issuing of tokens, and maintain the established token-to-PAN mapping in a repository (e.g., a token vault). In some embodiments, the token service system may establish a token security level for a given token to indicate the confidence level of the token’s binding to the PAN. The token service system may include or communicate with a token vault storing generated tokens. The token service system may support token processing for payment transactions submitted using tokens by de-tokenizing the tokens to obtain the actual PAN. In some embodiments, the token service system may include only a tokenization computer, or may include a tokenization computer in combination with other computers such as a transaction processing network computer. Various entities in the tokenization ecosystem may assume the role of a token service provider. For example, payment networks and issuers or their agents may become token service providers by implementing a token service according to embodiments of the present invention.

[0026] A "digital wallet" may include an electronic module that allows a device to conduct e-commerce transactions. In some embodiments, a digital wallet may store account information associated with a user (e.g., bank account number, PAN, etc.). A digital wallet may be associated with or store one or more unique asymmetric key pairs, TAVVs, etc., and in at least one embodiment, a digital wallet may store or otherwise access tokens. In some embodiments, such a digital wallet may be configured to encrypt transaction information (e.g., account data, etc.) using private keys, TAVVs, tokens, etc. In some embodiments, a digital wallet may be a digital wallet application, such as a digital wallet application stored on a user's device.

[0027] A “token domain” can indicate the area and / or environment in which the token can be used. Instances of token domains may include, but are not limited to, payment channels (e.g., e-commerce, physical point-of-sale, etc.), POS input modes (e.g., contactless, magnetic stripe, etc.), and merchant identifiers, thereby uniquely identifying where the token can be used. A set of parameters (i.e., token domain restriction controls) can be established by the token service provider as part of token issuance, which can allow the appropriate use of the token to be enforced in payment transactions. For example, token domain restriction controls can restrict the use of the token to a specific presentation mode—e.g., contactless or e-commerce presentation mode. In some embodiments, token domain restriction controls can restrict the use of the token to a specific merchant that can be uniquely identified. Some exemplary token domain restriction controls may require verification of the existence of a token password unique to a given transaction. In some embodiments, the token domain may be associated with the token requester.

[0028] "Token validity period" can include the token's expiration date / time. The token validity period can be transferred between entities in the tokenized ecosystem during transaction processing to ensure interoperability. The token expiration date can be a numerical value (e.g., a 4-digit number). In some embodiments, the token validity period can be expressed as the duration calculated from the issuance date.

[0029] A "token request message" can be an electronic message used to request a token. A token request message may include information that can be used to identify a payment account or digital wallet, and / or information used to generate a payment token. For example, a token request message may include credentials, mobile device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, information identifying the tokenization service provider, a merchant identifier, a password, and / or any other suitable information. The information included in a token request message may be encrypted (e.g., using an issuer-specific key).

[0030] A "token response message" can be a message responding to a token request. A token response message may include an indication that the token request has been approved or rejected. A token response message may also include a payment token, mobile device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, information identifying the tokenization service provider, a merchant identifier, a password, and / or any other suitable information. The information included in a token response message may be encrypted (e.g., using an issuer-specific key).

[0031] The "token tracking value" may include a value that corresponds to the token state. The token tracking value may include any suitable number of characters (e.g., 3, 5, 6, etc.). In some embodiments, the token tracking value may be the current token tracking value (e.g., a first current token tracking value, a second current token tracking value, etc.). In some embodiments, the token tracking value may be a control token tracking value (e.g., a first control token tracking value, a second control token tracking value, etc.).

[0032] The "current token tracking value" can include a change value that tracks the validity of the associated token used in the interaction. The current token tracking value can be an identifier associated with the token. For example, the current token tracking value can be a verification value submitted along with a payment token or payment credential of a payment account. In some embodiments, the current token tracking value can be 3, 4, 5, or more characters long. In some embodiments, the current token tracking value can be generated based on one or more data elements. Inputs to the current token tracking value can include a function index value, a function, and a control token tracking value. In some embodiments, both the current token tracking value and the control token tracking value can be used during the interaction, as described in the following examples.

[0033] A "control token tracking value" may include a token tracking value sent or received prior to the current token tracking value. A control token tracking value may be paired with the current token tracking value. In some embodiments, the control token tracking value may be a value used to generate the current token tracking value.

[0034] A "function" can include a relation or expression involving one or more variables. A function can accept input, perform appropriate processing, and return output. A function can include any suitable mathematical relation. An example function could include accepting an input value, multiplying the input value by a predetermined constant, multiplying the result by a second predetermined constant, and then truncating the final value to include four digits, thus producing an output value.

[0035] A "function pool" may include data items containing multiple functions. For example, a function pool may include 100 functions; however, it should be understood that a function pool may include any suitable number of functions (e.g., 200, 300, 500, 1,000, 10,000 functions, etc.). In some embodiments, the function pool may be generated by an authorized entity computer and then provided to the network processing computer for further use. In other embodiments, the network processing computer may generate the function pool locally.

[0036] A "function table" can include a table containing a subset of functions from a function pool. For example, a function table could include 10 functions from a function pool that contains 100 functions.

[0037] The "Function Index Value" can include an index value associated with the function's location or position in the function table. The function index value can indicate a function in the function table, and the indicated function can be used to determine the current token tracking value based on the control token tracking value.

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

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

[0040] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers that work like cells. In one example, a server computer can be a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0041] I. Introduction

[0042] Embodiments of this disclosure provide a token authentication and tracking model to prevent replay attacks in token authorization. The methods and systems described herein detail how uniqueness is established in each authorization and how these authorizations are linked and tracked to capture and deny any replay attacks.

[0043] The embodiments relate to preventing replay token attacks. The network processing computer may store a function table including functions for generating authentication values ​​(e.g., current token tracking values), which can be used to verify token usage. When the current token tracking value is received during an interaction (e.g., a transaction), the network processing computer can determine whether the authentication value is genuine. The network processing computer may identify the functions used to create the authentication values. Furthermore, in some embodiments, the input to the function may include a previous authentication value of the token (e.g., a control token tracking value). The embodiments make it difficult for a malicious party to use a stolen token. In order to use the token, a malicious party needs to know the functions used to generate authentication values ​​(e.g., current token tracking values) and previous authentication values ​​(e.g., control token tracking values).

[0044] II. System

[0045] According to an embodiment, a server computer (e.g., a network processing computer) can determine whether a value received in a request message is valid. An exemplary method may include the server computer receiving a request message from a token requester computer representing a user device. The request message may include a first current token tracking value and a first function index value. After receiving the request message, the server computer may determine a second function index value. The server computer may then compare the first function index value with the second function index value. If the first function index value matches the second function index value, the server computer may determine a function based on the first function index value and a stored function table associated with the user device. The server computer may then determine a second current token tracking value based on the function and compare the first current token tracking value with the second current token tracking value. The server computer may generate a response message in response to the comparison.

[0046] A. System Overview

[0047] Figure 1A system 100 according to an embodiment of the present disclosure is illustrated. System 100 includes a user device 102, a resource provider computer 104, a transmission computer 106, a network processing computer 108, an authorization entity computer 110, a token requester computer 112, and a token service computer 114. The user device 102 can operationally communicate with the token requester computer 112. The token requester computer 112 can operationally communicate with the resource provider computer 104 and the network processing computer 108. The network processing computer 108 can operationally communicate with the transmission computer 106, the authorization entity computer 110, and the token service computer 114. Furthermore, the transmission computer 106 can operationally communicate with the resource provider computer 104.

[0048] To simplify the explanation, Figure 1 A certain number of components are shown. However, it should be understood that embodiments of the invention may include more than one of each component. Additionally, some embodiments of the invention may include more than one of each component. Figure 1 All components shown are either fewer or more components.

[0049] Figure 1 Messages between computers and devices can be transmitted using secure communication protocols, such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); SSL; ISO (e.g., ISO 8583), etc. The communication network can include any one and / or a combination of the following: direct interconnection; the Internet; local area network (LAN); metropolitan area network (MAN); Operational Mission as a Node on the Internet (OMNI); secure custom connection; wide area network (WAN); wireless network (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.); etc. The communication network can use any suitable communication protocol to generate one or more secure communication channels. In some instances, the communication channel can include a secure communication channel, which can be established in any known manner, such as by using mutual authentication and session keys, and establishing a Secure Sockets Layer (SSL) session.

[0050] User device 102 may include any suitable device operated by a user. For example, user device 102 may include a mobile phone, laptop computer, desktop computer, smartwatch, and / or any other suitable device described herein. In some embodiments, user device 102 may include a digital wallet (e.g., a digital wallet application). In other embodiments, user device 102 may communicate with token requester computer 112, which may store tokens on behalf of user device 102.

[0051] In some embodiments, user device 102 may be associated with a user's payment account. For example, user device 102 may include a virtual wallet or payment application that can be associated with one or more of the user's payment accounts. In some embodiments, user device 102 is capable of using, for example, Wi-Fi. TM or Bluetooth TM The user device 102 communicates with the access device (e.g., a POS terminal) using a wireless data protocol. For example, the user device 102 can interact with the access device by establishing a connection using a wireless data protocol.

[0052] In some embodiments, system 100 may further include an access device (not shown). The access device may be an access point to an interactive processing system, which may include at least a transmission computer 106, a network processing computer 108, and an authorization entity computer 110. In some embodiments, the access device may be associated with or operated by a resource provider operating the resource provider computer 104. For example, the access device may include any suitable means for providing a user with access to an external computer system. Some examples of access devices include point-of-sale (POS) devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, websites, etc. In some embodiments, the access device may be configured to transmit information from one or more resources from a resource provider to the transmission computer 106 or the network processing computer 108. In some embodiments, the access device may be a personal computer that a user can use to initiate transactions (e.g., online interactions) with the resource provider computer 104.

[0053] The token requester computer 112 may include a computer that can request, store, manage, and provide tokens on behalf of user device 102 and / or upon request from user device 102. In some embodiments, the token requester computer 112 may be configured to maintain a digital wallet associated with a user of user device 102, as well as additional users of additional user devices. For example, the digital wallet may store user profile information, payment information (e.g., PAN or master account, payment token (i.e., PAN alternative), verification value such as CVV, etc.), bank account information, and / or the like, and may be used in various transactions, such as, but not limited to, e-commerce for retail purchases, social networks, money transfers / personal payments, mobile commerce, proximity payments, gaming, and / or the like, for retail purchases, digital goods purchases, utility payments, purchasing games or game credits from gaming websites, transferring funds between users, and so on.

[0054] In some embodiments, the digital wallet may also store the current token tracking value, the control token tracking value, the function table and function index value, or any combination thereof.

[0055] Resource provider computer 104 may include any suitable computer that can be operated by an entity that can provide resources (e.g., goods, services, information, access, etc.) to users. Resource provider computer 104 may generate authorization request messages for interactions between the resource provider and the user of user device 102. The resource provider computer may then transmit the authorization request messages to transmission computer 106.

[0056] In some embodiments, the resource provider computer 104 may receive an authorization request message from an access device associated with the resource provider computer 104.

[0057] The transmission computer 106 may include any suitable computer that can be operated by an entity (e.g., an acquirer). The acquirer may include a system of an entity (e.g., a bank) that has a business relationship with a particular resource provider, wallet provider, or another entity. The transmission computer 106 may issue and manage accounts (e.g., financial accounts) for resource providers. The transmission computer 106 may be configured to route authorization request messages for interactions to the authorization entity computer 110 via the network processing computer 108. The transmission computer 106 may be configured to route authorization responses received via the network processing computer 108 to the resource provider computer 104.

[0058] Network processing computer 108 can be configured to provide authorization services and clearing and settlement services for interaction. Network processing computer 108 may include a data processing subsystem, a wired or wireless network, including the Internet. Examples of network processing computer 108 include those composed of… VisaNet Operations TM For example, VisaNet TM The processing network can handle credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet TM Specifically, this includes the Visa Integrated Payment (VIP) system for processing authorization requests and the BaseII system for performing clearing and settlement services. The network processing computer 108 may include a server computer. In some embodiments, the network processing computer 108 may forward authorization requests received from the transmitting computer 106 to the authorizing entity computer 110 via a communication channel. The network processing computer 108 may also forward authorization response messages received from the authorizing entity computer 110 to the transmitting computer 106.

[0059] Token service computer 114 can be configured to provide tokenization services. For example, token service computer 114 can provide payment tokens representing PANs and / or other payment credentials. For example, a token request message can be sent to token service computer 114 (e.g., from network processing computer 108 or other suitable computer), and token service computer 114 can then generate a payment token and / or associate the payment token with the payment credentials in the token request message.

[0060] In some embodiments, the token service computer 114 may be associated with or combined with the network processing computer 108, the authorization entity computer 110, the transmission computer 106, or any other suitable entity. For example, in embodiments, the tokenization service may be provided by the authorization entity computer 110, the network processing computer 108, the transmission computer 106, a third-party service provider, or any other suitable entity. Therefore, the token service computer 114 may be incorporated into system 100 as part of another entity. In some embodiments, such as Figure 1 As shown, the token service computer 114 can be a separate entity.

[0061] Authorizing entity computer 110 may include any suitable computer that can be operated by an authorizing entity. Authorizing entity computer 110 may represent an account issuer and / or an issuer processor. In some embodiments, authorizing entity computer 110 may be associated with a business entity (e.g., a bank) that may have issued accounts and / or payment cards (e.g., credit accounts, debit accounts, etc.) for interaction (e.g., payment transactions). In some embodiments, authorizing entity computer 110 and / or network processing computer 108 may operate as an authorization system. For example, interaction may be authorized by authorizing entity computer 110 upon successful token authentication.

[0062] The authorizing entity computer 110 can be configured to determine whether to authorize the interaction based on the authorization request message. After determining whether to authorize the interaction, the authorizing entity computer 110 can generate an authorization response message and transmit it to the network processing computer 106.

[0063] In some embodiments, upon receiving an authorization response message, network processing computer 106 may forward the authorization response message to transport computer 106. In some embodiments, network processing computer 106 may determine which transport computer to send the authorization response message to by evaluating routing tables and / or data elements in the authorization response message that indicate the appropriate transport computer (e.g., transport computer 106). Transport computer 106 may then forward the authorization response message to resource provider computer 104.

[0064] After receiving an authorization response message from network processing computer 106, transmission computer 106 may forward the authorization response message to resource provider computer 104. In some embodiments, after receiving the authorization response message, the resource provider computer in resource provider computer 104 may notify the user of the status of the interaction. For example, the resource provider computer may notify the user, via access device or user device 102, whether it has authorized the interaction (e.g., a transaction).

[0065] B. Network processing computer

[0066] Figure 2 A block diagram of a network processing computer 200 according to an embodiment is shown. The exemplary network processing computer 200 may include a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, an input element 210, an output element 212, and a computer-readable medium 208. The computer-readable medium 208 may include a function table module 208A, a function index value module 208B, and a token tracking value module 208C.

[0067] Memory 202 can be used to store data and code. Memory 202 can be coupled internally or externally to processor 204 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash memory, or any other suitable memory device. For example, memory 202 can store function pools, routing tables, etc. In some embodiments, memory 202 can also store function tables, current token tracking values ​​(e.g., a first current token tracking value, a second current token tracking value, etc.), control token tracking values ​​(e.g., a first control token tracking value, a second control token tracking value, etc.), function index values, etc.

[0068] Computer-readable medium 208 may include code executable by processor 204 to perform a method comprising: receiving a request message from a user device by a server computer, the request message including a first current token tracking value and a first function index value; determining a second function index value by the server computer; comparing the first function index value with the second function index value by the server computer; if the first function index value matches the second function index value, determining a function by the server computer based on the first function index value and a stored function table associated with the user device; determining a second current token tracking value by the server computer based on the function; comparing the first current token tracking value with the second current token tracking value by the server computer; and generating a response message by the server computer in response to the comparison.

[0069] The function table module 208A may include code or software executable by the processor 204 for creating a function table. The function table module 208A may work with the processor 204 to generate a function table to be associated with a token based on a function pool. For example, the function table module 208A may work with the processor 204 to generate a function table containing 10 functions by randomly selecting 10 functions from a function pool containing 1000 functions. The function table module 208A may work with the processor 204 to select a predetermined number of functions from the function pool to be included in the function table using any suitable random or pseudo-random function.

[0070] For example, the function table module 208A can, in conjunction with the processor 204, randomly generate a predetermined number of function index values. The function table module 208A can, in conjunction with the processor 204, generate function index values ​​[124,480,7,931,734,590,217,401,646,833]. The function table module 208A can, in conjunction with the processor 204, retrieve functions from the function pool associated with the function index values ​​[124,480,7,931,734,590,217,401,646,833]. Then, the function table module 208A can, in conjunction with the processor 204, create a function table including the retrieved functions. In some embodiments, the function table module 208A can, in conjunction with the processor 204, rebuild the indexes of the functions in the function table (e.g., values ​​from 0 to 9).

[0071] The function index value module 208B may include code or software executable by the processor 204 to determine function index values. The function index value module 208B may work with the processor 204 to determine a function index value corresponding to a request message received from the user device. For example, the request message may include a first current token tracking value and a first function index value. The function index value module 208B may work with the processor 204 to determine a second function index value.

[0072] For example, the function index value module 208B can, in conjunction with the processor 204, determine the function index value based on the current time. The function index value module 208B can, in conjunction with the processor 204, determine the current epoch time (et). Then, the function index value module 208B can, in conjunction with the processor 204, determine a specific number of digits in the current time. For example, the current time could be 1555396199. The function index value module 208B can, in conjunction with the processor 204, determine the hundreds digit or other suitable digits (e.g., units digit, tens digit, etc.) of the current time as the function index value.

[0073] The token tracking value module 208C may include code or software executable by the processor 204 to determine a token tracking value (e.g., the current token tracking value). The token tracking value module 208C may, in conjunction with the processor 204, determine the current token tracking value based on a control token tracking value (e.g., a previous token tracking value associated with the same token). The token tracking value module 208C may, in conjunction with the processor 204, determine the function in the function table associated with a function index value (e.g., determined by the function index value module 208B). After determining the function, the token tracking value module 208C may, in conjunction with the processor 204, input a control token tracking value (e.g., retrieved from memory or a token store) into the determined function. The output of the function may be the current token tracking value.

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

[0075] III. Methods

[0076] Examples may use the systems and devices described herein to at least determine whether a received token is valid. Figure 3-5 Some examples of such methods are described. In some embodiments, Figure 3 , 4 Network processing computers 306, 410, and 506 may respectively include Figure 1 and 2 Network processing computer 108 or network processing computer 200.

[0077] A. Token Tracking Overview

[0078] The embodiments provide systems and methods for generating the current token tracking value using, for example, a function with a time index and previous token tracking values ​​(e.g., control token tracking values).

[0079] The functions in the function table can be used to determine the current token tracking value. The selected function in the function table can be based on the current time. For example, at time t, the function index value fi could be:

[0080] fi = f(t)

[0081] The function index value fi can index 0 to n functions in the range f[0](x) to f[n](x), where x can be a control token trace value. Furthermore, the current token trace value can be called xc. The control token trace value can be called xp. The current token trace value xc can be determined based on the control token trace value xp.

[0082] xc = f[f(t)](xp)

[0083] The next (e.g., subsequent) control token tracking value xn can be the next value at time t1. The next control token tracking value xn can be determined based on the current token tracking value xc (e.g., also referred to as the control token tracking value at time t1).

[0084] xn=f[f(t1)](xc)

[0085] A tracking mechanism can be implemented by saving and transmitting the current token tracking value tATV as the subsequent control token tracking value ctATV. For each interaction (e.g., payment authorization), the token requester's computer or user device can create a current token tracking value tATV based on the control token tracking value ctATV, and then store the current token tracking value tATV as the newly formed control token tracking value ctATV. In an embodiment, this process may allow the device to create a tATV|ctATV chain, which establishes the tracking mechanism.

[0086] Similarly, the network processing computer can verify the current token tracking value tATV using the control token tracking value ctATV from the token store. Upon successful verification, the network processing computer can store (e.g., save) the current token tracking value tATV as the control token tracking value ctATV in the token store, or in some embodiments, store (e.g., save) it in the token service computer.

[0087] B. Token pre-allocation period

[0088] Figure 3 A flowchart illustrating the pre-fitting process according to an embodiment is shown. Figure 3The method illustrated is described in the context of a token requester computer requesting a token for a user device operated by a user. However, it should be understood that the invention can be applied to other situations (e.g., a user device may request a token, a resource provider computer may request a token, etc.). Furthermore, the interaction can be any suitable interaction between the user and the resource provider computer.

[0089] In step 1, the authorized entity computer 302 can generate a function pool. The function pool can include multiple functions. For example, the function pool can include 100 functions. The function pool can include, for example, functions F(x0) to F(x... n A function pool can include a function pool size (e.g., the number of functions included in the function pool). The function pool size can be any suitable number. For example, in some embodiments, the function pool size can be equal to or greater than 100 functions. In some embodiments, a larger function pool size can provide a higher level of security.

[0090] Function pool index function 0 f(x0) 1 f(x1) ... ... 100 f(x100)

[0091] Table 1: Example Function Pool

[0092] Table 1 above shows an example function pool. Each function can be associated with a function pool index. Furthermore, in some embodiments, each function in the function pool can be a different function. The authorized entity computer 302 can set the equations (e.g., single-order, polynomial, etc.) of the individual functions in the function pool.

[0093] A function pool can be represented in any suitable way. For example, in some embodiments, a function pool can be represented by JSON, which is a mathematical model. The root of the JSON can serve as the function pool, along with an array of indices containing an equation for a given f(x). Table 2 below shows a sample object model of a function pool.

[0094]

[0095] Table 2: Example JSON object model. Additionally, sample JSON code for representation purposes only is shown at index [0] for details:

[0096]

[0097]

[0098] After generating the function pool, the authorized entity computer 302 can provide the function pool to the network processing computer 306. In some embodiments, the authorized entity computer 302 can upload the function pool to the network processing computer 306 using a messaging service or file transfer protocol (FTP). In other embodiments, the authorized entity computer 302 can encrypt the function pool using, for example, the network processing computer's public key or other suitable cryptographic keys (e.g., a shared symmetric key). The authorized entity computer 302 can then provide the encrypted function pool to the network processing computer 306. The encrypted function pool can be encrypted in a way that allows the network processing computer 306 to decrypt the encrypted function pool to obtain the function pool.

[0099] In some embodiments, network processing computer 306 may generate function pools locally in a manner similar to that used by authorized entity computer 302.

[0100] At step 2, at any appropriate time after the network processing computer 306 receives the function pool from the authorization entity computer 302, the token requester computer 304 may transmit a token request message to the network processing computer 306. For example, the token requester computer 304 may request a token for a user of a user device. The token request message may include any suitable data associated with the user. For example, in some embodiments, the token request message may include a user identifier and / or credentials associated with the user.

[0101] In step 3, after receiving a token request message from the token requester computer 304, the network processing computer 306 can create a function table to associate with the user and / or user device requesting the token. During provisioning, the network processing computer 306 can dynamically create the function table for the token. The network processing computer 306 can create the function table from a function pool using a random function. For example, the random function can specify the functions to be included in the function table from the function pool.

[0102] The network processing computer 306 can use a random function, for example, to extract 10 random functions from a function pool and create a function table. However, it should be understood that any suitable number of functions in the function pool can be included in the function table. For example, the function pool can include 1000 functions, while the function table can include 100 functions selected from the function pool. Furthermore, the network processing computer 306 can generate a function index value for each selected function.

[0103] In some embodiments, a function table may include function index values ​​and associated functions. In other embodiments, a function table may include function index values ​​and function pool index values. In this case, when determining a specific function to utilize later, the network processing computer 306 may look up the function pool index in the function table based on the known function index. Then, the network processing computer 306 may look up the function in the function pool based on the known function pool index.

[0104] Table 3 below shows an example function table. In this example, it includes three columns: function pool index, function index, and function. However, it should be understood that in some embodiments, the function table may include two columns: function pool index and function index, or two columns: function index and function.

[0105]

[0106] Table 3: Example Function Table

[0107] The network processing computer 306 can further generate a first-time use control token tracking value. The network processing computer 306 can generate the control token tracking value based on a determined function index value (e.g., a specific number of digits of the current time) and a randomly generated number to be input into the function indicated by the function index value. In some embodiments, the first-time use control token tracking value can be a randomly generated number. The first-time use control token tracking value can be, for example, a four-digit number.

[0108] Additionally, during step 3, the network processing computer 306 can provide the function table and the first-time use control token tracking value to the token service computer 308. The network processing computer 306 can request the token service computer 308 to generate a token associated with the function table and the first-time use control token tracking value, and therefore also associated with the user.

[0109] Upon receiving the function table and the first-time use control token tracking value, the token service computer 308 can generate a token that can be associated with the received function table and the first-time use control token tracking value. The token service computer 308 can store the function table and the first-time use control token tracking value in a token store that can be associated with the token. For example, the first-time use control token tracking value can be stored in the token store so that it can be used in the next authorization. The token service computer 308 can generate the token in any suitable manner known to those skilled in the art.

[0110] In step 4, the token service computer 308 may, in response to receiving the function table, immediately provide a token to the network processing computer 306 using the control token trace value.

[0111] In step 5, after receiving the token from the token service computer 308, the network processing computer 306 can encrypt the function table, enabling the encrypted function table to be securely provided to the token requester computer 304. The corresponding user's function table JSON (e.g., as shown in Table 2) can be encrypted using the token requester's public key and transmitted to the token requester computer 304 as part of the token response message. The network processing computer 306 can then provide the token requester computer 304 with the control token tracking value, the encrypted function table, and the token as soon as possible.

[0112] Upon receiving the first-time use control token tracking value, the encrypted function table, and the token, the token requester computer 304 can decrypt the encrypted function table. For example, the token requester can decrypt the encrypted function table using its private key. The token requester computer 304 can securely store the first-time use control token tracking value, the decrypted function table, and the token. In some embodiments, the token requester computer 304 can store the encrypted function table and decrypt it at a later point in time when needed. At a later point in time, during the interaction, the token requester computer 304 can retrieve and utilize the control token tracking value, the decrypted function table, and the token, as described in further detail herein.

[0113] C. Authorization Process

[0114] Figure 4 A flowchart illustrating the authorization process according to an embodiment is shown. This will be described in the context of a user interacting with a resource provider to obtain resources. Figure 4 The method illustrated allows a user device to request a token requester computer to provide a token associated with the user to a resource provider computer operated by the resource provider. However, it should be understood that the embodiment can be applied to other situations (e.g., the user device stores the token and provides it to the resource provider computer, the resource provider computer requests a token from the token requester computer, etc.).

[0115] At step 450, user device 402 may transmit a request to token requester computer 404 to provide a token to resource provider computer 406 in response to user device 402 initiating an interaction with resource provider computer 406. In some embodiments, the request may also include a user identifier. In other embodiments, the request may include a resource provider computer identifier or any other suitable identifier that identifies to which party the token requester computer should deliver the token.

[0116] At step 452, after receiving a request from user device 402 to provide a token (e.g., associated with user device 402) to resource provider computer 406, token requester computer 404 may determine a first function index value. Token requester computer 404 may determine the first function index value in any suitable manner. For example, in some embodiments, token requester computer 404 may determine the first function index value based on the current time.

[0117] As an illustrative example, the token requester computer 404 can determine the current period time (et). For example, the current period time could be equal to the value 1555396199. The token requester computer 404 can select a predetermined number of digits for the current period time. For example, the token requester computer 404 can select the hundreds digit (e.g., the third digit from the left). In this case, the hundreds digit is equal to the value 1. The token requester computer 404 can use the hundreds digit 1 as the first function index value. By using the hundreds digit as the function index value, it is ensured that each 100 The index changes every second. However, it should be understood that the predetermined number of digits can be any suitable number of digits for the current period of time. For example, the predetermined number of digits can include tens digits, thousands digits, or any other suitable number or value determined therefrom.

[0118] At step 454, after determining the first function index value, the token requester computer 404 can determine the first current token tracking value. Furthermore, the token requester computer 404 can retrieve the first control token tracking value from secure storage. The first control token tracking value may be from pre-provisioning, for example, during... Figure 3 The control token trace value received at step 5. The token requester computer 404 can generate a first current token trace value based on the control token trace value.

[0119] For example, the token requester computer 404 can retrieve a function from a function table corresponding to a first function index value. From the first function index value determined above, which equals the value 1, the token requester computer 404 can determine to use a second function from the function table (e.g., since it corresponds to index 1, where the first function corresponds to index 0). The token requester computer 404 can extract the function f[fi](x) for the first function index value fi = 1. The token requester computer 404 can parse the function table in any suitable manner (e.g., a JSON function table model) to determine the function. The token requester computer can then input a first control token tracking value into the second function in the function table. The output of the second function can be a first current token tracking value. In some embodiments, the token requester computer 404 may generate a token tracking value (e.g., a current token tracking value or a control token tracking value) without using transaction-level payment data. For example, the token requester computer 404 can calculate the following formula, where f is a function, fi is a function index value, ctATV is the control token tracking value, and tATV is the current token tracking value.

[0120] tATV = f[fi](ctATV)

[0121] Furthermore, the token requester computer 404 can store the created first current token tracking value as a second control token tracking value. As an illustration, the token requester computer 404 can be configured to:

[0122] ctATV = tATV

[0123] As an illustrative example, the token requester computer 404 can input a first current token tracking value into a function. As an example, the first function index value can have a value equal to 1. The token requester computer 404 can determine the function associated with index 1. For example, the function could be tATV = truncate4(tATV * 2), and the first control token tracking value could be equal to the value 8967. The token requester computer 404 can determine that the current token tracking value (tATV) is 7934 = truncate4(8967 * 2).

[0124] By saving the first current token tracking value (tATV) as the second control token tracking value (ctATV), the token requester computer 404 can create a tracking mechanism between subsequent interactions and associated authorization request messages.

[0125] At step 456, the token requester computer 404 may provide the token, the first function index value, the first current token tracking value, and the first control token tracking value to the resource provider computer 406. In some embodiments, the token requester computer 404 may further provide a user identifier to the resource provider computer 406.

[0126] At step 458, after receiving the token, the first function index value, the first current token tracking value, and the first control token tracking value, the resource provider computer 406 may generate an authorization request message. The authorization request message may include the token, the first function index value, and the first current token tracking value, and / or any other suitable data related to the interaction between the user and the resource provider. The resource provider computer 406 may then provide the authorization request message to the transport computer 408.

[0127] For example, in some embodiments, the authorization request message may include a data item containing a concatenated version of a first function index value, a first current token tracking value, and a first control token tracking value. For instance, the data item could be (tATV|ctATV|fi).

[0128] The three data elements of the data item can be transmitted as a composite 9-byte numeric data block. The data can be identified by position; for example, the first four bytes could be the first current token tracking value (tATV), the next four bytes could be the first control token tracking value (ctATV), and the last byte could be the first function index value (fi). As a numerical example, the first current token tracking value, the first control token tracking value, and the first function index value can be represented as 793489673.

[0129] At step 460, after receiving the authorization request message from the resource provider computer 406, the transmission computer 408 may forward the authorization request message to the network processing computer 410.

[0130] At step 462, after receiving an authorization request message from the transmission computer 408 that includes at least a first current token tracking value and a first function index value, the network processing computer 410 can parse the data in the authorization request message. For example, the authorization request message may include a first current token tracking value, a first control token tracking value, and a first function index value (e.g., tATV|ctATV|fi). The network processing computer 410 can parse the data to obtain the first current token tracking value, the first control token tracking value, and the first function index value.

[0131] Network processing computer 410 can determine the second function index value. Network processing computer 410 can determine the second function index value in any suitable manner, as described in detail herein. For example, network processing computer 410 can determine the second function index value in the same manner as token requester computer 404 determines the first function index value, and this will not be repeated here. For example, network processing computer 410 can determine that the second function index value is equal to the value 1.

[0132] The network processing computer 410 can compare the first function index value with the second function index value. For example, the network processing computer 410 can determine whether the first function index value and the second function index value match. In this case, the first function index value is equal to the value 1.

[0133] If the first function index value matches the second function index value, the network processing computer 410 can safely determine that the received first function index value is valid.

[0134] If the first function index value does not match the second function index value, the network processing computer 410 can perform additional processing to determine whether the first function index value is being received as part of a replay attack. For example, the network processing computer 410 can determine whether (e.g., received) the first function index value is equal to 9 and whether (e.g., calculated by the network processing computer 410) the second function index value is equal to 0. In this case, the value may have cycled back from the value 9 to the value 0 (through modular arithmetic). For example, sufficient time may have elapsed between 1) the token requester computer 404 determining the first function index value and 2) the network processing computer 410 determining the second function index value, such that the time interval has increased sufficiently for the value to change. In this case, the network processing computer 410 can determine that the time is at a boundary, and then change the second function index value to be equal to the first function index value, and then proceed to step 464.

[0135] If the absolute difference between the first function index value and the second function index value is greater than 1 (e.g., more than 100 seconds have passed), the network processing computer 410 can determine that the received first function index value may be part of a replay attack because the time difference between the received function index values ​​exceeds a threshold amount of 100 seconds (as determined by a predetermined number of bits of the aforementioned period). The network processing computer 410 can generate a new control token tracking value to reset the chain of control token tracking values ​​and the current token tracking value. In some embodiments, the network processing computer 410 can pre-provision the new control token tracking value to the token requester computer 404. In other embodiments, the network processing computer 410 can also generate a fraud alert and provide the fraud alert to, for example, Figure 1Any suitable entity and / or computer. Furthermore, network processing computer 410 can reject the current interaction. For example, network processing computer 410 can generate an authorization response message indicating that the interaction has been rejected. Network processing computer 410 can then provide the authorization response message to resource provider computer 406 via transport computer 408.

[0136] At step 464, in some embodiments, if the first function index value matches the second function index value, the network processing computer 410 can retrieve the function table from the token service computer 412. For example, the token service computer 412 can retrieve the function table from the token pre-provisioning (e.g., as...). Figure 3 During this period, a function table associated with the user and / or user device 402 is stored. In some embodiments, the network processing computer 410 may provide a token to the token service computer 412.

[0137] At step 466, after receiving a request for a function table, the token service computer 412 may provide the function table to the network processing computer 410. For example, the token service computer 412 may determine which function table to provide to the network processing computer 410 based on which function table is associated with the received token. In some embodiments, the token service computer 412 may further determine the credentials (e.g., PAN) associated with the token. The token service computer 412 may provide the credentials (e.g., user credentials) to the network processing computer 410. For example, when an authorization request message is provided to the authorization entity computer 414, the network processing computer 410 may later replace the token with the user credentials from the authorization request message, as described in further detail herein.

[0138] At step 468, after retrieving the function table associated with the token, the network processing computer 410 can determine a function based on the first function index value and the stored function table. For example, the first function index value can indicate to the network processing computer 410 which function in the function table to use to determine the second current token tracking value (e.g., the second token tracking value). The network processing computer 410 can also retrieve a stored control token tracking value (e.g., the second control token tracking value). The second control token tracking value can be entered into a function. As an example, the first function index value has a value equal to 1. The network processing computer 410 can determine the function associated with index 1. For example, the function could be tATV = truncate4(ctATV*2).

[0139] After determining the functions to be used in the function table, the network processing computer 410 can determine the second current token trace value based on the functions. For example, the network processing computer 410 can input the second control token trace value into the function tATV = truncate4(tATV * 2). For example, the second control token trace value can be equal to the value 8967. The network processing computer 410 can determine the second current token trace value (TATV) as 7934 = truncate4(8967 * 2).

[0140] Network processing computer 410 can compare a first current token tracking value with a second current token tracking value. If the first current token tracking value is not equal to the second current token tracking value, network processing computer 410 can determine that the received first current token tracking value is part of a replay attack or other fraudulent attempt. In this case, network processing computer 410 can then generate a new control token tracking value, which can be provisioned to token requester computer 404. Network processing computer 410 can further deny authorization for the current interaction. For example, network processing computer 410 can generate an authorization response message indicating that the interaction is not authorized, as described herein.

[0141] If the first current token trace value is equal to the second current token trace value, the network processing computer 410 can determine that the received current token trace value is verified. However, in some embodiments, the network processing computer 410 can perform additional verification techniques to further determine whether the received first current token trace value is part of a replay attack or other fraudulent attempt.

[0142] For example, network processing computer 410 can determine whether a (received) first current token tracking value is equal to a second control token tracking value (e.g., retrieved from a token store). If the first current token tracking value matches the second control token tracking value, network processing computer 410 can determine that the received first current token tracking value is part of a replay attack. This would happen if a malicious party attempted to steal a token and the first current token tracking value, and subsequently provided the token and the first current token tracking value in an authorization request message. Network processing computer 410 can determine this is a replay attack because the first current token tracking value stolen by the malicious party was not updated using the function table (as described above). This is why a malicious party would attempt a replay attack if the received current token tracking value is the same as the stored second current token tracking value.

[0143] Furthermore, in some embodiments, the network processing computer 410 may compare a first control token tracking value with a second control token tracking value. If the first control token tracking value and the second control token tracking value do not match, the network processing computer 410 may determine whether the first current token tracking value is out of sequence. The network processing computer 410 may then send a current token tracking value request message to the token requester computer 404. For example, the current token tracking value request message may include a request for a new current token tracking value.

[0144] If the first control token trace value matches the second control token trace value, the network processing computer 410 may store the first current token trace value as a subsequently stored control token trace value in the token service computer 412. In some embodiments, the subsequently stored control token trace value may be used during subsequent request messages.

[0145] If the first control token tracking value matches the second control token tracking value, the network processing computer 410 may generate a response message in response to the comparison. The response message may include, for example, a modified authorization request message, which may be forwarded to the authorization entity computer 414 in step 470 below. In some embodiments, the network processing computer 410 may modify the authorization request message to include at least user credentials (e.g., PAN) that can be received from the token service computer 412 at step 466.

[0146] At step 470, after determining that the token originates from a valid party (e.g., the user of user device 402), network processing computer 410 may transmit the authorization request message to authorization entity computer 414.

[0147] At step 472, after receiving the authorization request message, the authorization entity computer 414 can determine whether to authorize the interaction between the user of user device 402 and the resource provider computer 406. The authorization entity computer 414 can generate an authorization response message, including user credentials and an indication of whether the interaction is authorized.

[0148] At step 474, after determining whether to authorize the interaction, the authorizing entity computer 414 may transmit an authorization response message to the network processing computer 410.

[0149] At step 476, after receiving the authorization response message from the authorizing entity computer 414, the network processing computer 410 may transmit the authorization response message to the transport computer 408. In some embodiments, the network processing computer 410 may request a token associated with user credentials from the token service computer 412. Upon receiving user credentials, the network processing computer 410 may modify the authorization response message to include at least the token and an indication of whether the interaction is authorized.

[0150] At step 478, after receiving the authorization response message from the network processing computer 410, the transmission computer 408 may transmit the authorization response message to the resource provider computer 406.

[0151] At step 480, after receiving the authorization response message from the transmission computer 408, the resource provider computer 406 may transmit the authorization response message to the token requester computer 404. In some embodiments, the resource provider computer 406 may directly provide the authorization response message to the user device 402.

[0152] At step 482, after receiving the authorization response message from resource provider computer 406, token requester computer 404 may transmit the authorization response message to user device 402. If the authorization response message includes an indication that the interaction is authorized, the user of user device 402 and the resource provider of resource provider computer 406 may continue to interact.

[0153] D. Verification Example

[0154] Figure 4 Steps 462-468 illustrate the verification performed by the network processing computer 410 on the current token trace value. The following pseudocode illustrates an example procedure that can be performed by the network processing computer 410 using the current token trace value. Table 4 below includes a diagram of the variables corresponding to the pseudocode.

[0155] variable meaning (m) Received message data (v) Data from tokenstore (c) Calculated data fi Function index value tATV Current token tracking value ctATV Control token tracking value

[0156] Table 4: Pseudocode illustrations

[0157] Upon receiving the request message described herein, the network processing computer can extract the hundreds digit from the current period time, set fi(c), and evaluate the time limit conditions:

[0158]

[0159]

[0160] The network processing computer can use the computed function index fi(c) to extract the JSON function model (e.g., a function from a function table). The network processing computer can then parse the function model and use ctATV(v) to compute tATV(c).

[0161] tATV(c)=f(ctATV(v))

[0162] The network processing computer can compare the calculated tATV(c) with the message tATV(m).

[0163]

[0164]

[0165]

[0166] generate_ctATV(): This method generates a new ctATV.

[0167] generate_token_tATV_alert():

[0168] The `generate_token_tATV_alert()` method allows the network processing computer to create an alert message and send it to the token requester's computer. In some embodiments, the alert can use a new control token tracking value, `ctATV`. The alert may also include a reason for the alert. The reason for the alert can be, for example, "FRAUD", "REPLAY_ATTACK", "OUT_OF_SEQUENCE", etc.

[0169] E. Safe location access

[0170] Figure 5 A flowchart illustrating a secure location access process according to an embodiment is shown. Figure 5 The method illustrated is described in the context of a user requesting access to a secure location (e.g., a locked building). However, it should be understood that the invention can be applied to other situations (e.g., a user requesting access to a secure webpage, etc.).

[0171] At step 550, user device 502 may transmit a request for access to a secure location of token requester computer 504. The request may include a request from token requester computer 504 on behalf of user device 502 to provide a token to network processing computer 504. For example, the interaction may include a user request from user device 502 to access a secure building.

[0172] At step 552, after receiving a request from user device 502, token requester computer 504 may determine a first function index value. Token requester computer 504 may determine the first function index value in any suitable manner described herein. For example, in some embodiments, token requester computer 504 may determine the first function index value based on the current time (e.g., the hundreds digit of the current period time). After determining the first function index value, token requester computer 504 may determine a first current token tracking value. Furthermore, token requester computer 504 may retrieve a first control token tracking value from secure storage. The first control token tracking value may be during provisioning, for example, in... Figure 3 The control token trace value received at step 5. The token requester computer 504 can generate a first current token trace value based on the control token trace value.

[0173] At step 554, the token requester computer 504 may generate an authorization request message and transmit it to the network processing computer 506. The authorization request message includes a token, a first function index value, a first current token tracking value, and a first control token tracking value.

[0174] At step 556, after receiving the authorization request message, the network processing computer 506 can determine whether the received current token tracking value is valid. For example, the network processing computer 506 can perform... Figure 4 Step 462. Steps 558-562 can be similar to... Figure 4 Steps 464-468 ​​will not be repeated here.

[0175] At step 564, network processing computer 506 may transmit an authorization request message to authorization entity computer 510. The authorization request message may include user credentials and / or tokens. In some embodiments, the authorization request message may also include a building identifier capable of identifying the building the user is requesting access to.

[0176] At step 566, after receiving the authorization request message, the authorization entity computer 510 may determine whether to authorize the user to access the secure location associated with the building identifier. For example, the authorization entity computer 510 may verify that the user associated with the user credentials and / or token is included in the stored user list associated with the building identifier. After determining whether to authorize the user to access the secure location, the authorization entity computer 510 may generate an authorization response message and transmit it to the network processing computer. The authorization response message includes any suitable data as described in detail herein.

[0177] At step 568, after receiving the authorization response message, the network processing computer 506 may transmit the authorization response message to the token requester computer 504. In some embodiments, if the authorization response message includes user credentials, the network processing computer 506 may, in conjunction with the token service computer 508, replace the user credentials with a token associated with the user.

[0178] At step 570, after receiving the authorization response message, the token requester computer 504 may provide the user device 502 with an authorization response message, or an indication stored in the token requester computer indicating whether the interaction is authorized. Furthermore, the user of user device 502 can be granted or denied access to a secure location based on the indication of whether the interaction is authorized.

[0179] The embodiments of this disclosure have many advantages. For example, the embodiments make it difficult for a malicious party to use stolen tokens (e.g., in a replay attack). In order to use a stolen token, a malicious party needs to know the functions used to generate the associated current token tracking value and previous token tracking values ​​(e.g., control token tracking values).

[0180] The embodiments offer several additional advantages. For example, the process does not require the use of resource re-encryption procedures or cryptographic keys to verify data presented during the interaction, thereby reducing processing power requirements and total interaction time, and enabling users to receive indications of whether the interaction is authorized more quickly.

[0181] Although the steps in the flowcharts and process flows above are shown or described in a specific order, it should be understood that embodiments of the invention may include methods with steps in a different order. Furthermore, steps may be omitted or added, and they may still be present in embodiments of the invention.

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

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

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

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

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

Claims

1. A method for preventing token authentication replay attacks, the method comprising: The server computer receives a request message from a token requester computer representing the user device. The request message includes a first current token tracking value and a first function index value associated with a function. The request message is an authorization request message received during an interaction between the user device and the resource provider computer. The first function index value is a value based on the current time. The server computer determines a second function index value, wherein the second function index value is a value based on a second current time; The server computer compares the first function index value with the second function index value; If the first function index value matches the second function index value, the server computer determines the function based on the first function index value and a stored function table associated with the user device. The server computer determines the second current token tracking value based on the function; The server computer compares the first current token tracking value with the second current token tracking value; The server computer generates a response message in response to the comparison; Authorize transactions with the resource provider's computer; as well as The server computer sends the response message to the resource provider computer, wherein the response message includes an indication of whether the interaction is authorized.

2. The method of claim 1, wherein determining the function based on the first function index value and the stored function table associated with the user device further comprises: The server computer retrieves the stored control token tracking value from the token service computer; as well as The function is determined by the server computer based on the first function index value, the stored function table associated with the user device, and the stored control token tracking value.

3. The method of claim 2, wherein the request message further includes a first control token tracking value, wherein the stored control token tracking value is a second control token tracking value, and wherein the method further includes: If the first current token tracking value matches the second current token tracking value, the server computer compares the first control token tracking value with the second control token tracking value.

4. The method according to claim 3, further comprising: If the first control token tracking value matches the second control token tracking value, the server computer stores the first current token tracking value as a subsequent stored control token tracking value in the token service computer.

5. The method of claim 4, wherein the subsequently stored control token trace value is used during a subsequent request message.

6. The method of claim 3, further comprising: If the first control token tracking value does not match the second control token tracking value, the server computer determines that the first current token tracking value is out of order. as well as The server computer transmits a token tracking value request message to the token requester computer, the token tracking value request message including a request for a new current token tracking value.

7. The method according to claim 3, further comprising: The server computer compares the first current token tracking value with the second control token tracking value; If the first current token tracking value matches the second control token tracking value, the server computer determines that the user device is a malicious user device. The server computer generates a replacement control token tracking value; The server computer stores the replacement control token tracking value in the token service computer; as well as The server computer generates a replay attack alert message that includes at least the replacement control token tracking value.

8. The method of claim 7, wherein the request message is received during an interaction between a user of the user device and a resource provider, and wherein after determining that the user device is the malicious user device performing the replay attack, the method further comprises: The server computer generates an authorization response message, which includes an indication that the interaction was not authorized.

9. The method of claim 1, wherein determining the second function index value further comprises: The server computer determines the index value of the second function based on the number of bits of the current time.

10. The method of claim 1, wherein the response message is a modified authorization request message, and the method further comprises: The server computer transmits the modified authorization request message to the authorization entity computer, wherein the authorization entity computer determines whether to authorize the interaction.

11. A server computer, comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to implement a method comprising: A request message is received from a token requester computer representing a user device. The request message includes a first current token tracking value and a first function index value associated with a function. The request message is an authorization request message received during an interaction between the user device and the resource provider computer. The first function index value is a value based on the current time. Determine a second function index value, wherein the second function index value is a value based on a second current time; Compare the first function index value with the second function index value; If the first function index value matches the second function index value, then the function is determined based on the first function index value and the stored function table associated with the user device; The second current token tracking value is determined based on the function; Compare the first current token tracking value with the second current token tracking value; A response message is generated in response to the comparison; Authorization of transactions with the resource provider's computer; and The server computer sends the response message to the resource provider computer, wherein the response message includes an indication of whether the interaction is authorized.

12. The server computer of claim 11, wherein the computer-readable medium further comprises: Function table module; Function index value module; as well as Token tracking value module.

13. The server computer of claim 11, wherein the server computer is a network processing computer.

14. The server computer of claim 11, wherein the response message is a modified authorization request message, and wherein the method further comprises: The modified authorization request message is transmitted to the authorization entity computer, wherein the authorization entity computer determines whether to authorize the interaction. as well as Receive an authorization response message from the authorized entity computer, wherein the authorization response message includes at least an indication of whether the interaction is authorized.

15. The server computer of claim 14, wherein the method further comprises: The authorization response message is transmitted to the token requester's computer via a transmission computer and a resource provider computer associated with the resource provider.

16. The server computer of claim 15, wherein the authorization request message further includes a first control token tracking value and a token associated with the user.

17. The server computer of claim 16, wherein determining the function based on the first function index value and the stored function table associated with the user device further comprises: Retrieve the second control token tracking value from the token service computer; as well as The function is determined based on the first function index value, the stored function table associated with the user device, and the second control token tracking value.

18. The server computer of claim 17, wherein the method further comprises: Provide the token to the token service computer; as well as Receive user credentials associated with the token from the token service computer.

19. The server computer of claim 18, wherein the modified authorization request includes the user credentials.

20. The server computer of claim 11, wherein determining the second function index value further comprises: The index value of the second function is determined based on the hundreds digit of the current time.

Images