Methods and systems for detecting relay attacks

Abstract

A method for preventing relay attacks between a first device and a second device is disclosed. The method includes the first device providing a command message, receiving a request message, and providing a response message to the second device. A time period between receiving the command message and the first device sending the response message is compared with another time period between sending the command message and the second device receiving the response message. If these time periods substantially match, the first device can ensure that no relay attack has occurred.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2017 / 022476, international application date of March 15, 2017, and Chinese national phase application number 201780088389.1, entitled "Method and System for Relay Attack Detection".

[0002] Cross-references to related applications

[0003] not applicable. Background Technology

[0004] Relay attacks are possible in both contactless and contactless access transactions, such as payment transactions. For example, Figure 1 The victim's contactless card 40 is shown, which can be remotely located relative to a contactless terminal 10 at a resource provider such as a merchant.

[0005] Although the contactless card 40 and the contactless terminal 10 are geographically separated in this example, an attacker (e.g., two people working together to steal information or defraud legitimate users) can use two NFC-enabled phones 20 and 30 and two smartphone applications 20A and 30A on those phones to perform a relay attack. In a typical relay attack, the attacker uses phone A 30 with an NFC reader mode application to tap the contactless card 40 in the victim's pocket and communicate with it. The attacker can use phone B 20 with application 20A to tap the contactless terminal 10 at a merchant or other resource provider and communicate with it. The two applications 20A and 30A on the two phones 20 and 30 are connected via mobile internet 50.

[0006] Command messages issued by contactless terminal 10 are relayed from phone B 20 to phone A 30 and then received by the victim's contactless card 40. The victim's contactless card 40 then responds to the command messages. Information on access card 40 (e.g., payment information such as the primary account (PAN)) can then be relayed from phone A 30 to phone B 20 and then back to contactless terminal 10. By performing such a relay attack, an attacker can use the victim's contactless card 40 to perform access transactions (e.g., purchase transactions) without taking possession of the victim's card 40. While this particular example involves a merchant, it should be understood that this problem may exist in other situations requiring access to resources (e.g., attempting to enter a building or attempting to access data inside a computer).

[0007] As shown above, data is transmitted between two legitimate devices (contactless terminal 10 and contactless card 40) without any change (or with minimal change). An attack detection mechanism is needed to address this issue, preferably without substantially altering the existing access transaction infrastructure.

[0008] The embodiments of the present invention solve these and other problems. Summary of the Invention

[0009] Embodiments of the present invention relate to methods and systems that can prevent relay attacks between portable devices and access devices, thereby preventing attackers from accessing data they are not authorized to access.

[0010] One embodiment of the present invention relates to a method. The method includes generating a command message by the first device and sending it to the second device during a transaction between a first device and a second device. In some embodiments, the first device may be an access device such as a POS terminal, and the second device may be a card such as a payment card.

[0011] Subsequently, the second device generates a first request message and sends it to the first device. Then, the first device receives the first request message, generates a first response message, and sends it to the second device. The first request message may be a first wait time extension request message.

[0012] At a certain point in time, when the second device is ready to respond to a command message, a data message is generated by the second device and sent to the first device. This data message includes an encrypted value comprising an encrypted first time period. The first time period can be determined by the second device and can be associated with the command message, the first request message, and / or the first response message. For example, the first time period can be measured between the time the second device receives the command message and the time the second device sends the first request message to the first device. The method also includes decrypting the encrypted value to determine the first time period and then comparing the first time period with a second time period determined by the first device. The second time period can be associated with the command message, the first request, and / or the first response. For example, the second time period can be measured between the time the first device sends the command message to the second device and the time the first device receives the first request message. If the first time period and the second time period are not within a predetermined threshold, the second device can record that the first time period and the second time period are not within the predetermined threshold and can optionally initiate a transaction rejection. In some embodiments, the access device can stop the transaction or can display an error message. If the first time period and the second time period are within the predetermined threshold, the first device can allow the transaction to continue.

[0013] Another embodiment of the present invention relates to a first device configured to perform the above-described method.

[0014] Another embodiment of the invention relates to a method comprising: receiving a command message from a first device by a second device, and then generating a first request message. The second device then sends the first request message to the first device. The second device subsequently generates a data message. The data message may be a command message response message and may include an encrypted value. The encrypted value may include a first time period determined by the second device. The first time period may be associated with the command message, the first request message, and / or the first response message. For example, the first time period may be measured between the time the second device receives the command message and the time the second device sends the first request message to the first device. Once the data message is generated, it can be sent to the first device. After receiving the data message, the first device compares the first time period with a second time period determined by the first device. The second time period may be associated with the command message, the first request message, and / or the first response message. For example, the second time period may be measured between the time the first device sends the command message to the second device and the time the first device receives the first request message.

[0015] Another embodiment of the present invention relates to a second device configured to perform the above-described method.

[0016] These and other embodiments of the present invention will now be described in more detail with reference to the accompanying drawings and the "Detailed Description". Attached Figure Description

[0017] Figure 1 This is a system diagram illustrating a relay attack.

[0018] Figure 2 A block diagram of a system including an access device and a portable device is shown, along with methods that can be performed in the illustrated system.

[0019] Figure 3 A block diagram of a system including an access device and a portable device is shown, along with a description of exemplary command messages and responses that can be transmitted between the access device and the portable device.

[0020] Figure 4 A block diagram of a portable device according to an embodiment of the present invention is shown.

[0021] Figure 5 A block diagram of an access device according to an embodiment of the present invention is shown.

[0022] Figure 6 A system diagram including access equipment and buildings is shown.

[0023] Figure 7 A system diagram illustrating the payment processing system is shown. Detailed Implementation

