I've always wondered about how modern contactless methods are more resistant to skimming. Couldn't someone compromise two machines and essentially MITM the NFC communcations, intercepting the card's response from the first machine, and replaying it against another remote machine, along with the PIN recorded from a camera? Though I suppose the ATM company could combat this by encoding the machine's ID or a nonce with the message that the card's smart chip responds to, so it only works when replayed on that first machine - is this what happens in practice?
> Though I suppose the ATM company could combat this by encoding the machine's ID or a nonce with the message that the card's smart chip responds to, so it only works when replayed on that first machine - is this what happens in practice?
Yes, more or less. The chip and contactless flows defined by EMV both require the card to generate a nonce for the transaction. The terminal also generates its own nonce[1].
Unfortunately "random" is a headache for a certain type of bureaucrat. They can't really do "random" or "unpredictable" and it needs somebody who actually understands what is going on to sit down and walk through how they can check whether to tick this box. For the Web PKI we had this problem extensively. No, if you set the top bit of this 128-bit integer, that's not 128 random bits. That's 127 random bits, the top one isn't random any more, see?
Anyway, the EMV test spec tells them to ensure the numbers are different not that they're random even though the cryptography requires randomness to work. So if you make terminals, the way to ensure you pass is not to use random numbers, as there's a tiny chance a random number fails the test. To pass, just ensure you emit a sequence of different numbers. For example 1, 2, 3, 4, 5. That's not random at all, but it's different and so it passes the test.
As you would expect this is an exploitable bug. Light Blue Touchpaper covered this years back.
> as there's a tiny chance a random number fails the test
There’s ~4e23 _grains of sand_ on Earth. There are more possible values in 128 bits than grains of sand on Earth.
Take it further. There are 10^11 stars in our galaxy. If every star in the Milky Way had a planet identical to Earth orbiting it, there would be ~4e35 grains of sand on all the Earths orbiting all the stars of the Milky Way.[1]
If you assigned each of those grains to its own value, we’d only need 0.11% of the possible values of 2^128.[2]
I think it’s safe to say those bureaucrats are wrong :)
Sure. As an engineer who knows what they're doing I of course agree with you. I'd argue with management that random is both obviously the correct choice and unlikely to cause compliance problems. But...
Here are some of the "Unpredictable numbers" from a series of EMV transactions reported in a paper in 2014:
F1246E04, F1241354, F1244328, F1247348
That's a 32-bit value, so not enough to count living humans, never mind grains of sand. And it's not very "Unpredictable", indeed the researchers have more data from the logs which allows them to predict with confidence future values from that same terminal, basically the low 15 bits are a clock which repeats every 32768 cycles, with cycles having a fixed duration of several milliseconds. The high bits, if they change, don't change for a prolonged period.
I'm a bit curious now how compliance with the spec is tested.
It certainly can't be done with "pure" unit tests, and it would be difficult to ensure sufficient entropy even with "impure" tests that examine multiple nonces generated in sequence.
Do you happen to have a link to the paper you mentioned?
... mentions these values and links a paper they wrote, I suspect it isn't the 2014 paper I was thinking about but it's on the same topic.
The good news is that in the years after this work, I believe the rules were tightened up, there's a good chance if you buy a brand new EMV terminal the people testing it wouldn't have accepted 1, 2, 3, 4, 5 as a series of "Unpredictable numbers", so crooks today are less likely to be able to exploit this, and more likely to get caught.
The bad news is that courts remain very easily persuaded that banks know what they're doing, and expert witnesses who can make it clear that the bank have no idea what they're doing and shouldn't be trusted more than a typical citizen are expensive. If it ends up being your word against a bank, the court is probably going to believe the bank.
From my understanding you can't really skim these cards as the cards sign some piece of data using a private key stored only on the card that never gets exposed in the transaction. I might be _totally_ wrong though.
That's pretty close: the private key alone can't prevent replays, since any material generated from just the private key could be recorded and replayed. Instead, the card mixes its private key with a nonce to produce a session key.
The magnetic stripe is just data. NFC is a handshake: the chip is a tiny MCU. There is still a root of trust required to prevent MITM, but the device would need to be compromised. This is why keys and certificate chains are stored in secure memory that is resistent to side channel, and even physical attack (it breaks easily and the die can't be shaved down).
“A tiny MCU” in this case means Microcontroller Unit, not Marvel Cinematic Universe. Don’t expect to find Antman running around on your chip preventing fraud.
Surely that’ll get you a one use token but not data good for repeat use? In addition you would have to send that to the network as a retailer yourself. So it would not be anonymous.
It’s completely useless. Because the terminal you’re using is involved in what gets signed, even if you replayed the data to a different but identical contactless terminal (say the next gas pump over) the signatures would fall apart and it wouldn’t work. The serial numbers and such are different.
Also there are transaction counters involved. So even if you could overcome that the processor would see that your card had two transactions with counter 268753 and reject the second. The terminal also has its own transactions counter mixed in too.
And even if you could overcome those I’m almost positive that timestamps are involved too. So even if you could replay the transaction to the same exact terminal and get around the transaction counter issue the time would be different and I think that would cause it to fail.
It really is a well designed system. It follows that software law that people can know absolutely everything about the process and it’s still secure as long as the private keys aren’t given away.
