Researchers reveal chip and PIN hack

Would standard crypto verification not prevent this ?

Today the signature of the transaction would indicate that the PIN was not verified if the card was properly configured.

But this does support the US decision to use EMV without PIN.

@Jonathan: no this does not explain why the US did not opt to use PIN.  This attack is only possible using Offline PIN (ICC verifies PIN with an Offline PIN Block stored in secure memory).  I will assume the attack vector uses the same approach as the original Cambridge MITM attack - and authorises with the ICC as Chip and Signature - whereas the POS believes it was PIN Authorised.  If Online PIN was used - unless the PIN was exposed to the Fraudsters this attack vector would not work.

@Matt: Exactly, with online PIN it would not work. But using the PIN exposes it to many other attacks, and it is not worth it.

I'm not sure what your point is?  PIN's can be compromised - so can Fingerprint Biometrics etc etc.  Online PIN is a better approach than Offline PIN but does increase Cryptographic processing in the transaction flow and key management for terminal estates.  America would still be better off using EMV with Online PIN versus EMV and Signature (as I understand US Debit Cards currently use Online PIN already).

@Matt: I am saying that the US is better off with EMV and Signature, because in the risk analysis the benefits of using the PIN are less that the risk in exposing it.

We leave our fingerprints everywhere - would you feel safer using a fingerprint? Maybe we should have signature pads on ATM's? We can dress this up a number of ways but the sad fact is that it's all down to interchange income rather than a technical or security argument. If you want to debate the effectiveness of Chip and PIN I suggest looking at fraud statistics before, after and during rollout. The problem area is CNP - and there are ways to lock that down too but the cost to implement outways the potential losses. It's all down to economics.

The second chip passed through the EMV commands and data between the terminal and genuine chip apart from the command to the chip to verify the PIN.  The terminal generated the VERIFY command correctly but the second chip intercepted this command without forwarding it to the genuine chip. The second chip automatically responded with SW1 SW2='9000' whatever PIN was entered to indicate to advise the terminal that  PIN verification was successful.  The PIN was not exposed in the fraud.

This attack would not be successful in an online environment where the PIN is verified by the issuer.  It would not be successful with Combined Data Authentication (CDA) cards and one would hope that US issuers are not sending out Static Data Authentication (SDA) cards.

If these had been Chip and Signature cards, the fraudsters would not have had to go to all the trouble of transplanting chips from one card to another and attaching second chips.  They could have simply used the stolen cards and signed for the transactions confident that the signature would not be checked thoroughly by the retailer.

Yes, it was exploiting the same vulnerability as the original no-PIN attack. However there was an interesting twist: they also modified the application transaction counter (ATC) to make it seem as if the card had done fewer transactions than it really had. This, along with the fact that the cards were stolen in France and used in Belgium, made it more likely for the transaction to be offline and so keep the fraud working even after the genuine card had been reported stolen. I posted more details here: https://www.benthamsgaze.org/2015/10/14/just-how-sophisticated-will-card-fraud-techniques-become/

I'm confused!

@Trevor stated "This attack would not be successful in an online environment where the PIN is verified by the issuer.  It would not be successful with Combined Data Authentication (CDA) cards and one would hope that US issuers are not sending out Static Data Authentication (SDA) cards." yet as far as I'm aware Belgium (if that's where the fraudulent transaction took place) uses online pin, so if @Trevor is correct how did this happen?  I'm not overly familiar with the technical detail but I thought that if the chip sought to go online but was unsucessful, then a decline response would be given? Would this fraud have been easier in the UK where offline pin is used?

@Peter When I've used my UK credit card in Belgian PoS terminals, I'm confident offline PIN and online authorisation was used because the PIN verification response was instantaneous but the transaction authorisation took a few seconds. I don't know the relative proportions of different transaction types, but offline PIN is almost certainly possible and is listed as the prefered option on the CVM list of UK cards I looked at. Even if only some terminals support offline PIN, criminals would have targeted them (they already would have had to identify terminals with a non-zero floor limit).

The French Issuer probably supported Offline PIN - its a case of what the Card and the Terminal can mutually support. If the Card can authorise offline (with floor limit and velocity) then it does create the potential for undesirable situations - when the advice is pushed online providing the CVM Result and TVR and sent online you can easily identify a discrepency between what the ICC thinks it processed vs what the terminal thinks it processed. Floor limit of zero is the way forward...

Reference the article by Andy Greenberg in Wired: http://www.wired.com/2015/10/x-ray-scans-expose-an-ingenious-chip-and-pin-card-hack/

Visa, MasterCard, and the others involved in EVM should have listened to Steven J. Murdoch, Saar Drimer, Ross Anderson, and Mike Bond - five years ago.
https://www.cl.cam.ac.uk/research/security/banking/nopin/oakland10chipbroken.pdf

I think fast Elliptic Curve Crypto (like Curve25519) and today's capable microchips would let us do cryptographically strong public-key based authentication.

EVM is a broken protocol.  I wonder if a correctly strong protocol wasn't possible with the technology when EVM was first developed.

It's useful to quote the final paragraph:"we have discussed ways in which this vulnerability may be fixed by issuer banks, while maintaining backwards
compatibility with existing systems. However, it is clear that the EMV framework is seriously flawed. Rather than leaving its member banks to patch each successive vulnerability, the EMV consortium must start planning a redesign and an orderly migration to the next version. In the meantime, the EMV protocol should be considered broken. We recommend
that the Federal Reserve should resit pressure from banks to allow its deployment in the USA until it is fixed."