[0024] One embodiment of the present invention relates to a method. The method includes generating a command message by the first device and sending it to the second device during a transaction between a first device and a second device. In some embodiments, the first device may be an access device such as a POS terminal, while the second device may be a card such as a payment card. Note that the terms "first," "second," etc., are not limiting but can be used as labels to refer to different devices or objects.

[0025] Subsequently, the second device generates a first request message and sends it to the first device. Then, the first device receives the first request message, generates a first response message, and sends it to the second device. The first request message may be a wait time extension request message.

[0026] At a certain point in time, when the second device is ready to respond, a data message is sent from the second device to the first device. This data message includes an encrypted value comprising an encrypted first time period. The first time period can be determined by the second device and can be measured between the time the second device receives a command message and the time the second device sends a first request message to the first device. The method also includes decrypting the encrypted value to determine the first time period and comparing the first time period with a second time period determined by the first device. The second time period can be measured between the time the first device sends the command message to the second device and the time the first device receives the first request message. If the first time period and the second time period are not within a predetermined threshold, the second device can record that the first and second time periods are not within the predetermined threshold and can optionally reject the transaction. If the first and second time periods are within the predetermined threshold, the first device can record that the first and second time periods are within the predetermined threshold and can optionally allow the transaction to proceed. The first device can also decrypt encrypted unpredictable numbers and multiple request messages sent by the second device in the data message.

[0027] In embodiments of the invention, the threshold value can vary, but exceeding the threshold may indicate a potential relay attack. For example, if the difference between the first time period and the second time period is greater than, for example, 10%, 20%, or 30% of either the first or second time period value. For instance, first and second time periods of 15.00 milliseconds and 15.02 milliseconds, respectively, are sufficiently close and therefore within the threshold. Conversely, if the first and second time periods are 15 and 20 milliseconds, respectively, then this may exceed the threshold.

[0028] Specific embodiments of the invention may include a portable device sending SWTX (Extended Waiting Time) message data with specific characteristics of signature and protection. An external observer (attacker) is unaware of the SWTX data prior to transmission. These characteristics may include (i) an unknown number of SWTX requests, (ii) an unknown time period associated with the SWTX transmission, and (iii) session-based unpredictable WTXM parameters (e.g., random numbers) in the transmitted SWTX message.

[0029] This mechanism eliminates attack devices that could potentially identify early SWTX exchanges quickly enough and send messages immediately before the original exchange ends. Such attack devices would need to retransmit every bit of the SWTX message. This introduces delays on the order of microseconds or approximately microseconds because the attacker is unaware of the WTXM parameters and the timing of the SWTX message transmission.

[0030] Any attacker's device attempting to bypass the embodiments of this invention would need to be complex and require significantly stronger timing (less than 1 millisecond, possibly even less than 10-20 microseconds). The solution provided by the embodiments of this invention will prevent attacks using mobile phones that introduce delays of several milliseconds. If necessary, terminal manufacturers can limit the protection provided by the embodiments of this invention to the nanosecond level. This will make it more difficult for attackers, forcing them to create more complex devices. Current contactless terminals are expected to be more precise than the 10-microsecond level.

[0031] In some implementations, certain parameters associated with SWTX are known only to legitimate objects in the system (i.e., portable devices and access devices). This can be achieved in the following ways, but is not limited to:

[0032] 1. During a transaction, an access device (e.g., a terminal) may provide unpredictable SWTX parameters / timing and unpredictable numbers to a portable device (e.g., a card) in a secure manner (signature, etc.). The portable device (e.g., the card) determines these parameters and applies them to the lower operational layer to be implemented.

[0033] 2. Portable device manufacturers load SWTX parameters into portable devices for use during transactions. These parameters can be securely forwarded to the accessing device.

[0034] 3. Portable devices internally generate unpredictable SWTX parameters and securely notify accessing devices.

[0035] 4. Portable devices and access devices can partially generate and share parameters. For example, an unpredictable number can be generated by a portable device, while the access device sends multiple SWTXs and SWTX timings.

[0036] Before discussing embodiments of the present invention, some terms will be described.

[0037] "Portable device" can include any suitable device that can be operated by a user. Examples of portable devices can include mobile communication devices (e.g., mobile phones), payment devices (e.g., credit cards, debit cards, etc.), user access devices such as access badges, etc. Portable devices may store sensitive information such as payment credentials (e.g., master account number, token, expiration date, etc.) and access credentials.

[0038] "Mobile communication device" can be an example of a "communication device" that can be easily carried. Examples of remote communication capabilities include using mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that provides access to a network (e.g., the Internet or a private network). Examples of mobile communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptop computers, personal music players, handheld dedicated readers, etc. Other examples of mobile communication devices include wearable devices such as smartwatches, fitness trackers, anklets, rings, earrings, etc., and automobiles with remote communication capabilities. In some embodiments, a mobile communication device can be used as a payment device (e.g., the mobile communication device can store and transmit payment credentials for transactions). Mobile communication devices can also include vehicles such as cars with remote communication capabilities.

[0039] "Payment device" can include any suitable device that can be used to conduct financial transactions, such as issuing payment credentials to merchants. Suitable payment devices can be handheld and compact, allowing them to fit into a user's wallet and / or pocket (e.g., pocket-sized). Example payment devices may include smart cards, keychain devices (e.g., Speedpass available from Exxon-Mobil Corp.), etc. TM Other examples of payment devices include payment cards, smart media, transponders, etc. If the payment device is in the form of a debit card, credit card, or smart card, it may optionally have features such as a magnetic stripe. Such devices can operate in contact or contactless modes.

[0040] A "credential" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authorization. A credential can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can serve as confirmation.

