Logical validation of devices against fraud

• US 10,373,167 B2
• Filed: 06/30/2016
• Issued: 08/06/2019
• Est. Priority Date: 06/30/2016
• Status: Active Grant

• Current Assignee: Block, Inc. (f/k/a Square, Inc.)
• Original Assignee: Square Inc (Block, Inc. (f/k/a Square, Inc.))
• Inventors: Zovi, Dino Dai, Klawe, Janek
• Primary Examiner(s): Kelly, Rafferty D
• Application Number:
  US15/199,917
• Publication Number:
  US 20180005243A1
• Time in Patent Office: 1,132 Days
• Field of Search: 235379
• CPC Class Codes: G06Q 20/382 insuring higher security of transaction
• CPC Class Codes: G06Q 20/4016 involving fraud or risk level assessment in transaction processing
• CPC Class Codes: G06Q 20/405 Establishing or using transaction specific rules
• CPC Class Codes: H04L 63/1433 Vulnerability analysis
• CPC Class Codes: H04L 63/1441 Countermeasures against malicious traffic countermeasures against attacks on cryptographic mechanisms H04L9/002
• CPC Class Codes: H04W 12/12 Detection or prevention of fraud

Abstract

Disclosed herein is a method and system to determine whether a payment terminal has been tampered with based on a comparison of attestation data received from the payment terminal. If the determination yields that the request has been approved, the terminal generates an attestation ticket having one or more validity conditions, wherein the validity conditions include expiration time that indicates the time after which the attestation ticket becomes invalid. The attestation ticket can be used as long as it is valid or until another trigger causes the ticket to be invalidated or regenerated.

Claims

1. A computer-implemented method for detecting security threats on a payment terminal capable of communicating with a payment object reader, the method comprising:

generating, by a tamper monitoring component of the payment terminal, a request for attesting security of the payment terminal;

sending, by the tamper monitoring component of the payment terminal, the request for attesting security of the payment terminal to a payment processing server;

generating, by a tamper detection component of the payment processing server, at least one command to scan or test the payment terminal against pre-determined test criteria;

sending, by the tamper detection component of the payment processing server, the command to the payment terminal;

executing, by the tamper monitoring component of the payment terminal, the command to generate attestation data indicative of one or more security threats;

determining, by the tamper detection component of the payment processing server, the attestation data based on the command, wherein attestation data includes at least one of a current state of the payment terminal, a previous state of the payment terminal, a risk rating, and a merchant profile saved on the payment terminal;

sending the attestation data from the tamper detection component of the payment processing server to the tamper monitoring component of the payment terminal;

determining, by the tamper detection component of the payment processing server, whether to approve or deny the request for attesting security based on a comparison of one or more of attestation data with known behavior;

if the determination yields that the request has been approved, further generating an attestation ticket having one or more validity conditions, wherein the one or more validity conditions include expiration time that indicates the time after which the attestation ticket becomes invalid; and

sending the attestation ticket to the payment terminal, wherein the attestation ticket indicates that the payment terminal is secure;

and

if the determination yields that the request has been denied, further generating another attestation ticket at least includes denial notification, wherein the denial notification indicates a reason for denial of the request; and

sending the other attestation ticket to the payment terminal, wherein the attestation ticket indicates that the payment terminal is not secure.

2. The method of claim 1, further comprising:

receiving, by the payment terminal, an attestation trigger, wherein the attestation trigger includes at least one of the following events;

connecting the payment object reader to the payment terminal using a wired connection, connecting the payment object reader to the payment terminal using a wireless connection, pairing the payment object reader to the payment terminal, installing a new payment application on the payment terminal, detecting re-location of the payment object reader or the payment terminal, re-starting the payment terminal, re-starting the payment object reader, detecting insertion of a payment object from a known fraudulent user, detecting a known fraudulent payment object, or detecting entry of a known fraudulent device within an established geo-fence; and

generating, by the tamper monitoring component of the payment terminal, the request for attesting security of the payment terminal based at least on the attestation trigger.

3. The method of claim 1, further comprising performing, by the payment terminal, a periodic scan of the payment terminal to generate a state of the payment terminal and a timestamp of the scan;

and

storing the state or transferring the state to the payment processing server at predetermined intervals to update validity of the attestation ticket.

4. The method of claim 1, further comprising:

generating the command based on a merchant identifier, a payment terminal identifier, a risk score, or an environmental parameter; and

generating a subsequent command based at least on the attestation data received from the payment terminal.

5. A method for processing payment transactions at a payment terminal, comprising:

generating, by a tamper monitoring component of the payment terminal, a request for attesting security of the payment terminal;

sending, by the tamper monitoring component of the payment terminal, the request for attesting security of the payment terminal to a payment processing server;

generating, by a tamper detection component of the payment processing server, at least one command to scan or test the payment terminal against pre-determined test criteria;

determining, by the tamper detection component of the payment processing server, attestation data based on execution of the command on the payment terminal, wherein attestation data includes a state of the payment terminal indicative of one or more signs of fraud or tampering of the payment terminal;

determining, by the tamper detection component of the payment processing server, whether to approve or deny the request for attesting security based on a comparison of one or more of attestation data with known behavior;

if the determination yields that the request has been approved, further generating an attestation ticket having one or more validity conditions, wherein the one or more validity conditions include expiration time that indicates the time after which the attestation ticket becomes invalid; and

sending the attestation ticket to the payment terminal, wherein the attestation ticket indicates that the payment terminal is secure;

and

if the determination yields that the request has been denied, further generating another attestation ticket that at least includes a denial notification, wherein the denial notification indicates a reason for denial of the request; and

