[PreInternet01]

Sorry, but as someone who is involved with the development of contactless payment terminals, this just isn't a practical attack.

The phase where the relaying is supposed to happen (between the terminal sending its actual challenge and receiving the response) already employs a very short timeout (a millisecond or less, definitely not anywhere near a network round-trip to, well, anywhere).

There is a 'card selection' phase that may take (much) longer, as well as various retries, but the key bits (pun intended) of the exchange are only valid in that very short window.

Also, upwards of 80% of all point-of-sale transactions in some northern-European countries are NFC these days, and if any of this had truly any large-scale applicability, people would definitely have noticed...

[eknkc]

In Turkey when the contactless payments became ubiquitous one concern / urban myth was that people were using actual pos devices in public transport to lift money from wallets at back pockets and stuff. I guess that would work but that kind of fraud gets shut down pretty fast.

Relaying the thing seems like a workable thing but the timeout aspect is interesting. I wonder how fast can a short direct radio link would operate. Say someone inside an Apple store relays a card from another shopper while the accomplice checks out. In the line of sight of victim?

[PreInternet01]

> In the line of sight of victim

Yeah, you can actually check out the details in https://www.emvco.com/specifications/contactless-specificati... -- relevant parameter is "Device Estimated Transmission Time For Relay Resistance R-APDU", which is specified as "typically 1.5ms".

That's already hard to achieve reliably (in-store WiFi is right out, but possibly Bluetooth?) but would definitely make the required on-device malware even more complicated...

[eknkc]

Also, the underlying processing also takes some time obviously. Hence the 1.5ms timeout. If the cards take 0.5ms on average to respond in real world that leaves even less time to relay.

But I bet in close proximity, sub 1ms would not be a big deal for specialized hardware. Just flood the room with infrared if it gets the job done.

[swatcoder]

> The phase where the relaying is supposed to happen (between the terminal sending its actual challenge and receiving the response) already employs a very short timeout (a millisecond or less, definitely not anywhere near a network round-trip to, well, anywhere).

Sincere question: is that enforced by some certification process?

Because for anything that isn't strictly audited, I wouldn't assume that your own wise practices are universally applied. In fact, things like timeouts in particular are often treated very informally by engineers and often face pressure from product people for more leniance to improve the happy path user experience. Until real exploits like this become widely known, people can be really quite sloppy about this stuff.

> Also, upwards of 80% of all point-of-sale transactions in some northern-European countries are NFC these days, and if any of this had truly any large-scale applicability, people would definitely have noticed...

I don't think the article is suggesting this is an epidemic that threatens nfc payments at some large scale, and highlights the prerequisites for pulling it off. All they seem to be reporting is that it's acheivable, inviting to malicious actors, and seems to be happening in the wild.

[PreInternet01]

> is that enforced by some certification process

Yes, pretty much any NFC payment solution has to be EMVCo (Eurocard/Mastercard/Visa) licensed, and relay resistance is an explicit part of that.

> seems to be happening in the wild

Nah, NFC is so ubiquitous that would have been a lot more noisy.

[nurple]

Yeah, I realized this was a low-quality discussion when I got to the part where the author is basically stumping for security through obscurity as part of the solution.