[0041] A “payment voucher” may contain any suitable information associated with an account (e.g., payment account and / or payment device associated with said account). Such information may be directly related to the account or may be derived from account-related information. Examples of account information may include PAN (primary account or “account number”), username, expiry date, and verification values ​​such as CVV, dCVV, CVV2, dCVV2, and CVC3 values.

[0042] A "token" can be an alternative value for a credential. A token can be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, and so on.

[0043] A "payment token" may contain an identifier for a payment account, serving as a substitute for an account identifier such as a primary account number (PAN). For example, a payment token may include a string of alphanumeric characters that can be used as a substitute for the original account identifier. For instance, the token "4900 0000 0000 0001" could be used in place of the PAN "4147 0900 0000 1234". In some implementations, the payment token may be "preserved format" and may have a numerical format consistent with account identifiers used in existing transaction processing networks (e.g., the ISO 8583 Financial Transaction Message Format). In some implementations, the payment token may replace the PAN in initiating, authorizing, settling, or resolving payment transactions, or represent the original document in other systems where the original document is typically provided. In some implementations, the payment token may be generated such that the original PAN or other account identifier cannot be computationally derived from the token value. Additionally, in some implementations, the token format may be configured to allow the entity receiving the token to recognize it as a token and identify the entity that issued the token.

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

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

[0046] A “merchant” can typically be an entity that participates in transactions and can sell goods or services or provide access to goods or services.

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

[0048] An "authorizing entity" can be the entity requesting authorization. Examples of authorizing entities include publishers, government agencies, document repositories, access administrators, and so on. Authorizing entities have the authority to operate authorized computers.

[0049] "Issuer" can typically refer to a business entity (e.g., a bank) that maintains a user's account. Issuers can also issue payment credentials to consumers that are stored on portable devices such as cell phones, smart cards, tablets, or laptops.

[0050] An "access device" can be any suitable device that provides access to a remote system. Access devices can also be used to communicate with a merchant's computer, transaction processing computer, authentication computer, or any other suitable system. Access devices can typically be located anywhere suitable, such as at the merchant's location. 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 from or associated with mobile communication devices or payment devices. In some implementations where the access device may include a POS terminal, any suitable POS terminal can be used, and any suitable POS terminal may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless operating mode. For example, a demonstrative card reader 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 implementations, a cellular phone, tablet, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or “mPOS” terminal.

[0051] An "authorization request message" can be an electronic message requesting authorization for a transaction. In some implementations, 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 implementations 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 contain an issuer account identifier that can 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 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, buyer's bank identification number (BIN), card acceptor ID, information identifying the item being purchased, and any other information that can be used to determine whether the transaction is identified and / or authorized.

[0052] 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 transaction processing computer. An authorization response message may contain one or more of the following status indicators, used only as examples: Approval—the transaction is approved; Rejection—the transaction is not approved; or Call Center—a response suspending further information, requiring the merchant to call the toll-free authorization number. An authorization response message may also contain 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. This code can serve as evidence of authorization.

[0053] A "server computer" can comprise 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 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.

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

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

[0056] Figure 2 A block diagram of a system including access device 102 and portable device 104 is shown. Access device 102 may be an example of a first device, and portable device 104 may be an example of a second device. Access device 102 may be a terminal, while portable device 104 may be a mobile device, such as a mobile phone or a card.

[0057] Access device 102 and portable device 104 can typically be accessed via technologies such as NFC (Near Field Communication) and Bluetooth. TM Bluetooth TM Direct short-range wireless communication protocols such as low-energy (BLE) and infrared communicate with each other.

[0058] Prior to step S150, access device 102 may generate a command message that instructs portable device 104 to perform some type of action. The action could be, for example, retrieving stored data within portable device 104 and sending it to access device 102. In step S150, the command message may be sent to portable device 104 wirelessly, for example, using an RF signal. An example of a command message is provided below. Figure 3Steps S202, S206, S210, and S214 are shown in the diagram. These steps are described in more detail below. The transmission of command messages, such as these command messages, to portable device 104 results in some type of command response message being issued from portable device 104. The command response message may be an example of a data message, which can provide the information requested in the command message sent in step S150.

[0059] In step S152, portable device 104 may not respond immediately to access device 102. During legitimate interactions between portable device 104 and access device 102, portable device 104 may fail to respond for various reasons. For example, portable device 104 may take longer than usual to retrieve the data requested by command message S150. If portable device 104 experiences a response delay, it may generate a first wait time extension request message.

[0060] In an embodiment of the invention, the waiting time extension request message can be generated by the portable device 104 and sent to the access device 102 as a means of preventing relay attacks, and it is not necessary to assert based on the determination that the portable device 104 is experiencing a response delay. Therefore, the portable device 104 can be programmed to generate and send first waiting time request messages S152, S154 to the access device 102 at an unpredictable, arbitrary, or predetermined time after the portable device 104 receives the command S150.

[0061] Once generated, in step S154, a first wait time extension request message can be sent to access device 102. The first wait time extension request message may include a first unpredictable number, such as WTXM1. The time interval between the time when portable device 104 receives command S150 and the time when portable device 104 sends the first wait time extension request can be T1. T1 can be, for example, 35 milliseconds. The time interval between the time when access device 102 sends command S150 and the time when access device 102 receives the first wait time extension request S154 can be t1. For example, if no relay attack occurs, t1 can be substantially the same as T1. For example, if no relay attack occurs, t1 might be 35.02 milliseconds. The value t1 can be temporarily stored in the memory of access device 102.

[0062] After receiving the first waiting time extension request message S154, in step S156, the access device 102 may send a first waiting time extension response message to the portable device 104. The first waiting time extension response message S156 acknowledges receipt of the first waiting time extension request message S154.