sending the other attestation ticket to the payment terminal, wherein the attestation ticket indicates that the payment terminal is not secure.

6. The method of claim 5, further comprising:

performing, by the payment terminal, a periodic scan of the payment terminal to generate a state of the payment terminal and a timestamp of the scan; and

storing the state or transferring the state to the payment processing server at predetermined intervals to update validity of the attestation ticket.

7. The method of claim 5, further comprising:

configuring the command based on a merchant identifier, a payment terminal identifier, a risk score, or an environmental parameter; and

generating a subsequent command based at least on the attestation data received from the payment terminal.

8. The method of claim 5, further comprising:

receiving, by the payment terminal, an attestation trigger, wherein the attestation trigger includes at least one of the following events;

connecting a payment object reader to the payment terminal using a wired connection, connecting the payment object reader to the payment terminal using a wireless connection, pairing the payment object reader to the payment terminal, installing a new payment application on the payment terminal, detecting re-location of the payment object reader or the payment terminal, detecting insertion of a payment object from a known fraudulent user, detecting a known fraudulent payment object, or detecting entry of a known fraudulent device within an established geo-fence; and

generating, by the tamper monitoring component of the payment terminal, the request for attesting security of the payment terminal based at least on the attestation trigger.

9. The method of claim 5, wherein if the request is denied, implementing, by the payment processing server, a first corrective action and a second corrective action, wherein the first corrective action comprises one or more of aborting a transaction and querying the payment terminal, and wherein the second corrective action comprises one or more of removing power from one or more components of a payment object reader associated with the payment terminal or the payment terminal, disabling one or more components of the payment object reader or the payment terminal, and employing countermeasures at the payment terminal.

10. The method of claim 5, wherein the executing the command includes:

monitoring timing for one or more responses that yield the attestation data based on electrical characteristics, mechanical characteristics, or software characteristics of the payment terminal or a payment application executing on the payment terminal.

11. The method of claim 5, further comprising:

storing the attestation ticket or the attestation data on the payment terminal; and

presenting the attestation ticket in response to validation of a payment transaction or towards establishing a secure communication channel between the payment terminal and another device.

12. The method of claim 5, wherein the commands comprise one or more of error condition test commands, encryption-decryption test commands, hardware test commands, and message timing test commands.

13. The method of claim 11, further comprising encoding the attestation ticket using at least a hardware security key associated with the other device.

14. The method of claim 5, further comprising:

determining, by a controller communicatively coupled to a plurality of servers, including the payment processing server, a header field indicating address of the payment processing server or a risk score, wherein each server handles requests of a particular range of risk scores; and

routing the request to an appropriate server based on the header field.

15. A payment server, comprising:

a communication interface, wherein the communication interface is configured to receive a request for attesting to security of a payment terminal, and wherein the request comprises a frame of data corresponding to the payment terminal;

a transaction database comprising records, for the payment terminal and a plurality of additional payment terminals, of previous response messages from previous requests and predetermined test criteria; and

a processing element configured to;

generate at least one command to scan or test the payment terminal against the records;

obtain, from the payment terminal submitting the request, attestation data in response to the command;

determine whether to approve or deny the request for attesting security based on a comparison of one or more of attestation data with known behavior;

if the determination yields that the request has been approved, generate an attestation ticket having one or more validity conditions, wherein the one or more validity conditions include expiration time that indicates the time after which the attestation ticket becomes invalid; and

send the attestation ticket to the payment terminal, wherein the attestation ticket indicates that the payment terminal is secure;

and

if the determination yields that the request has been denied, generate another attestation ticket that at least includes a denial notification, wherein the denial notification indicates a reason for denial of the request; and

sending the other attestation ticket to the payment terminal, wherein the attestation ticket indicates that the payment terminal is not secure.

16. The payment server of claim 15, wherein the processing element is further configured to perform, by the payment terminal, a periodic scan of the payment terminal to generate a state of the payment terminal and a timestamp of the scan and store the state or transferring the state to the payment processing server at predetermined intervals to update validity of the attestation ticket.

17. The payment server of claim 15, wherein the processing element is further configured to configure the command based on a merchant identifier, a payment terminal identifier, a risk score, or an environmental parameter;

and

generate a subsequent command based at least on the attestation data received from the payment terminal.

18. The payment server of claim 15, wherein the processing element is further configured to receive, by the payment terminal, an attestation trigger, wherein the attestation trigger includes at least one of the following events:

connecting the payment object reader to the payment terminal using a wired connection, connecting the payment object reader to the payment terminal using a wired connection, pairing the payment object reader to the payment terminal, installing a new payment application on the payment terminal, detecting re-location of the payment object reader or the payment terminal, detecting insertion of a payment object from a known fraudulent user, detecting a known fraudulent payment object, or detecting entry of a known fraudulent device within an established geo-fence; and

generate the request for attesting security of the payment terminal based at least on the attestation trigger.

19. The payment server of claim 15, wherein the processing element is further configured to encode the attestation ticket using at least a hardware security key associated with another device.

20. The payment server of claim 15, wherein the processing element is further configured to update one or more test criteria for the command based on payment terminal characteristics, the monitored responses, the monitored timing, the previous payment terminal characteristics, the previous responses, and the previous monitored timing, wherein the payment server is configured to generate an update message including the updated test criteria and stored for use for a subsequent request.

21. The payment server of claim 15, further comprises a failover component configured to send the request for generating the attestation ticket to one component and a request for analyzing the attestation data for potential tampering to another component.

22. The payment server of claim 15, further comprises a hardware security module configured to store a key that uniquely identifies a payment object reader with which the payment terminal communicates.