Systems and methods for preventing relay attacks

Abstract

Systems, methods, and apparatus for preventing relay attacks are disclosed. A user device can receive device identification data for a first access device from an intervention device (e.g., when approaching the first access device). Messages can be received from a second access device via the intervention device. The messages may include a digital signature generated at least in part based on the second access device identification data. The user device can verify the message using the digital signature and a public key. If the message is invalid, the user device can discard the message. If the message is valid (e.g., unchanged), the user device can determine that the user has not confirmed their intention to interact with the second access device and therefore can terminate further interaction with the second access device.

Description

[0001] This application is a divisional application of the invention patent application entitled "System and Method for Preventing Relay Attacks", filed on November 28, 2018, with international application number PCT / US2018 / 062759 and Chinese national phase application number 201880076718.5.

[0002] This application claims priority to U.S. Provisional Application No. 62 / 591,708, filed November 28, 2017, the disclosure of which is incorporated herein by reference in its entirety for all purposes. Background Technology

[0003] Relay attacks are possible in contactless access transactions, such as payment transactions between contactless devices and contactless terminals. For example, an attacker (e.g., one or more people working together to steal information or defraud legitimate users) can use two wirelessly-enabled mobile devices and two mobile applications on those devices to carry out a relay attack. In a typical relay attack, the attacker uses a first mobile device with a first mobile application to tap and communicate with a contactless device in the victim's pocket. The attacker can then use a second mobile device with a second mobile application to tap and communicate with a contactless terminal, for example, at a merchant or other resource provider.

[0004] Command messages originating from the contactless terminal are relayed from the second mobile device to the first mobile device and subsequently received by the victim's contactless device. The victim's contactless device then responds to the command message. Access information on the device (e.g., payment information such as a master account (PAN)) can then be relayed from the first mobile device to the second mobile device and then to the contactless terminal. By performing this relay attack, an attacker can use the victim's contactless device to perform access transactions (e.g., purchase transactions) without gaining control of the victim's device. While this particular example involves a merchant, it should be understood that this problem can exist in other situations where access to resources is desired (e.g., attempts to enter a building or attempts to access data inside a computer).

[0005] Mobile transactions using Bluetooth Low Energy (BLE) to communicate between contactless devices and contactless terminals typically occur in very close proximity between the device and the terminal. However, these transactions remain vulnerable to relay attacks.

[0006] The embodiments described herein individually and collectively address these problems. Summary of the Invention

[0007] One embodiment of this disclosure relates to a method. The method may include receiving first access device identification data for a first access device from an intervention device by a user device. The method may also include receiving a message from a second access device via the intervention device by a user device approaching the first access device. In some embodiments, the message may include message data including at least second access device identification data and a digital signature generated by signing a hash of the at least second access device identification data with the private key of a public / private key pair associated with the second access device. The method may also include obtaining the hash from the digital signature using the public key. The method may also include generating an additional hash of the message data. The method may also include comparing the hash with the additional hash by the user device. The method may also include determining whether the hash matches the additional hash by the user device. The method may also include automatically terminating any further interaction with the second access device by the user device when the hash does not match the additional hash. The method may also include, when the hash matches the additional hash: determining that the user of the user device has not confirmed an intention to interact with the second access device, and terminating any further interaction with the second access device at least in part based on the determination that the user has not confirmed an intention to interact with the second access device.

[0008] Another embodiment of this disclosure is directed to a user device. In some embodiments, the user device may include a processor and a non-transient computer-readable medium. In some embodiments, the computer-readable medium may include code executable by a processor to implement any of the methods described herein.

[0009] Another embodiment of this disclosure is directed to a system. The system may include at least one user device and at least one access device. In some embodiments, the user device and / or access device may include a processor and a non-transient computer-readable medium. In some embodiments, the computer-readable medium may include code executable by a processor to implement any of the methods described herein. Attached Figure Description

[0010] Figure 1 This is a block diagram illustrating an exemplary relay attack according to some embodiments.

[0011] Figure 2 An exemplary user interface for establishing a connection to an access device is shown according to some embodiments.

[0012] Figure 3 An exemplary user interface for confirming interaction with an access device is shown according to some embodiments.

[0013] Figure 4A block diagram illustrating an exemplary method for preventing relay attacks, according to some embodiments, is shown.

[0014] Figure 5 The diagram illustrates an exemplary method for generating a digital signature according to some embodiments.

[0015] Figure 6 A block diagram illustrating another exemplary method for preventing relay attacks, according to some embodiments, is shown.

[0016] Figure 7 A block diagram illustrating yet another exemplary method for preventing relay attacks, according to some embodiments, is shown.

[0017] Figure 8 A block diagram illustrating yet another exemplary method for preventing relay attacks, according to some embodiments, is shown.

[0018] Figure 9 A block diagram illustrating yet another exemplary method for preventing relay attacks, according to some embodiments, is shown.

[0019] Figure 10 A block diagram of an exemplary user device according to an embodiment of the present invention is shown.

[0020] Figure 11 A block diagram of an exemplary access device according to an embodiment of the present invention is shown.

[0021] Figure 12 A block diagram of the transaction processing system is shown.

[0022] Figure 13 A block diagram of the building access system is shown. Detailed Implementation

[0023] Bluetooth Low Energy (BLE) is a communication technology available in most modern smartphones. BLE technology is already used in mobile payments. A key feature that makes BLE potentially attractive for low-friction interaction is the ease with which connections can be established between devices (e.g., access devices and users' phones). For example, when connecting one device to another, there is no need to exchange PINs or passwords as is the case with traditional Bluetooth.

[0024] However, the widespread availability of BLE capabilities in user devices and the ease of establishing BLE connections between user devices and access devices have unduly fueled the desire of fraudsters to develop mobile applications that can emulate BLE access devices. Without protection at the application protocol level, fraudsters can potentially execute relay attacks. For example, a fraudster can impersonate an access device that a user device is attempting to interact with, and can persuade the user to connect to the fraudulent device instead of the actual access device. Instead of communicating with the local, legitimate access device, the fraudster can establish a communication channel extending to an accomplice at the remote access device, and, together with the fraudster's device, manipulate the communication protocol to unintentionally make the user interact with the remote access device instead of the access device the user desires.

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

[0026] "User equipment" can include any suitable electronic device that a user can transport and operate, and which may also provide the ability to communicate remotely with a network. Examples of remote communication capabilities include the use of mobile phone (wireless) networks. Bluetooth Low (BLE), 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 a private network. Examples of user devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptop computers, personal music players, handheld dedicated readers, etc. Other examples of user devices include wearable devices such as smartwatches, fitness trackers, ankle bracelets, rings, earrings, etc., and automobiles with telematics capabilities. User devices may include any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., two connected devices may be considered a single user device when the devices share access to the network via a network—that is, the other device is used as a modem).

[0027] "Interaction data" may include any suitable information associated with the interaction between the access device and the user device. Interaction data may include any suitable data associated with the interaction (e.g., BLE advertising messages, purchases and / or pre-authorization transactions, etc.). In some embodiments, interaction data may include any suitable combination of: identification data associated with the access device (e.g., one or more identifiers of the access device), identification information associated with the user device (e.g., one or more identifiers associated with the user device), interaction values ​​(e.g., transaction amounts, such as pre-authorization amounts and / or purchase prices), payment data (e.g., payment account identifiers associated with payment accounts), one or more locations each associated with the access device and / or user device, or any suitable information. Instances of payment data may include PAN (primary account or "account"), username, expiration date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, etc. CVV2 is generally understood to be a static verification value associated with the payment device. CVV2 values ​​are typically visible to users (e.g., consumers), while CVV and dCVV values ​​are usually embedded in memory or authorization request messages and are not easily known to users (although they are known to the issuer and payment processor). Payment data can be any information that identifies a payment account or is associated with a payment account. Payment data can be provided to enable payment from a payment account. Payment data may also include username, expiration date, gift card number or code, and any other suitable information.

[0028] An "application" can be computer code or other data stored on a computer-readable medium (e.g., a memory element or a secure element) that can be executed by a processor to perform a task.

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

[0030] 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, access devices, secure data access points, etc. A "merchant" can typically be an entity that participates in transactions and can sell goods or services or provide access to goods or services.

[0031] An "acquiring party" can typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform the functions of both an issuer and an acquirer. Some embodiments may cover such a single entity as an issuer-acquiring party. The acquiring party can operate an acquiring party computer, which may also be generally referred to as a "transfer computer".

[0032] "Authorizing entity" can be the entity that makes the authorization request. Instances of authorizing entities can be issuers, government agencies, document repositories, access administrators, etc. "Issuer" typically refers to a commercial entity that maintains a user's account (e.g., a bank). Issuers may also issue payment credentials to consumers that are stored on user devices such as cellular phones, smart cards, tablets, or laptops.

[0033] An "access device" can be any suitable device that provides access to a remote system. Access devices can also be used to communicate with user devices, resource provider computers, network processing computers, authorizing entity computers, and / or any other suitable systems. Access devices can generally be located in any suitable location, such as at a merchant's location, or, as another example, at the entrance of a building. Access devices can take any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), 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, and so on. Access devices can use any suitable contact or contactless operating mode to send or receive data to or from user devices, or associate with user devices. In some embodiments, access devices can be configured to be at least partially based on, for example... The access device communicates with the user device using short-range communication protocols such as BLE. In some embodiments, the access device may also be configured to communicate with a resource provider computer, a processing network computer, an authorization entity computer, and / or any other suitable system using any suitable wired and / or wireless network. In some embodiments where the access device may include a POS terminal, any suitable POS terminal may be used, and it may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless operating mode. For example, exemplary readers may include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with payment devices and / or mobile devices. In some embodiments, a cellular phone, tablet computer, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or “mPOS” terminal.

[0034] An "authorization request message" can be an electronic message requesting authorization for a transaction. In some embodiments, the authorization request message is sent to the transaction processing computer and / or the issuer of the payment card to request transaction authorization. Authorization request messages according to some embodiments may conform to ISO 8583, a standard for systems exchanging information about 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 the 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, CVV (card verification value), dCVV (dynamic card verification value), PAN (primary account number or "account number"), payment token, username, expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction amount, 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 the transaction is identified and / or authorized.