[0063] If the portable device 104 still cannot respond to the initial command S150, it can generate a second waiting time extension request S158 under normal circumstances. However, as mentioned above, the second waiting time extension request S158 can be sent by the portable device 104 to the access device 102 as a means of preventing relay attacks. Therefore, the transmission of the request can be performed even if the second waiting time extension request is not based on the processing delay of the portable device 104. Then, in step S160, the second waiting time extension request S158 can be sent to the access device 102. The transmission of the second waiting time request in S160 can occur at any, calculated, or predetermined time known to the portable device 104. The second waiting time extension request message can also include a second unpredictable number, such as WTXM2.

[0064] The time interval between the time when portable device 104 receives the first wait time extension response S156 and the time when portable device 104 sends the second wait time extension request S162 can be T2. For example, T1 can be 12 milliseconds. The time interval between the time when access device 102 sends the first wait time extension response S156 and the time when access device 102 receives the second wait time extension request S160 can be t2. For example, if there is no relay attack, t2 can be 12.02 milliseconds. The value t2 can be stored by access device 102 in the memory of access device 102.

[0065] After receiving the second wait time extension request S160, the access device 102 can generate a second wait time extension response S162 and send it to the portable device 104. This will happen if the access device 102 has not yet received a complete response to the initial command S150.

[0066] If the portable device 104 requires more time to respond, steps S154, S156, S160, and S162 can be repeated as needed. However, note that the access device 102 may have a timeout period, which sets a limit on how much waiting time is allowed before the access device 102 terminates its interaction with the portable device 104 to extend the request.

[0067] In step S164, when the portable device 104 is able to respond to the command in step S150, the portable device 104 may generate the requested data (e.g., in response to command S150) to send an appropriate data response message from the portable device 104 to the access device 102. In addition to the requested data, the data response message may also include an encrypted value. The encrypted value may include information relating to the described request and response messages. For example, the encrypted value may include, in encrypted form, multiple request messages sent by the portable device 104 to the access device 102, values ​​T1 and T2, and a first unpredictable number and a second unpredictable number (or other parameters). One or more of these data may be concatenated and then encrypted to form the encrypted value. The encrypted value may be included in the data response along with the requested data.

[0068] To generate an encrypted value, portable device 104 may have a pre-provided symmetric key, or may derive a symmetric key, which can then be used to encrypt data to form the encrypted value. Alternatively, the corresponding symmetric key may be pre-provided to access device 102, or derived therefrom. Alternatively, portable device 104 may receive a public key from access device 102 or another entity, and the corresponding private key may be held by access device 102. Portable device 104 can use the public key to encrypt data, and access device 102 can use the corresponding private key to decrypt the encrypted data. Any suitable encryption / decryption process can be used, including DES (Data Encryption Standard), Triple DES (Triple Data Encryption Standard), AES (Advanced Encryption Standard), ECC (Elliptic Curve Cryptography), etc.

[0069] In step S166, a data request containing the requested information and encrypted value can be sent from portable device 104 to access device 102.

[0070] In step S168, access device 102 can decrypt the encrypted value using the encryption key to recover multiple request messages sent from portable device 104 to access device 102, time periods T1 and T2, and a first unpredictable number and a second unpredictable number.

[0071] In step S170, after the access device 102 decrypts the encrypted value, the access device 102 can compare and / or analyze the latency extension data to determine whether a relay attack has occurred. More specifically, value t1 can be compared with T1, and value t2 can be compared with value T2. If the values ​​match (e.g., within a predetermined threshold), no relay attack has occurred. Furthermore, the number of latency extension requests received by the access device 102 can be compared with the number of latency extension requests indicated in the received data message. If the values ​​match, it indicates that no relay attack has occurred. Finally, the first unpredictable number and the second unpredictable number received in data message S166 can be compared with the first unpredictable number and the second unpredictable number received in the first latency extension request and the second latency extension request (S154, S160). If the numbers match, a replay attack is unlikely.

[0072] In step S172, the comparison result may be stored by access device 102 and may optionally be sent to portable device 104. Access device 102 may also continue the transaction. If the comparison result indicates that the transaction may be the subject of a relay or replay attack, access device 102 may store the information and may optionally terminate the transaction and / or display an error message.

[0073] The implementation is not limited to the specific processing flow described above. For example, in some implementations, instead of sending an encrypted value including the delay time extension data to command S150 in response S166, the encrypted value can be sent in any subsequent data transmission from portable device 104 to access device 102. For example, refer to... Figure 3 As described in more detail below, the command can be a “select command” S202, and the encrypted value can be sent in a “GPO response” S214 or a “read record response” S216, and does not need to be sent in the corresponding “select response” S204.

[0074] In another variation, in some implementations, the aforementioned request message may be characterized as a "protection request message." Such a protection request message (e.g., possibly including unpredictable numbers) may be sent first, after a specific command and before any actual request message (e.g., an actual delay extension request message sent in response to actual delays that the second device may experience).

[0075] In yet another variation, note that... Figure 2The time periods t1, t2, T1, and T2 shown do not necessarily need to be measured as illustrated. In embodiments of the invention, the first and second time periods can be associated with commands, first requests, and / or first responses in any suitable manner. For example, in some embodiments, T2 can be measured by the portable device 104 from the transmission of the wait time extension request S160 to the reception of the second wait time extension response S162. t2 can be measured from the reception of the second wait time extension request by the access device 102 to the transmission of the wait time extension response S162. Therefore, embodiments of the invention can compare the time period between any two consecutive messages received and transmitted by the portable device 104 with the time period between any two corresponding consecutive messages received and transmitted by the access device 102 to determine whether a relay attack has occurred.

