Today we have published a new paper: “Chip and Skim: cloning EMV cards with the pre-play attack”, presented at the 2014 IEEE Symposium on Security and Privacy. The paper analyses the EMV protocol, the leading smart card payment system with 1.62 billion cards in circulation, and known as “Chip and PIN” in English-speaking countries. As a result of the Target data breach, banks in the US (which have lagged behind in Chip and PIN deployment compared to the rest of the world) have accelerated their efforts to roll out Chip and PIN capable cards to their customers.
However, our paper shows that Chip and PIN, as currently implemented, still has serious vulnerabilities, which might leave customers at risk of fraud. Previously we have shown how cards can be used without knowing the correct PIN, and that card details can be intercepted as a result of flawed tamper-protection. Our new paper shows that it is possible to create clone chip cards which normal bank procedures will not be able to distinguish from the real card.
When a Chip and PIN transaction is performed, the terminal requests that the card produces an authentication code for the transaction. Part of this transaction is a number that is supposed to be random, so as to stop an authentication code being generated in advance. However, there are two ways in which the protection can by bypassed: the first requires that the Chip and PIN terminal has a poorly designed random generation (which we have observed in the wild); the second requires that the Chip and PIN terminal or its communications back to the bank can be tampered with (which again, we have observed in the wild).
To carry out the attack, the criminal arranges that the targeted terminal will generate a particular “random” number in the future (either by predicting which number will be generated by a poorly designed random number generator, by tampering with the random number generator, or by tampering with the random number sent to the bank). Then the criminal gains temporary access to the card (for example by tampering with a Chip and PIN terminal) and requests authentication codes corresponding to the “random” number(s) that will later occur. Finally, the attacker loads the authentication codes on to the clone card, and uses this card in the targeted terminal. Because the authentication codes that the clone card provides match those which the real card would have provided, the bank cannot distinguish between the clone card and the real one.
Because the transactions look legitimate, banks may refuse to refund victims of fraud. So in the paper we discuss how bank procedures could be improved to detect whether this attack has occurred. We also describe how the Chip and PIN system could be improved. As a result of our research, work has started on mitigating one of the vulnerabilities we identified; the certification requirements for random number generators in Chip and PIN terminals have been improved, though old terminals may still be vulnerable. Attacks making use of tampered random number generators or communications are more challenging to prevent and have yet to be addressed.
Update (2014-05-20): There is press coverage of this paper in The Register, SC Magazine UK and Schneier on Security.
Update (2014-05-21): Also now covered in The Hacker News.
Isn’t this article a bit old . I read it some long time ago ? why is called new ?
There was a pre-print by the same name, but that pre-print was not published anywhere (this paper is at Oakland) and the pre-print only discussed the first of the two vulnerabilities we discovered.
Hi Gents,
I really liked the paper. I think you did a great job of showing how to predict numbers in the ATM / POS you tested. I also smiled when I read that EMVCo just released (in June 2014) a clarification of the Unpredictable Number requirements.
Do you think this attack is actually possible “in the wild”? I ask because when I read your test conditions you were using test payment cards with known symmetric keys to generation the online authorization requests (the ARCQ). The paper outlines how you would store valid cryptograms – generated by the genuine card – for replay by a counterfeit card at a later point. I am just struggling to understand how that would be possible. I could write more but my response would then become a rather dull essay. In short, do you think this attack is actually possible “in the wild”?
I do think it is likely that the changes to the EMV specification were a result of our disclosure. We privately circulated our results in January 2012 and the first specification change came out in April 2012. Other than the timing though, we don’t have any confirmation that we were the trigger.
Thanks for pointing us to the June 2014 specification change. I’ll take a look at it.
I do think the attack is possible in the wild. It’s not easy, but the difficulty of the no-PIN attack was higher and criminals still pulled it off. Criminals are frequently underestimated by the banking industry, but all it takes is one smart criminal to build tools that others can use.
Hi Steven,
Thanks for responding.
On a related note (I think)….
When I visited the London based Mexican food chain “Wahaca” I noticed the receipt also included the Transaction Certificate. Do you think more merchants should be printing this value on receipts to help with disputes? Or do you think there is the possibility for a nefarious merchant to launch a similar style pre-play attack against the Transaction Certificate (not the ARCQ) for Offline approved transactions?
My receipt (which you can see on here: http://youdot.co.uk/wordpress/?p=790) had the normal stuff; the ICC, the Terminal ID, the Merchant ID, and the AID. The receipt, to my surprise, also listed the Transaction Certificate. I re-checked EMV book 1, 3 & 4 for details on mandatory fields on the receipt. About as clear as mud (the AID is mandatory on a receipt, the CVM method should also be on the receipt but no details of whether the TC is included on the receipt). I imagine the TC is useful if a customer ever gets into a dispute with the Card Issuer. They can use that number to show the Chip verified (or did not) verify the transaction.
I thought about this receipt information and the way you laid out the pre-play attack. I don’t want to chase an idea down a rabbit hole but I would pay a penny for your thoughts…
The TC is of limited use on customer receipts, because if the transaction is disputed the customer won’t have the receipt. It’s a bit more interesting on the merchant receipt, but only if other information is provided too (TVR, UN, etc…). Even then it’s only useful if the card issuer is willing to disclose the card key but in my experience they weren’t.
So I think printing the TC is mainly useless but not harmful. It would be much more useful to print the TVR and IAD. If card issuers can be forced to disclose card keys for disputed transactions then there would be a strong case for printing the TC along with all the input data though.