[0035] An "authorization response message" can be a message responding to an authorization request. In some cases, an authorization response message can be an electronic message response to an authorization request message generated by the issuing financial institution or a transaction processing computer. An authorization response message can include (by way of example only) one or more of the following status indicators: Approval - the transaction is approved; Rejection - the transaction is not approved; or Call Center - the response is to wait for more information, and the merchant must call the toll-free authorization number. An authorization response message may also include an authorization code, which can be a code 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 the transaction processing computer), indicating that the transaction has been approved. The code can serve as evidence of authorization. As described above, in some embodiments, the transaction processing computer can generate or forward authorization response messages to the merchant.

[0036] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers operating like cells. In one instance, a server computer can be a database server coupled to a web server. A server computer can be coupled to a database and can include any hardware, software, other logic, or combination of the foregoing for serving requests from one or more client computers. 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.

[0037] Figure 1This is a block diagram 100 illustrating an exemplary relay attack according to some embodiments. Figure 1 The examples depicted illustrate how fraudsters can use relay attacks to compromise the interaction between user device 102 and access device 104-1. Figure 1 Includes user device 102, access device 104-1, access device 104-2, intervention device 106-1, and intervention device 106-2, but in other embodiments any suitable number and / or type of device may be used. As a non-limiting example, access devices 104-1 and 104-2 may each be located at a separate fuel pump unit in one or more gas stations (and / or operate as part of the respective fuel pump unit).

[0038] In step 1, access device 104-1 (e.g., located at pump 1 in a gas station "SuperGas") can transmit an advertising message (e.g., via a short-range wireless protocol such as BLE). The advertising message may include at least identification data associated with access device 104-1. The identification data can be in any form. For example, the identification data may include an identifier of the resource provider (e.g., a merchant, such as "SuperGas", "SuperGas at 4"). th and Broadway, Seattle, WA. or similar). In some embodiments, the identification data associated with access device 104-1 may also include a device identifier (e.g., "Pump 1"). User device 102 may approach access device 104-1 to break a threshold distance from access device 104-1 (e.g., within range of receiving short-range wireless messages of short-range wireless communication protocols such as BLE).

[0039] In step 2, the intervention device 106-1 operated by the first fraudster can intercept the advertising message and relay the message to the user device 102. In some embodiments, the intervention device 106-1 can change the advertising message (e.g., identification data) before relaying the message to the user device 102, while in other embodiments, the intervention device 106-1 can keep the advertising message unchanged.

[0040] In step 3, user device 102 may receive advertising messages and display one or more user interfaces for confirming connection with access device 104-1. For example, user device 102 may present... Figure 2 The user interface. Figure 2 An exemplary user interface 200 for establishing a connection with an access device having BLE functionality, according to some embodiments, is shown. Figure 2 As depicted, the user interface 200 may include text 202. In some embodiments, the text 202 may indicate an intent to connect to a particular access device. As a non-limiting example, the text 202 may include...Figure 1 Step 3 receives a portion of the identification data. As depicted, text 202 may indicate that the user wishes to establish a connection with access device 1 and terminal 1. Figure 1 In the example provided, user interface 200 may include text 202 indicating that the user wishes to establish a connection with "SuperGas, Pump 1". User interface 200 may include a confirm button 204 and / or a cancel button 206. When the confirm button 204 is selected (or any suitable user interface element configured to be associated with confirmation of the intent indicated by the text 202), user device 102 is configured to perform further operations. Specific user interface elements and / or formats of user interface 200 may vary.

[0041] Return to Figure 1 Upon presenting the user interface 200 and receiving an indication that the user has confirmed their intention to establish a connection with "SuperGas, Pump 1", a connection can be established between the intervention device 106-1 and the user device 102 using any suitable short-range wireless protocol (e.g., BLE). Therefore, based on the relay message in step 2, a fraudster can establish a BLE connection between the first fraudulent contactless device (intervention device 106-1) and the user device 102. The user of user device 102 can trust (e.g., based on...) Figure 2 The text 202 provided in the user interface 200 indicates that they are connected to access device 104-1. However, user device 102 may actually be connected to the fraudster's device (e.g., intervention device 106-1).

[0042] Once the connection between the intervention device 106-1 and the user device 102 is established, the intervention device 106-1 can connect (or additionally transmit data) to a second fraudulent device of the accomplice (e.g., intervention device 106-2) via any suitable wired and / or wireless connection in step 4. The intervention device 106-2 may be located, for example, at another access device (e.g., at "Pump 4" in another gas station "OtherGas"). The intervention device 106-2 can connect (or additionally transmit data) to the access device 104-2 via a second BLE connection in step 5.

[0043] In this fraudulent transaction flow, intervention device 106-2 can receive interactive data from access device 104-2 (e.g., identification information associated with access device 104-2, such as an interactive value for a pre-authorized amount). Intervention device 106-2 can relay the received interactive data to intervention device 106-1 in step 7.

[0044] In some attacks, intervention device 106-1 (and / or intervention device 106-2) can alter the interaction data provided by access device 104-2. As a non-limiting example, intervention device 106-1 can change the identification data to indicate that the interaction data is provided by access device 104-1 instead of access device 104-2. More specifically, intervention devices 106-1 and / or 106-2 can change the interaction data associated with “OtherGas, Pump 4” to “SuperGas, Pump 1”. This altered interaction data can be relayed to user device 102 in step 9. Receiving this altered interaction data can allow user device 102 to present another user interface (e.g., ...). Figure 3 The user interface 300 is used to confirm the interaction between the user device 104 and the intervention device 106-1, which is called the access device 104-1. Figure 3 An exemplary user interface 300 for confirming interaction with an access device having BLE functionality, according to some embodiments, is shown. As a non-limiting example, the user interface 300 may include text 302, such as... Figure 3 The instructions described herein will interact with "Access Device 1, Terminal 1". Figure 1 In an ongoing instance, text 302 may indicate that an interaction will occur with access device 104-1 (e.g., "Continue pre-authorization of $99 at SuperGas pump 1"). It should be understood that text 302 may include any suitable portion of the interaction data provided by access device 104-2 and / or modified by intervention devices 106-1 and / or 106-2.

[0045] In some embodiments, the user interface 300 may be configured to receive biometric information using any suitable biometric input device of the user device 102. For example, a user may indicate an intention to perform an interaction (e.g., pre-authorization) by scanning his fingerprint at the user device 102 via a fingerprint reader. Any suitable mechanism for indicating an intention to perform an interaction (e.g., via a similar mechanism) may be utilized. Figure 2 A similar button to the confirmation button 204 is provided via another suitable biometric input device (e.g., a camera, retinal reader, and iris scanner). In some embodiments, the user interface 300 may also include a cancel button 304 or a similar interface element to indicate that the user does not intend to perform the interaction indicated in the text 302.

[0046] Return to Figure 1In a case where the intervening device 106-1 has previously presented itself as "SuperGas, Pump 1" to the user device 102, the user may be misled into believing that their user device 102 is interacting with the access device 104-1 (e.g., the "SuperGas" pump located near the user device 102) to execute a transaction, when in fact it is actually interacting with the access device 104-2 ("OtherGas" pump) via intervening devices 106-1 and 106-2. Therefore, the user may be misled into believing that their user device 102 is interacting with the access device 104-2 ("OtherGas" pump) based on read... Figure 3 The text 302 suggests that the interaction is with the SuperGas pump 1 to indicate its intention to perform the interaction, but in fact, the user device 102 does not interact with the access device 104-1 at all.

[0047] Upon receiving an instruction from the user to perform an interaction, user device 102 can be configured to provide payment data in step 10. For example, an application operating on user device 102 can generate chip data, which is relayed to intervention device 106-2 via intervention device 106-1 in step 11. In step 12, intervention device 106-2 provides the payment data to access device 104-2.

[0048] This allows accomplices of the fraudster (e.g., operating intervention device 106-2) to fill their own tanks, potentially in much larger quantities than the legitimate user would expect. In a simple relay attack scenario, the legitimate user might not even have the opportunity to fill their own tank. That is, intervention device 106-1 can simply terminate its BLE connection with user device 102 once it has obtained the data necessary to execute the fraudulent transaction.

[0049] It can be understood that there are many variations of this type of attack. The above description is merely one example. It is also understood that the provider of access device 104-1 (e.g., the merchant "SuperGas") is not colluding with the fraudsters. Regarding the provider of access device 104-2 (e.g., the merchant "OtherGas"), the intervention device 106-2 appears to be a legitimate user's device. Therefore, the provider of access device 104-2 also unintentionally becomes a party to the fraudulent transaction.

[0050] The relay attack described above is possible because there is no check that the access device the user believes they are interacting with is the same access device that the actual interaction is taking place with.

[0051] Figure 4 A block diagram illustrating an exemplary method 400 for preventing relay attacks is shown according to some embodiments. Figure 4This illustration shows a use case where an access device (e.g., access device 104-2) digitally signs transmitted data using a private key. The transmission may include a corresponding public key, such that if the access device modifies the data, user device 102 can verify the fact that the data has been modified by using the public key to verify the digital signature.

[0052] exist Figure 4 In the example depicted, user device 102 may be configured with encrypted data 402. In some embodiments, encrypted data 402 may include a certificate issued by a certificate authority (not depicted). In some embodiments, the certificate may be Europay, and (EMV) certificate. In some embodiments, the certificate may include a public key associated with user device 102, which is digitally signed by a certificate authority using a private key associated with the certificate authority. Encrypted data 402 may also include a private key associated with user device 104 (e.g., a private key associated with an authentication public key digitally signed by the certificate authority). Access devices 104-1 and 104-2 may each be configured to generate encrypted data 404 and 406, respectively. Each of encrypted data 404 and 406 may include an unauthenticated public / private key pair for each respective device. The public / private key pair may be an asymmetric key pair, such as Rivest, Shamir, and Adelman (RSA) keys, elliptic curve cryptography (ECC) keys, or keys for some other suitable encryption algorithm. In some embodiments, access devices 104-1 and 104-2 may be configured to generate a new public / private key pair for each potential interaction with a user device (e.g., user device 102). In other embodiments, access devices 104-1 and 104-2 may be configured to reuse the respective single public / private key pair to perform various interactions with multiple user devices.

