Blog article
See all stories »

Moving forward with EMV

I think the report from the University of Cambridge is very interesting and raises some very valid points, despite the fact that it is quite theoretical and could only work in a specific set of circumstances.

There are a number of options that the banking community has to prevent fraud of this nature.

1.        Do not allow EMV cards to be verified by signature, unless there are specific circumstances such as the card-holder is travelling overseas, or if signature is required because a physical disability means PIN isn’t an option. This could be rolled out by the banks checking the Card Verification Results during the authorisation process. (Card Verification Results are unaffected by this attack and give a true report of whether the offline PIN was verified by the card.)

2.        The report suggests comparing the Cardholder Verification Method Results (CVMR) with the data contained within the Card Verification Results (CVR) file, to ensure they report the same verification method. Currently the CVMR data doesn’t always get passed from the acquirer to the issuer, however if it were mandated by the card schemes, this could come into effect quite quickly. For the issuing banks, once they have all the information, it is a simple job to add one more step in the authorisation process to compare the files.

3.        Again, by checking the CVR information, banks can implement a ‘floor limit’ for all EMV transactions that haven’t been PIN verified, so there is a cap on the amount that could ever be spent

As an industry we often talk about trying to keep up with the fraudsters but many banks have done little with EMV since their initial implementations. A full review of the capabilities available particularly in authorisations and risk will mean it is the fraudsters who will be playing catch up as the industry identifies and blocks further potential holes before fraudsters even know they exist.


Comments: (2)

Steven Murdoch
Steven Murdoch - University College London - London 16 February, 2010, 15:57Be the first to give this comment the thumbs up 0 likes


Thanks for your comments on this issue. You may also be interested to read the comments on my blog posts, at Finextra and Light Blue Touchpaper. You will see that there is quite a wide range of opinions on how this attack should be mitigated.

"Currently the CVMR data doesn’t always get passed from the acquirer to the issuer"

That is a very interesting point. So far we've been investigating the merchant to acquirer interface, and it seems that the CVMR (or equivalent) is commonly sent to the acquirer. However, if it is dropped by the time it gets to the issuer, this way of preventing the attack doesn't work any more.

Do you have any reference for this fact, so we could mention it in the updated version of our paper?

A Finextra member
A Finextra member 17 February, 2010, 14:49Be the first to give this comment the thumbs up 0 likes


I think the point Andy is alluding to is his suggestion that Visa and MasterCard should mandate the passing of CVMR data between Acquirer and Issuer so that a comparison can be made between the CVR and CVMR on the Issuer Host.

There are a number of ways, in terms of both Technical and manual/business processing, that can mitigate the kind of attack you have detailed in your report.  

I am not convinced, from an Economical point of view, on the level of returns a fraudster would expect against such a high risk attack (most Merchants with High Value goods have CCTV).  Given that they will also have the additional risk of fencing any acquired goods in order to make a return only increases their exposure further. 

Now hiring