Distance bounding against smartcard relay attacks

Steven Murdoch and I have previously discussed issues concerning the tamper resistance of payment terminals and the susceptibility of Chip & PIN to relay attacks. Basically, the tamper resistance protects the banks but not the customers, who are left to trust any of the devices they provide their card and PIN to (the hundreds of different types of terminals do not help here). The problem some customers face is that when fraud happens, they are the ones being blamed for negligence instead of the banks owning up to a faulty system. Exacerbating the problem is the impossibility of customers to prove they have not been negligent with their secrets without the proper data that the banks have, but refuse to hand out.

Using a fake terminal and custom circuitry we demonstrated that a fraudster can get away with charging an unwitting, honest customer’s card with a purchase he did not authorize. The importance of this demonstration was that it showed that even though the customer is diligent about keeping his PIN secret, he can still be defrauded. APACS, the UK payment association, say that they are unaware of any cases of relay attacks being used against Chip & PIN in the UK. The reason, we believe, is that even though the cost and the technical expertise that are required for implementing the attack are relatively low, there are easier ways to defeat the system. Methods such as card counterfeiting/theft, mail interception, and cardholder impersonation are routinely reported and are more flexible in deployment. These security holes are gradually being closed, but card fraud remains a lucrative industry — in 2006 £428m of fraud was suffered by UK banks. Criminals will adapt to the new environment and, to maintain their income, will likely resort to more technically demanding methods, so now is the time to consider how to prevent relay attacks for when that time arrives.

We propose a defense against the relay attack in the form of “distance bounding“. This will allow the payment terminal to measure the distance between itself and the card and decide, based on its risk settings, whether to accept the transaction. We have built such a system using an FPGA and demonstrated that it can reliably operate in the face of a capable attacker and discern the addition of short transmission distances. With EMV being the target application, we have made the design such that the additional cost is mostly absorbed by the terminal rather than the smartcard and that the customer-merchant “experience” is unchanged. If the banking industry adopts this extension to EMV, the risk from relay attacks would be negligible. We describe the engineering details in a paper (“Keep your enemies close: Distance bounding against smartcard relay attacks“) that will be presented in August at the 16th USENIX Security Symposium. Along with a description of the relay attack, we also discuss the security-economics aspects of customers bringing their own trusted device into the transaction, as well as the ineffectiveness of procedural and other technical solutions that were previously proposed.

3 thoughts on “Distance bounding against smartcard relay attacks

  1. You write in the paper that payment cards are starting to be issued without embossing. It’s not clear how widespread this is, as yet; I recently received new C+P cards, from two different UK banks, which are embossed like their predecessors were. Perhaps it’ll be a different story when they next expire. Not all merchants have converted, either; one of my cards was “zip-zapped” by a taxi driver in Brussels earlier this year.

  2. Ross Younger,

    “Electron” cards, which may not be used at all with manual imprint machines, have never been embossed.

  3. @Ross

    There does seem to be a mix. All of my cards are embossed, but one German Maestro card I’ve seen is not. I also remember one non-embossed card a colleague received from a UK bank, but I can’t remember which.

Leave a Reply to Steven J. Murdoch Cancel reply

Your email address will not be published. Required fields are marked *