[0076] Figure 3 This is a flowchart illustrating a more detailed interaction between access device 102 (an example of an access device) and portable device 104 (an example of a payment device) in a payment transaction. Figure 3 The various commands in can correspond to Figure 2 Command S150 in the above reference, and the response can correspond to the above reference. Figure 2 An example of the data message mentioned above.

[0077] In step 202, when access device 102 detects the presence of portable device 104, a selection command is sent from access device 102 to portable device 104. The selection command may be a PPSE selection command, which can be used to identify the payment environments supported by access device 102 and portable device 104. The command may also include information about which payment applications(e.g., a list of AIDs (Application Identifiers)) are available on portable device 104.

[0078] Upon receiving a command in S202, portable device 104 may include an application that can identify and process the request by recognizing a payment environment identifier (e.g., a PPSE (Proximity Payment System Environment) name) contained in the request, and respond by sending an available application response S204 back to access device 102. The available application response S204 may include a list of available AIDs and may include a payment environment identifier (e.g., a PPSE name). In some embodiments, the available application response S204 may be in the form of a selected PPSE response and may include PPSE document control information (FCI).

[0079] When access device 102 receives an available application response S204, access device 102 selects a suitable application from the list of applications received in the available application response S204 (e.g., by selecting an AID from the available AIDs received in the available application response S204). In some embodiments, the selected AID can be the highest priority AID available and supported by access device 102. Access device 102 can then send the application selection with the selected AID to the portable device 104. In some embodiments, the application selection can take the form of an AID selection command S206.

[0080] Upon receiving an application selection, the application on portable device 104 may send a terminal transaction data request to access device 102 to request transaction data that may be required to execute the transaction using the selected application / AID. In some implementations, the terminal transaction data request may be in the form of an AID selection response S208 and may include AID File Control Information (FCI) with the selected AID as a dedicated filename. The terminal transaction data request may include a list of transaction data identifiers requesting appropriate data from access device 102, and the list of transaction data identifiers may be in the form of a Processing Option Data Object List (PDOL). The transaction data requested by the application on portable device 104 may include a Terminal Transaction Qualifier (TTQ), authorized amount, other amounts, terminal country code, terminal verification result, transaction currency code, transaction data, transaction type, and / or unpredictable numbers. The terminal transaction data request may also include other data, such as FCI issuer discretion data, application identifiers, and language preferences.

[0081] Upon receiving a terminal transaction data request, access device 102 can send the terminal transaction data requested by the mobile application to the application of portable device 104. In some embodiments, the terminal transaction data may be sent in the form of a Get Processing Options (GPO) command S210, and the requested terminal transaction data may be included in a Processing Options Data Object List (PDOL). In some embodiments, the terminal transaction data (e.g., a Terminal Transaction Qualifier (TTQ)) may contain a transaction type indicator indicating whether access device 102 supports integrated chip-based transactions or magnetic stripe-based transactions. Therefore, in situations such as... Figure 3In the chip-based transaction illustrated, access device 102 may send a transaction type indicator in the terminal transaction data to indicate that access device 102 supports integrated chip-based transactions. In some embodiments, the terminal transaction data (e.g., a terminal transaction qualifier TTQ) may also include a Consumer Authentication Method (CVM) requirement indicator indicating whether access device 102 requires a CVM, and a CVM type indicator indicating the type of CVM supported by access device 102. Examples of CVMs that may be supported by access device 102 may include online PINs, signatures, and / or Consumer Device CVMs (CDCVMs) such as ciphers used on portable device 104.

[0082] Once the application on portable device 104 receives terminal transaction data, the application can increment its Application Transaction Counter (ATC), use at least some of the received terminal transaction data to generate dynamic transaction processing information, and send a set of transaction processing information containing the generated dynamic transaction processing information to access device 102. In some embodiments, the transaction processing information may be sent in the form of a GPO response S212. In some embodiments, the transaction processing information may include one or more Application File Locators (AFLs) that can be used by access device 102 as file addresses to read account data stored on portable device 104, and an Application Exchange Profile (AIP) that can be used to indicate the capabilities of the application.

[0083] For transactions based on integrated chips, according to some implementations, the transaction processing information may include a transaction cipher dynamically generated using a LUK (Limited Use Key), track-2 equivalent data, and additional data such as Issuer Application Data (IAD), Form Factor Indicator (FFI), Card Transaction Qualifier (CTQ), Password Information Data (CID), updated ATC and / or Application PAN Serial Number (PSN). In some implementations, the Issuer Application Data (IAD) may include a length indicator indicating the length of the IAD, a Password Version Number (CVN) indicating the version of the transaction cipher, a Derived Key Indicator (DKI) that can be used to identify the master key (e.g., the master key associated with the issuer used when generating the LUK), Card Verification Result (CVR), wallet provider ID, and / or derived data, such as the key index used when generating the LUK.

[0084] The Card Verification Result (CVR) may contain information about the CVM verification entity and the CVM verification type of the transaction. The CVM verification entity indicates which entity is performing the CVM verification for the transaction. The verification entity can be an access device (or terminal), a co-located security application, a trusted execution environment application, an application on a portable device 104, a remote server (e.g., the cloud), etc. The CVM verification type indicates the CVM method used for the transaction. The CVM method can be a password, biometrics (e.g., fingerprint), pattern lock (e.g., for screen lock), signature, or online PIN.

[0085] If the terminal transaction data received from access device 102 indicates that the CVM supported by access device 102 is a CDCVM, the CVM authentication entity and CVM authentication type can be set according to the account's configuration parameters. For example, if the account uses a password authenticated by the operating system of portable device 104 to support the CVM, the CVM authentication entity can be set to the operating system, and the CVM authentication type can be set to indicate that the CVM is a password. In some implementations, an indicator of CDCVM execution can be included in the Card Transaction Qualifier (CTQ) to indicate whether the CVM authentication entity has successfully authenticated the user using the CDCVM indicated by the CVM authentication type.

