
The pre-play vulnerability in Chip and PIN - edward
http://www.lightbluetouchpaper.org/2014/05/19/the-pre-play-vulnerability-in-chip-and-pin/
======
GauntletWizard
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"

------
nhaehnle
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.

~~~
makomk
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.

------
dang
Url changed from
[http://www.theregister.co.uk/2014/05/19/chip_and_skim/](http://www.theregister.co.uk/2014/05/19/chip_and_skim/),
which points to this one.

------
drdaeman
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.

~~~
TD-Linux
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.

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

~~~
drdaeman
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.

~~~
mike_hearn
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.