[0053] In step 1, access device 104-1 (e.g., located at pump 1 in a gas station “SuperGas”) can transmit an advertising message (e.g., via a short-range wireless protocol such as BLE). The advertising message may include at least identification data associated with access device 104-1. For example, the identification data may include an identifier of a resource provider (e.g., a merchant, such as “SuperGas”). In some embodiments, the identification information associated with access device 104-1 may also include a device identifier (e.g., “pump 1”). User device 102 may approach access device 104-1 to break a threshold distance from access device 104-1 (e.g., within range of receiving short-range wireless messages via a short-range wireless communication protocol).

[0054] In step 2, the intervention device 106-1 operated by the first fraudster can intercept the advertising message and relay the message unchanged to the user device 102.

[0055] In step 3, user device 102 may receive advertising messages and display one or more user interfaces for confirming connection with access device 104-1. For example, user device 102 may present... Figure 2 The user interface.

[0056] Return to Figure 1 Upon presentation of user interface 200 and receipt of confirmation from the user that they wish to establish a connection with "SuperGas, Pump 1" (e.g., indication that confirmation button 204 has been selected), a connection can be established between intervention device 106-1 and user device 102 using any suitable short-range wireless protocol (e.g., BLE). The user of user device 102 can trust (e.g., based on...) Figure 2 The text 202 provided in the user interface 200 indicates that they are connected to access device 104-1. However, user device 102 may actually be connected to the fraudster's device (e.g., intervention device 106-1).

[0057] Once the connection between the intervention device 106-1 and the user device 102 is established, the intervention device 106-1 can connect (or additionally transmit data) to the accomplice's second fraudulent device (e.g., intervention device 106-2) via any suitable wired and / or wireless connection in step 4. The intervention device 106-2 may be located at, for example, another access device (e.g., an access device located at another gas station, "OtherGas"). The intervention device 106-2 can connect (or additionally transmit data) to the access device 104-2 via a second BLE connection in step 5.

[0058] In some embodiments, access device 104-2 may generate interactive data (e.g., including identification information associated with access device 104-2, such as an interactive value for a pre-authorized amount, etc.) for transmission. However, before transmitting the interactive data, access device 104-2 may be configured to generate a digital signature using at least a portion of the interactive data. Figure 5 A schematic diagram 500 illustrates an exemplary method for generating a digital signature according to some embodiments.

[0059] Schematic diagram 500 depicts message data 502. Message data 502 may include any suitable number of data fields corresponding to any suitable combination of data used to establish a connection and / or perform interactions between an access device and / or a user device. For example, message data 502 may include data field 502A. In some embodiments, data field 502A may include data related to the provider of the access device (e.g., a merchant, such as...).Figure 4 The message data 502 may additionally or alternatively include a data field 502B. In some embodiments, the data field 502B may include a device identifier (e.g., a serial number, a device specific to the provider, e.g., a device identifier associated with the "SuperGas" instance). Figure 4 The identifier associated with the instance of “pump 4”). In some embodiments, message data 502 may additionally or alternatively include data field 502C. In some embodiments, data field 502C may correspond to an interaction amount (e.g., pre-authorized amount, final purchase price, etc.). In some embodiments, message data 502 may additionally or alternatively include data field 502D. In some embodiments, data field 502D may correspond to a location (e.g., a location associated with an access device). In some embodiments, message data 502 may additionally or alternatively include data field 502E. In some embodiments, data field 502E may correspond to a public key (e.g., a public key associated with an access device). A digital signature 506 may be generated using any suitable combination of data fields 504, for example, by the access device. It should be understood that the order of message data 502 may differ between embodiments. Although not depicted, in some embodiments (e.g., for messages transmitted from a user device to an access device), the data fields may also include data fields for transmitting payment data.

[0060] In some embodiments, a digital signature 506 can be generated (e.g., by an access device) using any suitable portion of hash data field 504. For example, digital signature 506 can be generated by first providing data fields 502A and / or 502B as input to a hash algorithm to produce a hash value. The resulting hash value can then be input into a signing algorithm along with a private key (e.g., a private key associated with the access device) to generate digital signature 506. Digital signature 506 can be used, along with a public key corresponding to the private key, to verify that any data fields used to generate the digital signature have not been altered. As a non-limiting example, a receiver of message data 502 can retrieve the hash value from digital signature 506 using a public key (e.g., the public key provided in data field 502E). The receiver can then generate hashes from predetermined combinations of data fields 504 (e.g., data fields 502A and 502B) to generate additional hash values. The receiver can then compare the hash retrieved from digital signature 506 with the generated hash. If the two hash values ​​match, the receiver is assured that the message is valid (e.g., unchanged). If the two hash values ​​do not match, the receiver can determine that the message is invalid (e.g., altered due to the original transmission). It should be understood that in Figure 5The examples provided are illustrative and are not intended to limit the scope of this disclosure. In other embodiments, any suitable combination of data fields 504 (e.g., all data fields 504, more or fewer data fields than those already described above, etc.) can be used to generate a digital signature 506, which can then be used to determine whether such data has been altered upon receipt.

[0061] Return to Figure 4 Access device 104-2 can generate a digital signature in step 6 using at least a portion of the interactive data. For example, access device 104-2 can use identification data (e.g., merchant identifier, device identifier, etc.) of the interactive data to... Figure 5 The digital signature is generated in the manner described herein. In some embodiments, in addition to identification data, other interaction data (e.g., location, interaction value, etc.) may be used to generate the digital signature. Access device 104-2 may insert the digital signature and the public key corresponding to the private key used to generate the digital signature into the message and transmit the message to user device 102.

[0062] Intervention device 106-2 can receive a message from access device 104-2 in step 7 and relay the message to intervention device 106-1 in step 8.

[0063] Intervention device 106-1 (and / or intervention device 106-2) may modify the interaction data provided by access device 104-2. As a non-limiting example, intervention device 106-1 may modify identification data to indicate that the interaction data is provided by access device 104-1 instead of access device 104-2. More specifically, intervention devices 106-1 and / or 106-2 may change the interaction data associated with “OtherGas, Pump 4” to “SuperGas, Pump 1”. This modified interaction data may be relayed to user device 102 in step 9.

[0064] In step 10, user device 102 can be configured to verify the received message using a digital signature and public key associated with access device 104-2 received within the message. For example, the public key included in the received message can be used to extract the hash value of the digital signature included in the message. User device 102 can then verify the received message based on a predetermined set of data fields (e.g., ...). Figure 5 Additional hash values ​​are calculated for data fields 502A and 502B. User device 102 can then compare the extracted hash values ​​with the calculated hash values.

[0065] In step 11, since the hash value does not match due to data change, user device 102 can be configured to determine that the message is invalid (e.g., it has changed, or at least a predetermined set of data fields has changed) and terminate any further interaction with access device 104-2.

[0066] Figure 6 A block diagram illustrating another exemplary method 600 for preventing relay attacks is shown according to some embodiments. Figure 6 This illustrates a use case where an access device (e.g., access device 104-2) digitally signs data using its private key before transmission. The transmission may include a public key corresponding to the private key. If the data is not modified by the access device but is merely relayed, verification of the digital signature can be performed at user device 102. However, even if the message can be determined to be valid (e.g., unchanged), additional checks can be performed on at least some of the message's data (e.g., identification data indicating, for example, a merchant name / identifier). For instance, the identification data of a message from access device 104-2 can be compared with an identification received during the initial connection phase to ensure that the entity interacting with the user device is the same entity that user device 102 believes the connection to be approved.

[0067] exist Figure 6 In the examples described, such as Figure 4 In this example, user device 102 can be configured with encrypted data 402. As described above, relative to... Figure 4 As discussed, encrypted data 402 may include a certificate issued by a certificate authority (not depicted). Access devices 104-1 and 104-2 may each be configured to generate encrypted data 404 and 406, respectively, which may individually include an unauthenticated public / private key pair for each respective device.

[0068] Steps 1-10 of method 600 can be combined as described above. Figure 4 Steps 1-10 of the described method 400 are performed in a similar manner.

[0069] In step 1, access device 104-1 (e.g., located at pump 1 in a gas station “SuperGas”) can transmit an advertising message (e.g., via a short-range wireless protocol such as BLE). The advertising message may include at least identification data associated with access device 104-1. For example, the identification data may include an identifier of a resource provider (e.g., a merchant, such as “SuperGas”). In some embodiments, the identification data associated with access device 104-1 may also include a device identifier (e.g., “Pump 1”). User device 102 may approach access device 104-1 to break a threshold distance from access device 104-1 (e.g., within range of receiving short-range wireless messages via a short-range wireless communication protocol).

[0070] In step 2, the intervention device 106-1 operated by the first fraudster can intercept the advertising message and relay the message unchanged to the user device 102.

[0071] In step 3, user device 102 may receive advertising messages and display one or more user interfaces for confirming connection with access device 104-1. For example, user device 102 may present... Figure 2 The user interface.

[0072] Upon presentation of user interface 200 and receipt of confirmation from the user that they wish to establish a connection with "SuperGas, Pump 1" (e.g., indication that confirmation button 204 has been selected), a connection can be established between intervention device 106-1 and user device 102 using any suitable short-range wireless protocol (e.g., BLE). The user of user device 102 can trust (e.g., based on...) Figure 2 The text 202 provided in the user interface 200 indicates that they are connected to access device 104-1. However, user device 102 may actually be connected to a fraudster's device (e.g., intervention device 106-1). In this embodiment, user device 102 may store at least a portion of the data received in the advertising message. For example, user device 102 may store identification data (e.g., "SuperGas") indicating the device that user device 102 is allegedly connected to.

[0073] Once the connection between the intervention device 106-1 and the user device 102 is established, the intervention device 106-1 can connect (or additionally transmit data) to the accomplice's second fraudulent device (e.g., intervention device 106-2) via any suitable wired and / or wireless connection in step 4. The intervention device 106-2 may be located at, for example, another access device (e.g., an access device located at another gas station, "OtherGas"). The intervention device 106-2 can connect (or additionally transmit data) to the access device 104-2 via a second BLE connection in step 5.