[0086] If terminal transaction data received from access device 102 indicates that a CVM is not required, the CVM verification entity and CVM verification type can be set to indicate that a CVM is not verified. In some implementations, the CVR may include additional data such as threshold indicators that indicate whether one or more usage restriction thresholds associated with LUK have been exceeded.

[0087] The Form Factor Indicator (FFI) may include information about the portable device 104. The FFI may indicate whether the portable device 104 is a standard card (e.g., an ID-1 card type as specified in ISO 7811), a mini card, a non-card form factor (e.g., a keychain, watch, wristband, ring, sticker, etc.), or a mobile phone. The consumer payment device characteristic indicator may indicate whether the portable device 104 can use a PIN (which may be separate from the PIN used during a transaction), whether it has a signature panel, whether it has a hologram, whether it supports card verification values ​​(e.g., CVV2), whether it can perform two-way messaging to exchange identification information between the issuer and the user, and / or whether it supports the use of cloud-based credentials (e.g., LUK, tokens, etc.). The FFI may also include a payment transaction technology indicator indicating that the portable device 104 supports contactless transactions (e.g., NFC).

[0088] After receiving transaction processing information, access device 102 may send an account data request to the application of portable device 104 to read additional account data that may be stored on portable device 104. In some embodiments, the account data request may be in the form of a read record command S214 and may include an application file locator (AFL) indicating the address or location of the account data that access device 102 is attempting to read. The AFL included in the account data request may correspond to the AFL in the transaction processing information provided from portable device 104.

[0089] In response to receiving an account data request from access device 102, portable device 104 may send account data stored at the location indicated by the AFL to access device 102. In some embodiments, the account data may be sent in the form of a read record response S216. The account data may include, for example, application use controls indicating the issuer's restrictions on the use and services allowed by the application, the cardholder's name, consumer-specific data, the issuer's country code, the token requester ID (e.g., whether a token was used), and / or other account-related data accessible at the AFL location.

[0090] Once the access device 102 has received the necessary data from the transaction processing information and / or one or more account data transfers, some or all of the data elements in the transaction processing information and / or one or more account data transfers can be used by the access device 102 to generate a transaction authorization request message, thereby requesting transaction authorization from the issuer. For example, in some embodiments, the transaction authorization request message may include at least track-2 equivalent data and a transaction cipher generated using LUK, and may authorize the transaction based on at least verifying that the transaction cipher was correctly generated and that the LUK used to generate the transaction cipher has not exhausted one or more restricted usage thresholds.

[0091] Figure 4 A block diagram of a portable device 400 according to an embodiment of the present invention is shown. The portable device 400 may include a number of components, including but not limited to a processor 402, and a secure memory 406, a computer-readable medium 408, and an external interface 404 operatively coupled to the processor 402.

[0092] External interface 404 may include contact or non-contact elements. An exemplary non-contact element may include an antenna for sending or receiving data from an external device, such as an access device. An exemplary contact element may include two or more electrical contacts that allow the portable device 400 to communicate with the external device, and then the portable device 400 and the external device are electrically connected through the electrical contacts.

[0093] The memory 406 can store credentials. As described above, credentials may include account identifiers, access data for accessing secure locations, etc.

[0094] Computer-readable medium 408 may include code executable by processor 402 to implement a method comprising: receiving a command message from a first device by a second device; generating a first request message by the second device; sending the first request message to the first device by the second device; generating a data message by the second device, wherein the data message includes an encrypted value comprising an encrypted first time period, the first time period being determined by the second device and associated with any of the aforementioned messages, for example, measured between the time when the command is received from the second device and the time when the second device sends the first request message to the first device; and sending the data message to the first device by the second device, wherein the first device compares the first time period with a second time period, the second time period being determined by the first device and associated with any of the aforementioned messages, for example, measured between the time when the command is sent from the first device to the second device and the time when the first device receives the first request message.

[0095] Figure 5 A block diagram of an access device 500 according to an embodiment of the present invention is shown. The access device 500 may include a processor 502. A portable device reader 504, an output element 506, a network interface 508, an input element 510, and a computer-readable medium / memory 512 may be operatively coupled to the processor.

[0096] Portable device reader 504 may include any suitable device capable of reading from, providing to, or writing data to a portable device. Suitable portable device readers include antennas, electrical contacts, etc.

[0097] Output element 506 may include any suitable device capable of outputting data. Examples of output element 506 may include a display screen, a speaker, and a data transmission device.

[0098] Network interface 508 may include an interface that allows access device 500 to communicate with an external computer.

[0099] Input element 510 may include any suitable device capable of inputting data to access device 500. Examples of input devices include buttons, touchscreens, touchpads, microphones, etc.

[0100] Computer-readable medium / storage 512 may include one or more data storage devices. Such data storage devices may store code or applications that enable access device 500 to perform the functions described herein. In some embodiments, the computer-readable medium may include code executable by processor 502 for implementing a method comprising: in a transaction between a first device and a second device, the first device generating a command message and sending it to the second device, wherein the second device subsequently generates a first request message and sends the first request message to the first device; the first device receiving the first request message; the first device generating a first response message; the first device sending the first response message to the second device; and the first device receiving a data message from the second device, the data message including an encrypted value comprising an encrypted first time period determined by the second device, the first time period being associated with a previously described message, for example, the time from when the command is received by the second device and the time from when the command is received by the second device. The time interval is measured between the time the second device sends the first request message to the first device; the first device decrypts the encrypted value to determine the first time interval; the first device compares the first time interval with a second time interval, the second time interval being determined by the first device and associated with any of the aforementioned messages, for example, measured between the time the command is sent from the first device to the second device and the time the first device receives the first request message; if the first time interval and the second time interval are not within a predetermined threshold, then the first time interval and the second time interval are recorded as not being within the predetermined threshold, and optionally, a transaction rejection is initiated; and if the first time interval and the second time interval are within the predetermined threshold, then the first time interval and the second time interval are recorded as being within the predetermined threshold, and optionally, the transaction is allowed to continue.

