Chip and Skim: cloning EMV cards with the pre-play attack

November last, on the Eurostar back from Paris, something struck me as I looked at the logs of ATM withdrawals disputed by Alex Gambin, a customer of HSBC in Malta. Comparing four grainy log pages on a tiny phone screen, I had to scroll away from the transaction data to see the page numbers, so I couldn’t take in the big picture in one go. I differentiated pages instead using the EMV Unpredictable Number field – a 32 bit field that’s supposed to be unique to each transaction. I soon got muddled up… it turned out that the unpredictable numbers… well… weren’t. Each shared 17 bits in common and the remaining 15 looked at first glance like a counter. The numbers are tabulated as follows:

F1246E04
F1241354
F1244328
F1247348

And with that the ball started rolling on an exciting direction of research that’s kept us busy the last nine months. You see, an EMV payment card authenticates itself with a MAC of transaction data, for which the freshly generated component is the unpredictable number (UN). If you can predict it, you can record everything you need from momentary access to a chip card to play it back and impersonate the card at a future date and location. You can as good as clone the chip. It’s called a “pre-play” attack. Just like most vulnerabilities we find these days some in industry already knew about it but covered it up; we have indications the crooks know about this too, and we believe it explains a good portion of the unsolved phantom withdrawal cases reported to us for which we had until recently no explanation.

Mike Bond, Omar Choudary, Steven J. Murdoch, Sergei Skorobogatov, and Ross Anderson wrote a paper on the research, and Steven is presenting our work as keynote speaker at Cryptographic Hardware and Embedded System (CHES) 2012, in Leuven, Belgium. We discovered that the significance of these numbers went far beyond this one case.

Let’s go back to the start. Alex Gambin had his wallet pickpocketed in Palma, Mallorca, and within an hour of the theft five ATM withdrawals had been made using his card totalling €1350, yet he never wrote down his PIN.

Early on Alex smelled a rat. He contacted us and we linked his case with a wave of others across Spain. Alex talks about his case (in Maltese), and investigative journalist Sabina Wolf timed the maximum speed of consecutive withdrawals for one of the other cases in the wave – of Anette Luckey (in German). She found that the ATM in question could not keep up with the withdrawal speeds which had been logged. Luckey has since been refunded but HSBC Malta has not done the same for Alex.

Expecting some sort of foul play we examined Alex’s log data in detail and found the vulnerabilities in the ATM. Either there is a causal linkage between Alex’s fraud and the deficiencies in the ATM, or these deficiencies are extremely widespread. We then went back and reviewed log data from older disputes – some still unsolved – and found ATMs with similar obvious non-uniformity in the logged unpredictable numbers. We set out to systematically harvest unpredictable numbers in quantity from local ATMs to look for predictable random number generators. So far we have performed more than 1000 transactions at more than 20 ATMs and a number of POS terminals, and are collating a data set for statistical analysis. We have developed a passive transaction logger which can be integrated into the substrate of a real bank card, which records up to 100 unpredictable numbers in its EEPROM. Our analysis is ongoing but so far we have established non-uniformity of unpredictable numbers in half of the ATMs we have looked at.

We also acquired three ATMs from Ebay and have been analysing them to determine the random number generation algorithm. Our work is ongoing – reverse engineering is manpower intensive.

     

As we considered the ramifications of the attack we realise that there are bigger issues at stake.

First, there is an easier attack than predicting the RNG. Since the unpredictable number is generated by the terminal but the relying party is the issuing bank, any intermediate party – from POS terminal software, to payment switches, or a middleman on the phone line – can intercept and superimpose their own choice of UN. Attacks such as those of Nohl and Roth, and MWR Labs show that POS terminals can be remotely hacked simply by inserting a sabotaged smartcard into the terminal. Such an attack is powerful as the terminal can be rigged to show transaction approval regardless of what the bank says, but such a brazen attack would be detected quickly when the merchant’s books fail to balance. But to use malware to inject stolen transactions would be far harder to detect and trace back, as it would be down to the cardholder to complain; and as cardholders are routinely stonewalled by banks who claim that EMV is secure, and whose fraud teams lack the skills and tools to do proper investigations, the crooks will have much longer to cash out.

Second, there are legal ramifications: It can no longer be taken for granted that data in a transaction log was harvested at the time and place claimed, which undermines the reliability of evidence in both civil and criminal cases. To show that a given transaction was made by a particular card, it is now necessary to show that the random number generator on the ATM or POS was sound, and that neither the UN nor the ARQC was modified during transit.

Third, there are public policy issues. Just as banking regulators were too ready up till 2008 to believe banks’ assurances about credit risk, so also have most regulators been insufficiently sceptical about their claims in respect of operational risk. We have described some of the complaints we receive regularly from bank customers that stolen cards have been used in circumstances where the PIN could not have been compromised, and yet whose bank refuses a refund claiming its records show the PIN was used. Many of these customers are credible witnesses and it is not believable that they are all mistaken or lying. When we investigate their claims we often find serious vulnerabilities which the industry failed to disclose. It appears that some parties were already aware of the random number deficiencies we describe in today’s paper but failed to take action. This raises serious issues for regulators.