I love J.J. Cale. His 2001 live album is one of the most-played on my iPhone. Sadly, it’s doesn’t have a live version of one of my all-time favourite J.J. Cale tracks on it: I got the same old blues. In case you don’t remember…

Have you heard that rumour / that’s a going round

You got it made / way across town

It’s the same old story / tell me where does it end

Yes I heard the news / it’s the same ol’ blues again

I think of this every time I read a story about how EMV chips are trivial to clone and how the banking system is about to collapse because of multi-billion pound frauds. So when someone sent me a link to this… same ol’ blues again:

As it turns out, the cards are just as easy to clone as their magnetic stripe predecessors.

From Forget card skimmers, chip-card shimmers will be your next nightmare • The Register

No, they’re not. If they were, then the “black hats” would be living in the lap of luxury on the proceeds of their undetectable crime and the world’s biggest issuing banks (who bear the cost of fraudulent EMV transactions) would be bankrupt. They’re not (or at least, not because of card fraud, which was a piffling half-a-billion quid or so in the UK last year) so perhaps the claim might be ever-so-slightly exaggerated. What this story is actually about is tampering with terminals in order to steal PINs, which is a flaw with EMV deployment because enciphered PIN is not implemented as the standard cardholder verification method (CVM), but it’s not a flaw with cards and it doesn’t help you to clone the chips. In EMVCo’s official response to this story they say that 

The attack described in the Breaking the Payment Points of Interaction (POI) presentation captures static card transaction data in order to attempt fraudulent magstripe or e- commerce transactions, where EMV is not used. This type of attack relies on magstripe information and not the EMV chip. It is EMVCo’s view that when the full payment process is taken into account, suitable protection exists to mitigate against this type of attack, such as ensuring that information read from a chip card is not sufficient to create a valid magstripe card. 

I bolded the EMV point, by the way. What EMVCo mean by that last sentence is that issuers should ensure that the ICVV in the chip is not the same as the CVV on the stripe. I wrote about this nearly ten years ago when ICVV was introduced in the UK so if there are any issuers out there who are still setting the chip ICVV to be the same as the stripe CVV then, well, they deserve everything they get.

In a similar vein, I was sent a few links to a story about another new “new security flaw” in EMV. I won’t give you the link here because there’s no point following it. I can give you the skinny in half a line: if you rewrite the service code on the stripe to indicate no chip present, then the CVV, which is calculated using the service code, will no longer be valid. If any issuer authorises that transaction then they are either somewhat cavalier in their risk profiles and find it sexually thrilling to put shareholders’ money on the line or they had the wrong consultants advising them on their card issuing and authorisation strategies. In other words, they deserve everything they get. But it’s not a “security flaw” in EMV it is a “moron flaw” in the authorisation system.

Incidentally, on a related topic, my good friend Stephen Murdoch wrote an interesting piece about what are called “relay attacks” (or “ghost and leech attacks) on contactless cards. I remember that a fair few years ago one of our clients had us build a ghost and leech system just to see if it would work. It did. But then everyone knew this. Here I am talking about it ten years ago:

David reinforced the feasibility of relay attacks against contactless systems and in the subsequent discussion, it seemed to me that me people felt that serious fraudsters would begin investing in this soon, so the industry needs to take it seriously.

From Taking a punt | Consult Hyperion

As it happens, fraudsters never did invest in it (because the contactless no-CVM limit of thirty quid makes it a very time-consuming and expensive way to steal not very much). Our clients did their risk analysis and decided that there was no need to fix it right away but maybe think about it longer term. One potential defence against this attack is based on timing and such a defence has now been defined by the EMV chaps. This is what is called (by MasterCard, since no-one else implements it yet) the “MasterCard Relay Resistance Protocol”. So, as Stephen says, as part of the transaction, the terminal sends a command to the card and measures how long it takes to respond. The response contains timing limits indicating how long it should take.

When the EMV cryptogram is generated by using Combined Dynamic Data Authentication-Application Cryptogram Generation (CDA), the response also contains the same timing limits, but these are digitally signed. If they don’t match the limits received earlier, or if the timed command exceeds the limits, then the transaction has failed and the terminal needs to decline the transaction. To be honest, a fair few observers have pointed out that because these are hard-coded limits, any variance in genuine devices may create more false negatives (genuine transactions incorrectly declined) that positives (actual attacks). Plus it needs all terminals to be modified and all cards to be replaced or renewed, and as I noted earlier it’s MasterCard only, so it may not be widespread any time soon, and it’s at least worth wondering whether it will be universal before #cardmaggedon (the day when non-card electronic transactions exceed card transactions at retail point-of-sale).

By the way, #cardmaggedon will be one of the topics covered in the discussions at this year’s Tomorrow’s Transactions Toronto Unconference to be held in the MaRS Discovery District on 29th September 2016. The post-card payments future will be the kick-off topic to get everyone thinking about where the world of retail payments might be going next. I look forward to seeing you all there.

Leave a Reply

Discover more from Consult Hyperion

Subscribe now to keep reading and get access to the full archive.

Continue reading


Subscribe to our newsletter

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

By accepting the Terms, you consent to Consult Hyperion communicating with you regarding our events, reports and services through our regular newsletter. You can unsubscribe anytime through our newsletters or by emailing us.