[0101] Figure 6-7 This illustrates different scenarios where portable devices are used in conjunction with access devices when attempting to access resources such as goods, services, or locations.

[0102] Figure 6 A block diagram of a building access system is shown. Figure 6 A portable device 610 operated by user 606 is shown. Portable device 610 can interact with access device 620 and transmit access data to access device 620. Access device 620 can locally verify the received access data, or it can communicate with a remotely located authentication server computer (not shown). The remotely located authentication server computer can verify that the access data is authentic and can send a signal indicating this back to access device 620. Access device 620 can then proceed to allow user 606 to enter building 630.

[0103] Figure 7A block diagram of a transaction processing system that can use a portable device with access to data is shown. Figure 7 A user 706 is shown who can operate portable device 210. User 706 can use portable device 710 to make payments for goods or services at a resource provider, such as a merchant. The resource provider can operate resource provider computer 730 and / or access device 720. The resource provider can communicate with authorization computer 760 (e.g., issuer computer) via transmission computer 730 (e.g., acquiring computer) and processing network 750 (e.g., payment processing network).

[0104] Processing network 250 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 Such as VisaNet TM The payment processing network is capable of handling credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet... TM It 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.

[0105] A typical payment transaction flow using a portable device 710 at an access device 720 (e.g., a POS location) can be described as follows. User 706 presents his or her portable device 710 to the access device 720 to pay for goods or services. The portable device 710 and the access device 720 interact so that access data from the portable device 710 (e.g., PAN, payment token, verification value, expiry date, etc.) is received by the access device 720 (e.g., via a contact or contactless interface). The resource provider computer 730 can then receive this information from the access device 720 via an external communication interface. The resource provider computer 730 can then generate an authorization request message, including the information received from the access device 720 (i.e., the information corresponding to the portable device 710) and additional transaction information (e.g., transaction amount, merchant-specific information, etc.), and send this information electronically to a transmission computer 740. The transmission computer 740 can then receive, process, and forward the authorization request message to a processing network 750 for authorization.

[0106] Generally, prior to a credit or debit card transaction, the processing network 750 has an agreement with each authorizing computer regarding how the transaction will be authorized for the issuer. In some cases, such as when the transaction amount is below a threshold, the processing network 750 can be configured to authorize the transaction based on its information about the user account without generating and sending an authorization request message to the authorizing computer 760. In other cases, such as when the transaction amount is above a threshold, the processing network 750 can receive the authorization request message, identify the issuer associated with the portable device 710, and forward the authorization request message to the authorizing computer 760 for verification and authorization. Once the transaction is authorized, the authorizing computer 760 can generate an authorization response message (which may include an authorization code indicating whether the transaction is approved or rejected) and transmit the electronic message to the processing network 750 via its external communication interface. The processing network 750 can then forward the authorization response message to the transmission computer 740, which in turn can transmit the electronic message, including the authorization indication, to the resource provider computer 730, and then to the access device 720.

[0107] At the end of the day or at some other suitable time interval, the transaction can be cleared and settled between the resource provider computer 730, the transmission computer 740, the processing network 750, and the authorization computer 760.

[0108] 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 the disclosure and 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.

[0109] 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 such as random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as CD-ROMs. Any such computer-readable medium may reside on or within a single computing device, and may exist on or within different computing devices within a system or network.

[0110] Different arrangements of the components depicted in the accompanying drawings or described above, as well as components and steps not shown or described, are also possible. Similarly, some features and sub-combinations are available and can be used without involving other features and sub-combinations. Embodiments of the invention have been described for illustrative purposes and not for limitation, and alternative embodiments will become apparent to the reader of this patent. Therefore, the invention is not limited to the embodiments described above or shown in the accompanying drawings, and various embodiments and modifications can be implemented without departing from the scope of the following claims.

Claims

1. A method comprising: In a transaction between a first device and a second device, the first device generates a command message and sends it to the second device, wherein the second device subsequently generates a first request message and sends the first request message to the first device. The first request message is received by the first device; The first device generates a first response message; The first device sends the first response message to the second device; The first device receives a data message from the second device, the data message including an encrypted value, the encrypted value including a first time period in an encrypted form, the first time period being determined by the second device and associated with the command message, the first request message and / or the first response message; The first device decrypts the encrypted value to determine the first time period; The first device compares the first time period with a second time period determined by the first device, the second time period being associated with the command message, the first request message, and / or the first response message; If the first time period and the second time period are not within the predetermined threshold, then record that the first time period and the second time period are not within the predetermined threshold, and initiate the rejection of the transaction; as well as If both the first time period and the second time period are within a predetermined threshold, then the first time period and the second time period are recorded as being within the predetermined threshold, and the transaction is allowed to continue. The encrypted value contains multiple request messages that have been sent in encrypted form from the second device to the first device, and the method further includes: The first device compares the number of request messages that have been sent from the second device to the first device with the number of request messages that have been received by the first device to determine whether a relay attack has occurred.

2. The method of claim 1, wherein the first request message is a time extension request message, and the first response message is a time extension response message, and wherein... The first time period is measured between the time the second device receives the command message and the time the second device sends the first request message to the first device. The second time period is measured between the time when the first device sends the command message to the second device and the time when the first device receives the first request message.