[0074] In some embodiments, access device 104-2 may generate interactive data (e.g., including identification information associated with access device 104-2, such as an interactive value for a pre-authorized amount, etc.) for transmission. However, before transmitting the interactive data, access device 104-2 may be configured to combine the above description with... Figure 4 and 5 The method described generates a digital signature using at least a portion of the interactive data.

[0075] In step 6, access device 104-2 can generate a digital signature using at least a portion of the interactive data. For example, access device 104-2 can... Figure 5 The method described herein utilizes identifier data from interactive data (e.g., merchant identifiers, device identifiers, etc.). Figure 5The access device 104-2 can insert a digital signature and a public key corresponding to the private key used to generate the digital signature into the message and transmit the message to the user device 102. (This can be done using any suitable combination of data fields 504, etc.)

[0076] Intervention device 106-2 may receive a message from access device 104-2 in step 7 and relay the message to intervention device 106-1 in step 8. Intervention device 106-1 (and / or intervention device 106-2) may relay the unchanged message to user device 102 in step 9. It should be understood that in ongoing instances, the message still indicates identification data corresponding to "OtherGas".

[0077] In step 10, user device 102 can be configured to verify the received message using a digital signature and public key associated with access device 104-2 received within the message. For example, the public key included in the received message can be used to extract the hash value of the digital signature included in the message. User device 102 can then verify the received message based on a predetermined set of data fields (e.g., ...). Figure 5 Additional hash values ​​are calculated for data fields 502A and 502B. User device 102 can then compare the extracted hash values ​​with the calculated hash values.

[0078] In step 11, since the hash value can be matched because the message data has not changed, the user device 102 can be configured to determine that the message is valid (e.g., unchanged, or at least the predetermined set of data fields has not changed).

[0079] In step 12, the user device may be further configured to determine whether a portion of a data field matches stored information. For example, user device 102 may determine whether identification data received in a message (e.g., an indication of "OtherGas") matches identification data (e.g., "SuperGas") stored at user device 102 and associated with access device 104-1, which is assumed to be connected to user device 102. In an ongoing instance, user device 102 may determine that the received identification data (e.g., "OtherGas") does not match the stored identification data associated with the connected device (e.g., "SuperGas"). Based at least in part on this determination, user device 102 may be configured to terminate any further interaction with access device 104-2.

[0080] Figure 7 A block diagram illustrating yet another exemplary method 700 for preventing relay attacks, according to some embodiments, is shown. Figure 7This refers to an instance where access device 104-1 provides its public key in a connection message transmitted to user device 102. The same public key can be used to verify subsequent messages from access device 104-2. In a relay attack, the public key of the connection device will not match the public key of subsequent messages, which could cause the verification check for subsequent messages to fail at user device 102.

[0081] exist Figure 7 In the examples described above, as in conjunction with Figure 4 and 6 As described, user device 102 may be configured with encrypted data 402 (e.g., a public / private key pair for a certificate and / or authentication). Access devices 104-1 and 104-2 may each be configured to generate and / or store encrypted data 404 and 406, respectively. Each of encrypted data 404 and 406 may include an unauthenticated public / private key pair for each respective device. For example, encrypted data 404 may include a public key 702 and a private key associated with the public key 702.

[0082] In step 1, access device 104-1 (e.g., located at pump 1 in a gas station "SuperGas") can transmit an advertising message (e.g., via a short-range wireless protocol such as BLE). The advertising message may include at least identification data associated with access device 104-1. For example, the identification data may include an identifier of a resource provider (e.g., a merchant, such as "SuperGas"). In some embodiments, the identification data associated with access device 104-1 may also include a device identifier (e.g., "pump 1"). Figure 7 In the example provided, the advertising message may also include the public key 702 of encrypted data 404. User device 102 may approach access device 104-1 to break a threshold distance from access device 104-1 (e.g., within range of receiving short-range wireless messages of a short-range wireless communication protocol).

[0083] In step 2, the intervention device 106-1 operated by the first fraudster can intercept the advertising message and relay the message unchanged to the user device 102.

[0084] In step 3, user device 102 may receive advertising messages and display one or more user interfaces for confirming connection with access device 104-1. For example, user device 102 may present... Figure 2 User interface 200. In some embodiments, user device 102 may store the public key 702 of encrypted data 404 at user device 102.

[0085] When the user interface 200 is presented and a confirmation is received from the user that they wish to establish a connection with "SuperGas, Pump 1" (e.g., ...), Figure 2When the confirmation button 204 is selected, user device 102 can establish a connection with intervention device 106-1 in step 4 using any suitable short-range wireless protocol (e.g., BLE). The user of user device 102 can trust (e.g., based on...) Figure 2 The text 202 provided in the user interface 200 indicates that they are connected to access device 104-1. However, user device 102 may actually be connected to the fraudster's device (e.g., intervention device 106-1).

[0086] Once the connection between the access device 106-1 and the user device 102 is established, the access device 106-1 can connect (or additionally transmit data) to the accomplice's second fraudulent device (e.g., access device 106-2) via any suitable wired and / or wireless connection in step 5. The access device 106-2 may be located at, for example, another access device (e.g., an access device located at another gas station, "OtherGas"). The access device 106-2 can then connect (or additionally transmit data) to the access device 104-2 via a second BLE connection in step 6.

[0087] In some embodiments, access device 104-2 may generate interactive data (e.g., including identification data associated with access device 104-2, such as an interactive value for a pre-authorized amount, etc.) for transmission. However, before transmitting the interactive data, access device 104-2 may be configured as described above. Figures 4-7 The description describes generating a digital signature using at least a portion of the interactive data. Access device 104-2 can generate a digital signature in step 7 using at least a portion of the interactive data. For example, access device 104-2 can utilize any suitable portion of the interactive data (e.g., merchant identifier and / or device identifier, merchant identifier / device identifier / and location associated with the access device, or...). Figure 5 The digital signature is generated by any suitable combination of data fields 504 as described above. Access device 104-2 may insert the digital signature into the message and transmit the message to user device 102. In some embodiments, access device 104-2 may (or may not) insert the public key used to generate the digital signature into the same message before transmitting the message to user device 102.

[0088] Intervention device 106-2 may receive a message from access device 104-2 in step 8 and relay the message to intervention device 106-1 in step 9. Intervention device 106-1 may forward the message to user device 102, either unchanged or modified, in step 10. In some embodiments, intervention devices 106-1 and / or 106-2 may modify a portion of the message, while in other embodiments, intervention devices 106-1 and 106-2 simply relay the message to user device 102 unchanged.

[0089] In step 11, user device 102 can be configured to verify the received message using a digital signature and public key 702. For example, public key 702 received during connection establishment can be used in step 10 to extract the hash value of the digital signature included in the received message. User device 102 can then verify the message based on a predetermined set of data fields (e.g., data fields 502A and 502B, data fields 502A, 502B and 502D, or...). Figure 5 The user device 102 can calculate an additional hash value (any suitable combination of data fields 504). The extracted hash value can then be compared with the calculated hash value.

[0090] In step 12, since the hash values ​​do not match (e.g., at least in part based on the fact that public key 702 is being used to verify the message and public key 702 does not correspond to the private key used to generate the digital signature), user device 102 can determine that the message is invalid. This determination can occur regardless of whether the message has been altered or not. In some embodiments, in addition to verification using the digital signature or as an alternative, user device 102 can be configured to compare public key 702 with the public key included in the received message in step 10. If the public keys do not match, then user device 102 can be configured to determine that the message is invalid using the digital signature and hash value as described above, without having to verify the message.

[0091] In step 13, in response to the determination message being invalid, user device 102 may terminate any further interaction with access device 104-2.

[0092] Figure 8 A block diagram illustrating yet another exemplary method for preventing relay attacks, according to some embodiments, is shown. Figure 8 This refers to an instance where two of the intervention devices merely relay messages between the access device and the user device. Because the messages are not modified, a verification check of the messages can indicate that the messages are valid (e.g., unchanged). However, a notification can be provided to the user, allowing them to know the difference between the entity they believe they are connected to and the entity that subsequently requests additional data (e.g., payment data). The user can utilize this notification to cancel the interaction due to this difference.

[0093] exist Figure 8 In the examples described above, as in conjunction with Figure 4 , 6As described in section 7, user device 102 may be configured with encrypted data 402 (e.g., a public / private key pair for a certificate and / or authentication). Access devices 104-1 and 104-2 may each be configured to generate and / or store encrypted data 404 and 406, respectively. Each of the encrypted data 404 and 406 may include an unauthenticated public / private key pair for each respective device.

[0094] In step 1, access device 104-1 (e.g., located at pump 1 in a gas station “SuperGas”) can transmit an advertising message (e.g., via a short-range wireless protocol such as BLE). The advertising message may include at least identification data associated with access device 104-1. For example, the identification data may include an identifier of a resource provider (e.g., a merchant, such as “SuperGas”). In some embodiments, the identification data associated with access device 104-1 may also include a device identifier (e.g., “Pump 1”). User device 102 may approach access device 104-1 to break a threshold distance from access device 104-1 (e.g., within range of receiving short-range wireless messages via a short-range wireless communication protocol).

[0095] In step 2, the intervention device 106-1 operated by the first fraudster can intercept the advertising message and relay the message unchanged to the user device 102.

[0096] In step 3, user device 102 may receive advertising messages and display one or more user interfaces for confirming connection with access device 104-1. For example, user device 102 may present... Figure 2 User interface 200.

[0097] Return to Figure 8 When the user interface 200 is presented and a confirmation is received from the user that they wish to establish a connection with "SuperGas, Pump 1" (e.g., ...), Figure 2 When the confirmation button 204 is selected, a connection can be established between the intervention device 106-1 and the user device 102 using any suitable short-range wireless protocol (e.g., BLE). The user of the user device 102 can trust (e.g., based on...) Figure 2 The text 202 provided in the user interface 200 indicates that they are connected to access device 104-1. However, user device 102 may actually be connected to the fraudster's device (e.g., intervention device 106-1).

