The pre-play vulnerability in Chip and PIN | Hacker News Reader

The pre-play vulnerability in Chip and PIN

lightbluetouchpaper.org

28 pointsedward17 comments

How fast will the chip and pin card respond to requests? Does built-in rate-limiting (or just limitations of the chip on the card) mitigate this attack? How big is the authentication keyspace?

It sounds (from the brief; Reading the paper now) like this is a fairly standard replay attack. The terminal generates a transaction id, asks the card to sign it, then transmits that to the bank to prove identity. In this case, it's a 'pre-play', because the bank verifies that it's never seen the signature before by blacklisting the transactionid. This is not very effective if you can keep retrying.

It looks like they do give some numbers: "Thirty seconds is the standard authorisation time limit; this might allow for more than 100 transactions to be skimmed". That's not a whole lot, in a truly random 32 bit space, but in a world where many ATMs have predictable or deterministic sequence numbers, that's plenty for a chosen plaintext attack.

The attack works like this: You run a shady merchandise store. You hack your card reader; Instead of generating one ARQC for one transaction, when the customer enters their card and pin it generates five. One for your real transaction, one for four other specially chosen numbers.

You then take your special chip+pin card, armed with the public credentials of that card, and responses to those four transactions, to the local market with a freestanding ATM. You kick out the power to the ATM, "accidentally", causing the state of the ATM to be known. Then, you withdraw cash; A few hundred, or whatever's in the account. The ATM asks your card for a signature of it's 'random' number, but the 'random' number is one of the four you copied from the card in step one.

As the authors pointed out: "The deeper protocol design ﬂaw is that while the terminal generates the random number, it is the issuing bank that relies on it"

Somewhat counter-intuitively, security flaws in banking can be beneficial for customers.

The argument is simply that security is hard for clients; passwords and PINs get written down no matter how much you'd like them not to. However, if a system is theoretically secure, then the burden of security falls increasingly on the user, and getting fraudulent transactions reversed becomes ever more difficult. This makes online banking riskier for the customer.

In practice, the existence of previous vulnerabilities like this one hasn't helped customers get off the hook for fraudulent transactions because they couldn't prove the exploits were actually used against them. There's reason to believe the previous Chip and PIN vulnerability was being exploited in the wild but all the customers were still liable for all the charges.

Edit: with the previous attack, some of the banks had logs that would prove whether it was used but deleted them.

Maybe. I'm still unhappy that my bank stores my password as a case-insensitive string.

Url changed from http://www.theregister.co.uk/2014/05/19/chip_and_skim/, which points to this one.

By the way, had any payment system ever experimented with putting a cheap LCD display and a keypad on the card itself? Such card won't be really usable (most ATMs I've seen just gulp the whole card, although most POS terminals require inserting 2-3cm deep, just enough to connect to the chip), but as an experiment - that would probably solve many issues related to necessity to trust to terminal.

I've seen prototype NFC cards with E-ink screens and buttons that do exactly this. They can extract enough power from the NFC link to update the e-ink screen.

Doesn't solve the problem raised in this article though, which is authenticating the card. The problem is trusting the terminal you are using the card with - because the terminal is responsible for verifying that the card is genuine, a modified terminal can make any card appear as genuine.

Yeah I saw a card with a screen demoed ages ago which generated one-time-use credit card numbers (or something like that), which is surely the way it should be done. It's so crazy that once I've given someone some numbers they can just take money from me.

We really ought to completely skip over Chip and PIN to something like Google Wallet or another NFC system...

What about Google Wallet and NFC do you think is more secure than the EMV system?

Google Wallet actually uses the same technology as Chip+PIN, EMV (Visa payWave).

^ This. Google Wallet uses the same underlying technology as EMV. The only difference is the commands are being sent wirelessly (by NFC) rather than a direct physical connection between EMV chip and terminal.

I'd rather not have to pay for things using a device that costs more than what's in my checking account.

In a fantastical world yes. Google wallet and NFC require one thing that means they can't be readily adopted as the main method of payment - power, and more specifically, personal power. In the real world, relying on a system that requires such a fragile device to be a) powered up and b) functioning, is a Bad Idea. Notes can be washed, ripped and screwed up and still act as legal tender, a bank card is resilient to most conditions and has 2 levels of redundancy beyond the chip (magstripe and raised lettering - the problem with any major payment method is that it has to have failsafes. Imagine the NE (and specifically NYC) had another blackout - how do people think that would go if all methods of payment had to be powered? Even last time, you could still use cards with the traditional click clunk machines.

Chip and pin (and paywave, a nfc like solution) are great but they require failsafes to work consistently.

Chip-and-PIN as a very broad concept¹ is fine. It's EMV implementation has issues - requirement to trust POS terminal, MITM, legacy magnetic tracks and so on.

¹) When we mean just that there's a card with secured microprocessor holding the keys and some method that card's owner use to authenticate with that microprocessor.

Is it even EMV that has issues? This attack rather assumes a bad RNG. No doubt some hardware with bad RNGs exist, but this would cause problems for any crypto system. It's not like EMV is somehow uniquely vulnerable to bad RNGs when other systems using cryptography aren't.

There's also the Google Wallet Card [1]. Yes, it is still a card with a PIN, but it is tired to a limited access account that can be loaded in seconds from your phone. This provides additional safeguards in that the attacker can only gain access to what you've loaded, but the Google Wallet app will also send a notification to your device when it has a transaction - usually before my card is handed back to me. If the card were ever compromised, such as using it at Target when they were cracked, it is very easy to request a new card and invalidate the old one.

[1] https://wallet.google.com/cardRequest

Reply on news.ycombinator.com