3. The method of claim 2, further comprising: after sending the first response message and before receiving the data message: The first device receives a second request message from the second device; The first device generates a second response message; The first device sends the second response message to the second device; Furthermore, the data message further includes a third time period in encrypted form, which is determined by the second device and measured between the time the second device receives the first response message and the time the second request message is sent from the second device to the first device; And the method described therein also includes: Decrypt the encrypted third time period; The first device compares the third time period with a fourth time period, the fourth time period being determined by the first device and measured between the time when the first response message is sent to the second device and the time when the second request message is received by the first device; If the third time period and the fourth time period are not within the predetermined threshold, then record that the third time period and the fourth time period are not within the predetermined threshold, and initiate the rejection of the transaction; and If the third time period and the fourth time period are within a predetermined threshold, then the third time period and the fourth time period are recorded as being within the predetermined threshold, and the transaction is allowed to continue.

4. The method of claim 3, wherein the first request message is a first time extension request message, the first response message is a first time extension response message, the second request message is a second time extension request message, and the second response message is a second time extension response message.

5. The method of claim 3, wherein the first time period and the third time period are different.

6. The method of claim 1, wherein the first device is an access device and the second device is a portable device.

7. The method of claim 1, wherein the first request message includes an unpredictable number, and wherein the encrypted value includes the unpredictable number in an encrypted form.

8. A first device, the first device comprising: processor; as well as A non-transient computer-readable medium, the non-transient computer-readable medium comprising: In a transaction between a first device and a second device, a command message is generated and sent to the second device, wherein the second device subsequently generates a first request message and sends the first request message to the first device; Receive the first request message; Generate a first response message; Send the first response message to the second device; Receive a data message from the second device, the data message including an encrypted value, the encrypted value including a first time period in an encrypted form, the first time period being determined by the second device and associated with the command message, the first request message and / or the first response message; Decrypt the encrypted value to determine the first time period; The first time period is compared with a second time period determined by the first device, the second time period being associated with the command message, the first request message, and / or the first response message; If the first time period and the second time period are not within a predetermined threshold, then record that the first time period and the second time period are not within the predetermined threshold, and initiate the rejection of the transaction; and If both the first time period and the second time period are within a predetermined threshold, then the first time period and the second time period are recorded as being within the predetermined threshold, and the transaction is allowed to continue. The encrypted value contains multiple request messages that have been sent in encrypted form from the second device to the first device, and the non-transient computer-readable medium further comprises: The number of request messages that have been sent from the second device to the first device is compared with the number of request messages that have been received by the first device to determine whether a relay attack has occurred.

9. The first device of claim 8, wherein the first request message is a time extension request message, and the first response message is a time extension response message, and wherein... The first time period is measured between the time the second device receives the command message and the time the second device sends the first request message to the first device. The second time period is measured between the time when the first device sends the command message to the second device and the time when the first device receives the first request message.

10. The first device of claim 9, wherein the non-transient computer-readable medium further comprises, after sending the first response message and before receiving the data message: Receive the second request message; Generate a second response message; Send the second response message to the second device; Furthermore, the data message further includes a third time period in encrypted form, which is determined by the second device and measured between the time the second device receives the first response message and the time the second request message is sent from the second device to the first device; Furthermore, the non-transient computer-readable medium further includes: Decrypt the encrypted third time period; The third time period is compared with the fourth time period, which is determined by the first device and measured between the time when the time extension response message is sent to the second device and the time when the second request message is received by the first device; If the third time period and the fourth time period are not within the predetermined threshold, then record that the third time period and the fourth time period are not within the predetermined threshold, and initiate the rejection of the transaction; and If the third time period and the fourth time period are within a predetermined threshold, then the third time period and the fourth time period are recorded as being within the predetermined threshold, and the transaction is allowed to continue.

11. The first device of claim 10, wherein the first request message is a first time extension request message, the first response message is a first time extension response message, the second request message is a second time extension request message, and the second response message is a second time extension response message.

12. The first device as claimed in claim 10, wherein the first time period and the third time period are different.

13. The first device as claimed in claim 8, wherein the first device is an access device and the second device is a portable device.

14. The first device as claimed in claim 8, wherein the first device is in the form of a terminal and the second device is in the form of a card.

15. The first device of claim 8, wherein the first request message includes an unpredictable number, and wherein the encrypted value further includes the unpredictable number in an encrypted form.

16. A method comprising: The second device receives command messages from the first device; The second device generates the first request message; The second device sends the first request message to the first device; The second device generates a data message, wherein the data message includes an encrypted value, the encrypted value includes a first time period, the first time period is determined by the second device, and is associated with the command message, the first request message, and / or the first response message; as well as The second device sends the data message to the first device, wherein the first device compares the first time period with a second time period, the second time period being determined by the first device and associated with the command message, the first request message, and / or the first response message. The encrypted value contains multiple request messages that have been sent in encrypted form from the second device to the first device, and The first device is programmed to compare the number of request messages that have been sent from the second device to the first device with the number of request messages that have been received by the first device to determine whether a relay attack has occurred.

17. The method of claim 16, wherein If the first time period and the second time period are not within a predetermined threshold, the first device records that the first time period and the second time period are not within the threshold, and initiates a rejection of the transaction between the first device and the second device; and If the first time period and the second time period are within a predetermined threshold, the first device records the first time period and the second time period as being within the predetermined threshold, and may allow the transaction to continue.

18. The method of claim 16, wherein the first request message is a time extension request message, and the first response message is a time extension response message, and The first time period is measured between the time when the second device receives the command message and the time when the second device sends the first request message to the first device. The second time period is measured between the time when the first device sends the command message to the second device and the time when the first device receives the first request message.

19. The method of claim 16, wherein the second device is a card, and the first device is an access device.

Images