[0098] Once the connection between the intervention device 106-1 and the user device 102 is established, the intervention device 106-1 can connect (or additionally transmit data) to the accomplice's second fraudulent device (e.g., intervention device 106-2) via any suitable wired and / or wireless connection in step 4. The intervention device 106-2 may be located at, for example, another access device (e.g., an access device located at another gas station, "OtherGas"). The intervention device 106-2 can connect (or additionally transmit data) to the access device 104-2 via a second BLE connection in step 5.

[0099] In some embodiments, access device 104-2 may generate interactive data (e.g., including identification information associated with access device 104-2, such as an interactive value for a pre-authorized amount, etc.) for transmission. However, before transmitting the interactive data, access device 104-2 may be configured as described above. Figures 4-7 The described method generates a digital signature using at least a portion of the interactive data. Access device 104-2 can generate a digital signature in step 6 using at least a portion of the interactive data. For example, access device 104-2 can... Figure 5 The method described herein utilizes identification data (e.g., merchant identifier, device identifier) ​​and (in some cases) the location associated with the access device to generate a digital signature. Access device 104-2 may insert the digital signature and the public key corresponding to the private key used to generate the digital signature into the message and transmit the message to user device 102.

[0100] Intervention device 106-2 may receive a message from access device 104-2 in step 7 and relay the message to intervention device 106-1 in step 8. Intervention device 106-1 may forward the message unchanged to user device 102 in step 9.

[0101] In step 10, user device 102 can be configured to verify the received message using a digital signature and public key associated with access device 104-2 received within the message. For example, the public key included in the received message can be used to extract the hash value of the digital signature included in the message. User device 102 can then verify the received message based on a predetermined set of data fields (e.g., data fields 502A and 502B, data fields 502A, 502B and 502D, or...). Figure 5 The user device 102 can calculate an additional hash value (any suitable combination of data fields 504). The extracted hash value can then be compared with the calculated hash value.

[0102] In step 11, since the hash value matches because the data has not changed, user device 102 can be configured to determine that the message is valid (e.g., unchanged, or at least the predetermined set of data fields has not changed). Due to this determination, a user interface can be presented at user device 102 (e.g., ...). Figure 3 The user interface 300 is configured to prevent confirmation from the user regarding their intention to interact with access device 104-2. This might be because the user was presented with information (e.g., “SuperGas”) upon connection, so they might recognize that the data now presented (e.g., “OtherGas”) is associated with an access device (e.g., access device 104-2) that they believe they are connected to (e.g., access device 104-1). The user can indicate (e.g., via…) Figure 3 (Selection of the cancel button 304) He does not intend to interact with access device 104-2.

[0103] In step 12, although the message is determined to be valid, user device 102 may terminate any further interaction with access device 104-2, at least in part, based on receiving an indication that the user does not intend to interact with access device 104-2.

[0104] Figure 9 A block diagram illustrating another exemplary method 900 for preventing relay attacks, according to some embodiments, is shown. Figure 9 This refers to an instance where a user device (e.g., user device 102) mistakenly believes it has established a connection with access device 104-1 (e.g., associated with "SuperGas") but incorrectly authorizes subsequent interaction with access device 104-2 (e.g., "OtherGas"). This is because, despite being provided with notification, the user may not notice the difference between the claimed connected access device and the access device requesting the subsequent interaction. In this use case, user device 102 can digitally sign back data to access device 104-2. Upon receipt, access device 104-2 can check the message's public key (e.g., the public key of access device 104-2 previously sent to the user device and subsequently digitally signed by the user device). If the public key included in the message is the same as the public key held by access device 104-2, then the interaction can be considered valid. If valid, at least a portion of the received data can be sent to the resource provider for a conventional authorization request process. However, if the message is invalid, access device 104-2 can be configured to stop processing.

[0105] exist Figure 9 In the example depicted, user device 102 can be configured with encrypted data 402. As described above, relative to... Figure 4As discussed, encrypted data 402 may include a certificate issued by a certificate authority (not depicted). Access devices 104-1 and 104-2 may each be configured to generate encrypted data 404 and 406, respectively. Each of encrypted data 404 and 406 may include an unauthenticated public / private key pair for each respective device.

[0106] In step 1, access device 104-1 (e.g., located at pump 1 in a gas station “SuperGas”) can transmit an advertising message (e.g., via a short-range wireless protocol such as BLE). The advertising message may include at least identification data associated with access device 104-1. For example, the identification data may include an identifier of a resource provider (e.g., a merchant, such as “SuperGas”). In some embodiments, the identification data associated with access device 104-1 may also include a device identifier (e.g., “Pump 1”). User device 102 may approach access device 104-1 to break a threshold distance from access device 104-1 (e.g., within range of receiving short-range wireless messages via a short-range wireless communication protocol).

[0107] In step 2, the intervention device 106-1 operated by the first fraudster can intercept the advertising message and relay the message unchanged to the user device 102.

[0108] In step 3, user device 102 may receive advertising messages and display one or more user interfaces for confirming connection with access device 104-1. For example, user device 102 may present... Figure 2 The user interface.

[0109] Upon presentation of user interface 200 and receipt of confirmation from the user that they wish to establish a connection with "SuperGas, Pump 1" (e.g., indication that confirmation button 204 has been selected), a connection can be established between intervention device 106-1 and user device 102 using any suitable short-range wireless protocol (e.g., BLE). The user of user device 102 can trust (e.g., based on...) Figures 4-8 The text 202 provided in the user interface 200 indicates that they are connected to access device 104-1. However, user device 102 may actually be connected to the fraudster's device (e.g., intervention device 106-1).

[0110] Once the connection between the intervention device 106-1 and the user device 102 is established, the intervention device 106-1 can connect (or additionally transmit data) to the accomplice's second fraudulent device (e.g., intervention device 106-2) via any suitable wired and / or wireless connection in step 4. The intervention device 106-2 may be located at, for example, another access device (e.g., an access device located at another gas station, "OtherGas"). The intervention device 106-2 can connect (or additionally transmit data) to the access device 104-2 via a second BLE connection in step 5.

[0111] In some embodiments, access device 104-2 may generate interactive data (e.g., including identification information associated with access device 104-2, such as an interactive value for a pre-authorized amount, etc.) for transmission. However, before transmitting the interactive data, access device 104-2 may be configured to combine the above description with... Figure 5 The method described generates a digital signature using at least a portion of the interactive data.

[0112] In step 6, access device 104-2 may generate a digital signature using at least a portion of the interaction data. For example, access device 104-2 may utilize any suitable portion of the interaction data (e.g., merchant identifier, device identifier, etc.) in the manner described above. Figure 5 The access device 104-2 can insert a digital signature and a public key corresponding to the private key used to generate the digital signature into the message and transmit the message to the user device 102. (This can be done using any suitable combination of data fields 504, etc.)

[0113] Intervention device 106-2 may receive a message from access device 104-2 in step 7 and relay the message to intervention device 106-1 in step 8. Intervention device 106-1 (and / or intervention device 106-2) may relay the unchanged message to user device 102 in step 9. It should be understood that in ongoing instances, the message still indicates identification data corresponding to "OtherGas".

[0114] In step 10, user device 102 can be configured to verify the received message using a digital signature and public key associated with access device 104-2 received within the message. For example, the public key included in the received message can be used to extract the hash value of the digital signature included in the message. User device 102 can then verify the received message based on a predetermined set of data fields (e.g., ...). Figure 3 Additional hash values ​​are calculated for data fields 502A and 502B. User device 102 can then compare the extracted hash values ​​with the calculated hash values.

[0115] In step 11, since the hash value can be matched because the message data has not changed, user device 102 can be configured to determine that the message is valid (e.g., unchanged, or at least the predetermined set of data fields has not changed). One or more user interfaces can be provided at the user device (e.g., Figure 5 The user interface 300. The user may not realize that the text 302 indicates an interaction with an access device (e.g., access device 104-2) that the user believes is connected to the access device (e.g., access device 104-1). Therefore, the user can confirm the interaction in step 12.

[0116] In step 13, in response to receiving an instruction from the user confirming the interaction with access device 104-2, user device 102 may be configured to provide payment data and encrypted data 402 (e.g., a certificate issued by a certificate authority, not shown). In some embodiments, the payment data included by user device 102 in the message may be in the form of a token and / or an encrypted value that can be decrypted by the receiving access device 104-2. User device 102 may include a portion of the interaction data originally provided by access device 104-2 in the received message in step 9. For example, user device 102 may include identification data associated with the access device (e.g., a merchant identifier and / or device identifier) ​​together with the public key provided in the message received in step 9 and associated with access device 104-2. In some embodiments, user device 102 may be configured to utilize any suitable message data (e.g., identification data, the public key associated with access device 104-2, payment data, encrypted data 402, or the above and / or the above). Figure 12 A digital signature is generated from any suitable combination of the data field 5024.

[0117] Intervention device 106-1 can receive messages from the user device and relay the messages to intervention device 106-2 in step 14. Intervention device 106-2 can then relay the messages to access device 104-2.

[0118] In step 16, access device 104-2 can be configured to verify the received message using the public key associated with user device 102. For example, the public key associated with the certificate issuing authority contained in the message received in step 15 can be retrieved from the local storage of access device 104-2. The certificate issuing authority's public key can be used to retrieve the public key associated with user device 102 from the certificate. Access device 104-2 can be configured to verify the received message in step 15 using the public key associated with user device 102.

[0119] For example, access device 104-2 can be configured to retrieve a hash value from the digital signature of the received message in step 15 using the public key associated with user device 102. Access device 104-2 can then generate additional hash values ​​using a predetermined hash algorithm and a predetermined set of data fields from the message received in step 15. For example, the additional hash value can be generated by providing a hash algorithm as input to any suitable combination of the message's identification data, the public key included in the message, and / or payment data included in the message. Once generated, the resulting hash value can be compared with the hash value retrieved from the digital signature. If the hash values ​​do not match, access device 104-2 can be configured to terminate the interaction and not perform further processing of the payment data.

[0120] If the hash values ​​match, access device 104-2 can be configured to continue because a match indicates that not only has the message remained unchanged, but also (e.g., by user device 102) the message initially transmitted in step 7 has been verified using the correct public key associated with access device 104-2. In some embodiments, access device 104-2 can continue by generating an authorization request message, which can then be transmitted to the resource provider's computer (e.g., Figure 12 The resource provider computer (1230) is used as part of the traditional process for authorizing payment transactions. Regarding Figure 9 The process for authorizing payment transactions is described in further detail. If an authorization request is granted, then access device 104-2 can enable user device 102 to access goods and / or services (e.g., gasoline managed by access device 104-2).

[0121] Figure 10 The examples provided illustrate how the disclosed techniques can successfully prevent relay attacks. A successful relay attack can only occur if the data transmitted between user device 102 and access device 104-2 remains unchanged. In practice, most users will recognize the difference between the merchant they are connected to (e.g., SuperGas) and the merchant they are asked to consent to payment with (e.g., OtherGas). Even if a user inadvertently consents to payment, signature verification at access device 104-2 will fail. Figure 1 A block diagram illustrating an exemplary user device 1002 according to an embodiment of the present invention is shown. The user device 1002 may be... Figure 10 , 4Examples of user device 102 (6-9) are provided. In some embodiments, user device 1002 may include circuitry for enabling certain device functions, such as a telephone. Functional elements responsible for enabling those functions may include processor 1002B, which executes instructions to implement the functions and operations of the device. Processor 1002B may access memory 1002F (or another suitable data storage area or element) to retrieve instructions or data for executing those instructions, such as providing scripts and mobile applications. Data input / output elements 1002D, such as a keyboard or touchscreen, may be used to enable a user to operate user device 1002 and input data. Data input / output elements may also be configured to output data (via, for example, the device's speaker). Display 1002C may also be used to output data to the user. Communication element 1002E may be used to enable data transmission between user device 1002 and wired or wireless networks (via, for example, antenna 1002G) to facilitate connection to the Internet or other networks and to implement data transmission functionality. In some embodiments, communication element 1002E may utilize a short-range wireless communication protocol (e.g., BLE).

[0122] In some embodiments, user device 1002 may further include a contactless element interface to enable data transfer between a contactless element (not shown) and other elements of the device, wherein the contactless element may include secure storage and near-field communication data transmission elements (or another form of short-range communication technology). Cellular telephones or similar devices are examples of user device 1002 that can be used according to embodiments of the invention. However, other forms or types of devices may be used without departing from the basic concept of the invention. For example, user device 1002 may alternatively take the form of a payment card, key card, PDA, tablet computer, webbook, laptop computer, smartwatch, remote-capable car, etc.

[0123] The memory 1002F may include application 1002H and / or any other suitable modules or data. For example, in some embodiments, the memory 1002F may include a signing module 1002I, an authentication module 1002J, and / or encrypted data 1002K. The user device 1002 may have any number of mobile applications installed or stored on the memory 1002F, and is not limited to these. Figure 1 The situation is illustrated in the diagram. The memory 1002F may also include code that can be executed by the processor 1002B to implement the methods discussed herein.

[0124] Application 1002H can take any suitable form. For example, application 1002H can be used with access devices (e.g., Figure 11 Access device 104-1, Figure 2An application that interacts with access devices such as 1102. In some embodiments, application 1002H may be an application configured to provide any suitable user interface (e.g., respective access devices 1102, etc.). Figure 13 and 3 The user interface 200 and 300) or any suitable user interface configured to collect data and / or confirm interactions between the user device 1002 and the access device. In some embodiments, application 1002H can be used to perform transactions for goods and / or services, such as exchanging payment data and / or interaction data (e.g., identification data, interaction values, public keys, location, device information, etc.) with the access device to obtain fuel (or another good and / or service) and / or access to resources (e.g., as follows regarding...). Figure 12 The entrance to the building (the point of entry). In some embodiments, application 1002H (or another suitable module) may be configured to cause processor 1002B to perform operations and / or present any suitable user interface for establishing a connection (e.g., BLE connection) with one or more other devices (e.g., access devices, intervention devices, etc.). Application 1002H (or another suitable module) may also be configured to cause processor 1002B to perform operations and / or present any suitable interface for confirming interaction with one or more other devices (e.g., access devices, intervention devices, etc.).

[0125] In some embodiments, application 1002H may be configured to transmit and / or receive any suitable messages to and / or from access and / or intervention devices. In some embodiments, these messages may be transmitted and / or received via BLE and / or other suitable short-range wireless communication protocols. Application 1002H may be configured to enable processor 1002B to activate the functionality of signing module 1002I before message transmission and / or to activate the functionality of verification module 1002J upon receiving a message.

[0126] The signing module 1002I may be configured with code that, when executed by the processor 1002B, causes the processor 1002B to perform any suitable operations for generating a digital signature and transmitting a message that includes at least the digital signature. For example, the signing module 1002I may be configured to cause the processor 1002B to hash one or more data fields of the message data (e.g., identification data associated with user device 1002, identification data associated with access device, one or more locations associated with user device 1002 and / or access device, interaction values, the public key of the access device, the certificate of user device 1002, and / or the like) to generate a hash value. In some embodiments, the signing module 1002I may be configured to cause the processor 1002B to digitally sign the hash value using a private key associated with user device 1002. Once generated, the digital signature can be inserted into a message (e.g., along with one or more other data fields, such as identification data associated with user device 1002, identification data associated with access device, one or more locations associated with user device 1002 and / or access device, interaction values, the public key of access device, the certificate of user device 1002, and / or the like) and transmitted to the access device. In some embodiments, the signing module 1002I can operate as part of the application 1002H.

[0127] The verification module 1002J may be configured with code that, when executed by the processor 1002B, causes the processor 1002B to perform any suitable operations for verifying the message. In some embodiments, the verification module 1002J may be configured to cause the processor 1002B to receive a message including a public key of an access device. In some embodiments, the verification module 1002J may store the received public key in memory 1002F for later use. In some embodiments, the verification module 1002J may be configured to cause the processor 1002B to receive a message including a digital signature (e.g., a digital signature generated by the access device using a private key associated with the access device). In some embodiments, the received message may also include a public key associated with the access device. The verification module 1002J may cause the processor 1002B to verify the received message using the public key (e.g., a stored public key received in a message including a digital signature or in a previous message).

[0128] For example, the verification module 1002J can be configured to cause the processor 1002B to retrieve a hash value from the digital signature using a stored or received public key. The verification module 1002J can also cause the processor 1002B to hash one or more data fields of the received message (e.g., identification data associated with user device 1002, identification data associated with access device, one or more locations associated with user device 1002 and / or access device, interaction values, the public key of the access device, the certificate of user device 1002, and the like) to generate an additional hash value. In some embodiments, the verification module 1002J can be configured to cause the processor 1002B to compare the hash value retrieved from the digital signature with the calculated hash value. If the hash values ​​match, the verification module 1002J can incentivize the application 1002H (or another suitable module) to perform an operation (e.g., transmitting a message including at least a portion of the received message data to another device, such as...). Figure 12 The resource provider is computer 1230.

[0129] In some embodiments, if the hash values ​​match, the verification module 1002J can determine that the message is valid (e.g., unchanged). In some embodiments, the verification module 1002J can be configured to cause the processor 1002B to perform another determination regarding whether the location of a valid message is within a threshold distance of the location associated with the user device 1002. In these instances, the verification module 1002J can retrieve the location associated with the user device 1002 from, for example, a GPS component of 1002 (e.g., an instance of data input / output element 1002D). In a further embodiment, the verification module 1002J can perform additional operations, upon determining that the message is valid (e.g., based on a comparison of the retrieved hash with a calculated hash), to compare a stored identifier associated with an access device to which the user device 1002 is supposedly connected and identification data of a received message associated with a transmission device (e.g., the access device). In some embodiments, if a message is determined to be invalid (e.g., altered, at least in part based on a comparison of the retrieved hash and the calculated hash), and / or the location is not within a threshold distance from each other, and / or if the stored identifier does not match the identification data included in the received message, then the verification module 1002J may terminate the interaction and not perform further processing with the transmission device. In some embodiments, the verification module 1002J may operate as part of the application 1002H.

[0130] In some embodiments, the verification module 1002J (e.g., upon determining that the message is valid, and / or the locations are within a predetermined distance from each other, and / or the stored identifier matches the identification data included in the message) can be configured to trigger the application 1002H to present a user interface at the display 1002C to prohibit confirmation from the user of the user device 1002 of any further interaction with the transmitting device (e.g., the access device indicated in the message). Upon receiving confirmation, the application 1002H can be configured to cause the processor 1002B to execute code associated with the signing module 1002I described above to transmit a message that may include a digital signature generated by the signing module 1002I as described above.

[0131] Encrypted data 1002K can be presented by a Certificate Authority (CAA) (e.g., Figure 10 The certificate is provided by a processing network computer 1250 or any suitable certification authority. The encrypted data 1002K may also include a public / private key issued by a certificate authority and supplied to user device 1002. In some embodiments, the certificate may be digitally signed using the private key associated with the certificate authority. The certificate authority's public key may be distributed to one or more access devices. In some embodiments, the certificate may include the public key associated with user device 1002 and / or any suitable identification data. The certificate may be digitally signed by the certificate authority such that the public keys distributed to the access devices can be used to retrieve the public key associated with user device 1002 from the certificate.

[0132] Figure 1 An example of an access device 1102 according to an embodiment of the present invention is shown. The access device 1102 may be... Figure 1Examples of access devices 104-1 and / or 104-2. In some embodiments, access device 1102 may include circuitry for enabling certain device functions, such as a telephone. Functional elements responsible for enabling those functions may include processor 1102B, which executes instructions to implement the functions and operations of the device. Processor 1102B may access memory 1102F (or another suitable data storage area or element) to retrieve instructions or data for executing instructions, such as providing scripts and mobile applications. Data input / output elements 1102D, such as a keyboard or touchscreen, may be used to enable a user to operate access device 1102 and input data. Data input / output elements may also be configured to output data (via, for example, a speaker of the device). Display 1102C may also be used to output data to a user. Communication element 1102E may be used to enable data transmission between access device 1102 and wired or wireless networks (e.g., via antenna 1102G) to facilitate connection to the Internet or other networks and to implement data transmission functionality. In some embodiments, communication element 1102E may utilize a short-range wireless communication protocol (e.g., BLE).

[0133] In some embodiments, the access device 1102 may further include a contactless element interface to enable data transfer between a contactless element (not shown) and other elements of the device, wherein the contactless element may include secure memory and near-field communication data transmission elements (or another form of short-range communication technology). A point-of-sale terminal is an example of an access device 1102 that can be used according to embodiments of this disclosure. However, other forms or types of devices may be used without departing from the basic concept of the invention.

[0134] The memory 1102F may include a data processing module 1102H and / or any other suitable module or data. For example, in some embodiments, the memory 1102F may also include a signing module 1102I, an authentication module 1102J, and / or encrypted data 1102K. The memory 1102F may also include code executable by the processor 1102B for implementing the methods discussed herein.

[0135] The encrypted data 1102K may be in the form of a public / private key pair generated by the access device 1102. The public / private key pair can be generated at any suitable time and stored in the memory 1102F for later use. In some embodiments, new public / private key pairs can be generated to correspond to a specific interaction with another device (e.g., a user device, an intervention device, etc.) so that a unique public / private key pair can correspond to a specific message exchange. In other embodiments, the same public / private key pair can be used for any suitable message exchange with any suitable interaction device (e.g., a user device and / or an intervention device).

[0136] The data processing module 1102H can take any suitable form. In some embodiments, the data processing module 1102H may be configured with code that, when executed by the processor 1102B, causes the processor 1102B to send and / or receive messages (e.g., to and / or from a user device and / or an access device). In some embodiments, the data processing module 1102H may be configured to transmit messages (e.g., advertisements) that at least indicate one or more identifiers, such as those of the access device 1102. In some embodiments, the data processing module 1102H may be configured to cause the processor 1102B to include a public key associated with the access device 1102, retrieved from encrypted data 1102K. The data processing module 1102H may include the public key in any suitable message transmission (e.g., an advertisement message, an interactive request message, etc.). In some embodiments, the data processing module 1102H may be configured to incentivize the signing module 1102I to generate digital signatures from one or more message data fields of the message to be transmitted. In some embodiments, the data processing module 1102H may be configured to stimulate the functionality of the verification module 1102J at least in part based on messages received from devices (e.g., user devices and / or intervention devices).

[0137] Typically, the data processing module 1102H can be configured to transmit and / or receive any suitable messages to and / or from the access device and / or intervention device. In some embodiments, these messages can be transmitted and / or received via BLE and / or other suitable short-range wireless communication protocols. The data processing module 1102H can also be configured to cause the processor 1102B to activate any suitable functionality of the signing module 1102I and / or the verification module 1102J to perform the methods discussed herein.

[0138] The signing module 1102I may be configured with code that, when executed by the processor 1102B, causes the processor 1102B to perform any suitable operations for generating a digital signature and transmitting a message that includes at least the generated digital signature. For example, the signing module 1102I may be configured to cause the processor 1102B to hash one or more data fields of the message (e.g., identification data associated with access device 1102, location associated with access device 1102, interaction value, public key of access device 1102, and / or the like) to generate a hash value. In some embodiments, the signing module 1102I may be configured to cause the processor 1102B to digitally sign the hash value using a private key associated with access device 1102. Once generated, the digital signature can be inserted into the message (e.g., along with one or more other data fields, such as identification information associated with access device 1102, location associated with access device 1102, transaction information, public key of access device 1102, and / or the like) and transmitted to another device (e.g., Figure 1 User device 102, Figure 12 Interventional devices 106-1, etc.

[0139] Verification module 1102J may be configured with code that, when executed by processor 1102B, causes processor 1102B to perform any appropriate operations for verifying received messages. In some embodiments, verification module 1102J may be configured to cause processor 1102B to receive a message including a digital signature purportedly generated by a user device (e.g., using a private key associated with user device 102). The message may also include a certificate associated with user device 102 and issued by a certificate authority. In some embodiments, access device 1102 may store a public key associated with a certificate authority within encrypted data 1102K. When retrieving the certificate authority's public key, verification module 1102J may be configured to retrieve the public key associated with the user device from the received certificate using the certificate authority's public key. Verification module 1102J may cause processor 1002B to verify the digital signature of the received message using the public key associated with the user device and retrieved from the certificate.

[0140] For example, the verification module 1102J can be configured to cause the processor 1102B to retrieve a hash value from the digital signature using the public key of the user device. The verification module 1102J can also cause the processor 1102B to hash one or more data fields of the received message (e.g., identification information associated with access device 1102, identification information associated with user device 102, payment data and / or transaction information, the certificate of user device 102, and the like) to generate an additional hash value. In some embodiments, the verification module 1102J can be configured to cause the processor 1102B to compare the hash value retrieved from the digital signature with the calculated hash value. If the hash values ​​match, the verification module 1102J can incentivize the data processing module 1102H (or another suitable module) to perform an operation (e.g., transmitting the message, including at least a portion of the received message data, to another device, such as...). Figure 12 The resource provider is computer 1230.

[0141] In some embodiments, if the hash values ​​match, the verification module 1102J can determine that the message is valid (e.g., unchanged). In some embodiments, the verification module 1102J can be configured to cause the processor 1102B to retrieve, from a message received from the user device (or from the intervention device), the public key of the access device used to transmit the message to the user device 102. The verification module 1102J can be configured to cause the processor 1102B to determine whether the public key of the access device included in the received message matches a public key of the access device stored in encrypted data 1102K that was previously used to transmit to the user device. If the public keys match, the verification module 1102J can be configured to cause the processor 1102B to determine that the message is valid (e.g., unchanged) and that the previously transmitted message of the received message was verified by the user device (e.g., user device 102) using the correct public key (e.g., the public key stored in encrypted data 1102K associated with the previously transmitted message). In some embodiments, if a message is determined to be invalid (e.g., altered, at least in part based on a comparison of the retrieved hash with the calculated hash), and / or the public key of the received message does not match the public key stored in the encrypted data 1102K and associated with the previous message transmission to the user device 102, then the verification module 1102J may terminate the interaction and not perform further processing with the transmitting device.

[0142] The systems and methods described above for preventing relay attacks can be used in any suitable transaction or interaction. For example, they can be used in payment processes or access transactions. The following section combines... Figure 12 and 13 These examples will be described in further detail.

[0143] Figure 12A block diagram 1200 of a transaction processing system that can be used with user device 102 is shown. Figures 1-10 An operable user device 1210 is shown (e.g., Figure 10 Instance of user device 102, Figures 1-10 User 1206 (e.g., user device 1002, etc.). User 1206 can use user device 1210 to pay for goods or services at, for example, a merchant's resource provider. The merchant can operate resource provider computer 1230 and / or access device 1220 (e.g., Figure 5 (Examples of access device 104-1 and / or access device 1102). Merchants can communicate with authorized entity computer 1260 operated by the issuer via a transmission computer 1240 operated by the acquirer and a processing network 1250, such as a payment processing network.

[0144] A payment processing network may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception handling services, and clearing and settlement services. An exemplary payment processing network may include VisaNet. TM For example, VisaNet TM Payment processing networks like VisaNet can handle credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet... TM This includes the VIP system (Visa Integrated Payment System) for processing authorization requests and the Base II system for performing clearing and settlement services. The payment processing network can use any suitable wired or wireless network, including the Internet.

[0145] A typical payment transaction process using user device 1210 at access device 1220 (e.g., a POS location) can be described as follows. User 1206 presents his user device 1210 to access device 1220 to pay for goods or services. User device 1210 and access device 1220 can interact via the BLE communication protocol. In some embodiments, data (e.g., identification information, public key, certificate, location information, interaction data, etc.) can be exchanged between user device 1210 and access device 1220. Data transmitted from access device 1220 to user device 1210 can be digitally signed by access device 1220 in the manner described above and verified by user device 1210. Similarly, data transmitted from user device 1210 can be digitally signed by user device 1210 in the manner described above and verified by access device 1220. If the message data exchanged between the devices is verified to be unchanged and the interaction is permitted, then the data related to the interaction (e.g., identification data of access device 1220, identification data of user device 1210, payment information, etc.) is considered valid. Figure 13 The message data (502 or any suitable data) can be transmitted to the resource provider's computer 1230.

[0146] Resource provider computer 1230 may receive this information from access device 1220 via an external communication interface. Resource provider computer 1230 may then generate an authorization request message including the information received from access device 1220 and transmit this information electronically to transmission computer 1240. Transmission computer 1240 may then receive, process, and forward the authorization request message to processing network 1250 for authorization.

[0147] Generally, prior to a credit or debit card transaction, processing network 1250 establishes an agreement with each issuer regarding how transactions will be authorized. In some cases, such as when the transaction amount is below a threshold, processing network 1250 can be configured to authorize the transaction based on its information about the user account without generating and transmitting an authorization request message to authorization entity computer 1260. In other cases, such as when the transaction amount is above a threshold, processing network 1250 can receive an authorization request message, identify the issuer associated with user device 1210, and forward the authorization request message for the transaction to authorization entity computer 1260 for verification and authorization. Once the transaction is authorized, authorization entity computer 960 can generate an authorization response message (which may include an authorization code indicating that the transaction is approved or rejected) and transmit this electronic message to processing network 1250 via its external communication interface. The processing network 1250 may then forward the authorization response message to the transmission computer 1240, which may then transmit an electronic message including an authorization instruction to the resource provider computer 1230, and then to the access device 1220. The access device 1220 may provide access to goods and / or services based at least in part on the receipt of the authorization response message (e.g., receiving an authorization response message indicating that a transaction has been approved).

[0148] At the end of the day or at some other suitable time interval, a clearing and settlement process can be performed on the transaction between the resource provider computer 1230, the transmission computer 1240, the processing network 1250, and the authorizing entity computer 1260.

[0149] Figure 13 A block diagram of a building access system is shown. Figure 1 The user device 1310 operated by user 1306 is shown (e.g., Figure 1 User device 1310 may have the certificate as described above. User device 1310 may be connected to access device 1320 (e.g., ...). ​The user device 1310 interacts with access device 104-1 (an instance of access device 104-1) and transmits access data to access device 1320. Access device 1320 can be configured to generate a public / private key. The advertisement and / or any suitable message data transmitted by access device 1320 (e.g., the identifier of access device 1320, the location of access device 1320, interaction data, etc.) can be hashed and the resulting hash value signed using the private key. Access device 1320 can provide the public key and digital signature to user device 1310 in the same message or different messages. User device 1310 can use the provided public key (or a public key received from another access device in the event of a relay attack) to verify the message. If the message is invalid, user device 1310 can terminate the interaction with access device 1320. If the message is valid, user device 1310 can use additional message data (e.g., the location of access device 1320) to perform a distance check, and terminate the interaction if the distance of user device 1310 is outside a threshold distance to the location of access device 1320. If the message is valid, the user of user device 1310 can be presented with an option to confirm the interaction with access device 1320. If confirmed, user device 1310 can then send the message back to access device 1320.

[0150] In some embodiments, message data of a message transmitted from user device 1310 to access device 1320 may include a certificate associated with user device 1310, an identifier of access device 1320, and a public key for verifying the originally received message. In some embodiments, the identifier and public key of access device 1320 may be hashed and digitally signed using a private key associated with user device 1310. Upon receipt or at any suitable time, access device 1320 may retrieve user device 1310's public key from the certificate using the public key associated with the certification authority that issued the certificate. Using the retrieved public key, access device 1320 may verify the message using the digital signature provided by user device 1310. As part of the verification, access device 1320 may verify its public key, at least in part, based on the determination that the public key provided in the message has not changed (e.g., determined using the message's digital signature) and that the provided public key matches a public key stored by access device 1320, which user device 1310 used to verify the originally transmitted message. If access device 1320 determines that the message data received from user device 1310 is valid, then access device 1320 may proceed to allow user 1306 to enter building 1330. However, if access device 1320 determines that user device 1310 used an incorrect public key for authentication, or that any part of the message data has been altered (e.g., as can be determined using a digital signature), then access device 1320 may terminate interaction with user device 1310 and may not grant user 1306 access to building 1330.

[0151] Technological benefits

[0152] Embodiments of the present invention offer several advantages. For example, by configuring the disclosed access device to generate its own public / private key, the system can provide enhanced authentication functionality without incurring the additional key maintenance overhead of a certificate authority. Utilizing the various methods disclosed herein, user device 102 can be configured to authenticate interaction data from an interaction device (e.g., an access device) using digital signatures and public keys. Through this authentication, user device 102 can be configured to determine when a message has changed and can be configured to automatically reject and / or terminate interaction with the access device. These techniques ensure that user device 102 does not provide payment information to the intervention device. Even if one or more intervention devices intercept the message and relay it to user device 102, the techniques disclosed herein enable the user to detect that data is being received from a device that is not a device to which the user has confirmed a connection. The ability to cancel and / or terminate interaction can be provided to the user. Even when the user cannot discern the difference, user device 102 can digitally sign its interaction data (e.g., including its payment data) when data is transmitted back to the access device (e.g., potentially unintentionally through one or more intervention devices). The receiving access device can then use the public key associated with the user device to verify the data within the message to ensure that: 1) the message has not been altered, and 2) the original message transmitted to the user device is verified using the correct public key associated with the access device. In this way, data security is enhanced, preventing relay attacks and / or man-in-the-middle attacks that would otherwise allow fraudsters to access sensitive information (e.g., payment data) for fraudulent purposes.

[0153] It should be understood that the invention described above can be implemented in a modular or integrated manner using computer software in the form of control logic. Based on this disclosure and the teachings provided herein, those skilled in the art will know and understand other ways and / or methods of implementing the invention using hardware and combinations of hardware and software. Any entity mentioned above can operate a computer programmed to perform the functions described herein.

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

[0155] Different arrangements of components depicted in the accompanying drawings or described above, as well as components and steps not shown or described, are possible. Some features and sub-combinations are useful and can be used without reference to other features and sub-combinations. Embodiments of the invention have been described for illustrative and non-limiting purposes, and alternative embodiments will become apparent to the reader of this patent. Therefore, the invention is not limited to the embodiments described above or in the accompanying drawings, and various embodiments and modifications can be made without departing from the scope of the appended claims.

Claims

1. A method for conducting a communication, comprising: connecting, by a first access device, to a first intervening device using a short-range wireless communication protocol, wherein the first access device connects to the first intervening device after a second intervening device connects to the first intervening device, the second intervening device connecting to the first intervening device upon establishing a connection with a user device in proximity to a second access device, the second intervening device establishing the connection with the user device upon (1) intercepting an advertisement message transmitted by a second access device and (2) relaying the advertisement message to the user device, causing the user device to present a user interface to receive confirmation of the connection; generating, by the first access device, a message comprising message data, the message data comprising a public key and an identifier associated with the first access device; generating, by the first access device, a digital signature using a private key corresponding to the public key, the digital signature signed to a hash of the message data comprising the identifier associated with the first access device, wherein the first access device inserts the digital signature into the message prior to transmission; and sending, by the first access device, the message comprising the message data, the public key, and the digital signature to the first intervening device, the message sent to the user device, wherein the message is sent to the user device via the first intervening device and the second intervening device, wherein the user device determines that the message is valid or invalid based on extracting the hash from the digital signature using the public key, comparing the hash to a second hash generated from the message data, and determining whether the message data has been altered based on whether the hash matches the second hash, the user device configured to terminate any further interaction with the first access device based at least in part on determining that the message is invalid when the hash does not match the second hash.

2. The method of claim 1, wherein the message data comprises a value corresponding to the interaction between the first access device and the user device.

3. The method of claim 1, wherein the first access device and the second access device are automatic fuel dispensers.

4. The method of claim 1, wherein the message data further comprises a location associated with the first access device.

5. The method of claim 1, wherein the user device and the second intervening device are communicatively connected using the short-range wireless communication protocol.

6. The method of claim 1, wherein the user device determines that the message is valid when the hash matches the second hash, and provides a second message comprising a second public key in response to receiving confirmation from a user of the user device to interact with the first access device, and wherein the method further comprises: receiving, by the first access device from the user device via the second intervening device and the first intervening device, the second message including the second public key, wherein the second message is initially received by the second intervening device from the user device and is relayed by the second intervening device to the first intervening device; determining, by the first access device, that the second message is invalid based at least in part on the second public key of the second message; and terminating, by the first access device, processing of the second message based on determining that the second message is invalid.

7. The method of claim 6, wherein determining that the message is invalid further comprises comparing the public key sent in the message with the second public key obtained from the second message.

8. The method of claim 6, wherein the second message includes a second digital signature generated by the user device and a certificate associated with the user device, and wherein determining that the second message is invalid further comprises: obtaining a corresponding public key associated with the user device from the certificate; obtaining the second public key from the second digital signature from the second message using the corresponding public key associated with the user device; and verifying that the second public key obtained from the second message using the public key associated with the user device does not match the public key provided in the message.

9. An access device comprising: one or more processors; and a computer-readable storage medium comprising instructions that, when executed by the one or more processors, cause the access device to: connect to a first intervening device using a short-range wireless communication protocol, wherein the access device connects to the first intervening device after a second intervening device connects to the first intervening device, the second intervening device connecting to the first intervening device upon establishing a connection with a user device in proximity to a second access device, the second intervening device establishing the connection with the user device upon intercepting an advertisement message transmitted by a second access device; and relaying the advertisement message to the user device, causing the user device to present a user interface to receive confirmation of the connection; generate a message including message data, the message data including a public key and an identifier associated with the access device; generate a digital signature by signing a hash of the message data including the identifier associated with the access device using a private key corresponding to the public key, wherein the access device inserts the digital signature into the message prior to transmission; and transmit the message including the message data, the public key, and the digital signature to the first intervening device, the message being transmitted to the user device, the message being transmitted to the user device via the first intervening device and the second intervening device. ​ ​ wherein the user device determines that the message is valid or invalid based on extracting the hash from the digital signature using the public key, comparing the hash to a second hash generated from the message data, and determining whether the message data has been altered based on whether the hash matches the second hash, the user device being configured to terminate any further interaction with the access device based at least in part on determining that the message is invalid when the hash does not match the second hash.

10. The access device of claim 9, wherein the user device verifies the message based at least in part on comparing the public key provided in the message to a previously stored public key associated with the second access device.

11. The access device of claim 9, wherein executing the instructions further causes the access device to: receive a second message from the user device via the second intervening device and the first intervening device, the second message including a first location corresponding to the user device; and determine that the second message is invalid based at least in part on determining that the first location corresponding to the user device is outside a threshold distance to a second location corresponding to the access device.

12. The access device of claim 9, wherein the private key associated with the access device is part of a public / private key pair generated by the access device for the interaction between the access device and the user device.

13. A method for communicating, comprising: receiving, by a user device from a first intervening device, a first message including first access device identification data for a first access device, wherein the first intervening device is configured to connect to a second intervening device such that the second intervening device performs (1) connecting to a second access device, (2) receiving a second message from the second access device, the second message including message data including at least second access device identification data and a digital signature generated by the second access device, the digital signature being generated by signing a hash of the at least second access device identification data with a private key of a public / private key pair associated with the second access device, and (3) relaying the second message to the first intervening device; receiving, by the user device proximate to the first access device, the second message including the message data from the first intervening device; determining, by the user device, that the second message is invalid based at least in part on extracting the hash of the at least second access device identification data from the digital signature, comparing the hash to a second hash generated from the message data, and determining that the message data has been altered by the first intervening device or the second intervening device when the hash does not match the second hash; and automatically terminating, by the user device, any further interaction with the second access device.

14. The method of claim 13, wherein the message data further comprises a public key of the public / private key pair associated with the second access device.

15. The method of claim 14, wherein determining that the second message is invalid further comprises: obtaining, by the user device, the hash from the digital signature using the public key; and generating, by the user device, the second hash of the message data.

16. The method of claim 13, further comprising: presenting, by the user device, the first access device identification data to a user of the user device in a request to interact with the first access device; and receiving, by the user device, confirmation from the user that the user wants to interact with the first access device.

17. The method of claim 13, wherein the intervening device is communicatively connected with the user device via a short-range wireless communication protocol. ​ ​

Images