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.

32 thoughts on “Chip and Skim: cloning EMV cards with the pre-play attack

  1. Um… it sounds like YOU are trying to steal data, not act like a savior… You are trying to decode the original program and tell everyone how it is done. So now how are you attacking banks by unveiling their operational risks as well as their credit dangers? and… “sabotaged smartcard into the terminal” what’s that??? Go back to the matrix and let me get back to my life!

  2. David, let me expand on S’s comment,
    The research above is not intended to expose flaws to exploit, but to determine the methods current exploits are using.
    Consider it a battle tactic, think like the enemy to defeat the enemy.

  3. The fact is that if this WAS a current attack then fraud against chip and pin cards would be widespread and not sporadic. Can you imagine the value of such an attack to fraudsters? Why would there not be a widespread and sustained series of attacks taking high value withdrawals? Ross’s team have done some good work in the past in revealing a couple of genuine, if obscure, vulnerabilities but most of their announcements are sensationalism and self-serving PR. What do you need from any secure system? Enough security to prevent economic fraud – you get more back than it costs to perpetrate the attack, and that the risk of discovery is low. Now you have chip cards and you have mag stripe cards – which one would YOU go after? Exactly.

  4. Do this vulnerabilities apply only to “EMV payment cards” (issued by credit card companies) or also to so called “ec electronic cash” chip based debit cards (mostly issued by banks)?

  5. Also can anyone explain to me what card/bank issuing relationship allows someone to withdraw e1350 on the same day? Everywhere I go I hit the same withdrawl limits on daily use, whether in my home country, Europe or the US. Given that the ATM is online and requires either a stand-in or explicit auth from the issuer how is this possible?

  6. Just wondering if the code was examined on the 3 atm’s from ebay
    to look for something like collecting the card information & calling home with that info. I would really avoid using portable atms like those pictured. I have seen some in corner stores that have a phone line that runs out of the back of them & just go up into the ceiling or all bunched up on the floor next to the machine.

    Interesting research on this topic

  7. The attack does not seem to affect the main purpose of EMV, which is to detect cloned cards. And I cannot see the connection with the Luckey incident.

  8. @Steve – Crooks in general feed like parasites on society. If they hurt the banks or customers too hard then a new round of innovation is forced and the banks come up with a countermeasure or fund the police to try and arrest them. Therefore it is in their interest to commit enough fraud to get rich but not so much that they get hunted down and stopped. Simply put, they get too greedy, they lose. All new fraud methods start out small and benefit the smart crooks, before they get industrialised and enventually are countered by a new defence. Magstripe fraud is still possible but it is becoming harder too… hence the need for innovation in the criminal community.

    @Andreas – They apply to emv based credit debit and cash cards. I’m not sure exactly what you mean by “EC electronic cash”, but something like the older Proton scheme it may not apply to.

    @Janet – We mainly focussed on ATMs for the work in this report. According to our empirical analysis, most ATMs do not perform SDA or DDA, whether the card supports them or not. So the card type SDA/DDA/CDA is irrelevant.

    @Steve, yes €1350 withdrawn within just a couple of minutes. It is surprising.

    @Jonathan. the purpose is to “detect” cloned cards? I thought the purpose was to prevent card cloning, not just to detect it.

    The gambin case is connected to our research because it was the case during which we discovered defficient RNGs. The Gambin case has a similar withdrawal pattern, and context (stolen card) to the Luckey case. And both these cases appear to be part of a wave of fraud taking place in Spanish coastal resorts.

    Mike

  9. @Mike: €1350 withdrawn from a single account within the hour can be explained by ATM’s programmed to do offline verification (i.e. ask the chip) only of account balance and limits.

    Historically, the offline verification was designed in a time where phone calls were expensive (e.g. France late 90-ies). This new chip clone technique takes advantage of that, meaning the transaction(s) will not be reported to the bank until certain thresholds are met.

    Disclamer: I work in the creditcard anti fraud industry.

  10. @Steve: I can easily get €1000 from an ATM here in Spain and up to €3000 in purchases with a merchant.

  11. Very interesting research, following on from similarly impressive work by UoC congratulations!

    Almost as interesting, if not more so, are those posts indicating scepticism, blind disbelief, pure latent ignorance – or perhaps an undisclosed agenda? (As distinct from some very insightful comments and posts).

    Those of us who work in security will recognise a pattern here: flat denial that an issue exists, followed by anger at being publicly proved wrong and accusations that you, not the solution provider, are the problem for daring to research and disclose your findings. This is too often coupled with the “Who cares? it’s not a real problem” outlook.

    The NEXT stage – “we’re looking at fixing this” – only arrives when someone demonstrates what has been obvious to a thinking person from the outset: if it’s a feasible attack, then even if it requires undergraduate-level education, and the factor of malicious intent, that’s still a very, very large number (5 figures?) of potential culprits in a globally-connected system.

    Perhaps the only saving grace here is that, as no rule is absolute, some of the card providers must be exceptions to the above nonsense.

    Just hope they’re YOUR provider.

  12. @Mike

    I did indeed mean detect. Prevention depends on detection. It is up to the issuing bank to act upon the detection, EMV does not tell them what to do when the ARQC fails verification. I do indeed expect them to decline the transaction and attempt to retain the card, but this is not always possible. Detection, even if post factum, is.

  13. ha ha you have just discovered this well done. they have known of this since 2009.

    thanks for once again making our findings public

  14. It’s a shame that what appears to be valuable and legitimate research has (once again) been wrapped up in sensationalist, self-serving scare-mongering headlines.
    This isn’t a flaw in EMV technology or security – it’s a flaw in how some ATMs have been implemented, hence a flaw in the certification process.
    This isn’t card “cloning”, any more than taking a picture of somebody is “cloning” a human – this is making an imperfect faxsimille of a card that can be used in a very specific, very limited way to defraud the system.
    That said, I think the research itself is very interesting, and I agree with the (non-sensational) conclusions: there *is* an exploitable weakness in the system as a whole and therefore Issuers should do more to ensure they can detect the possibility of such an attack having occurred.

  15. If only the issue was technical… If, as the article mentions, Mr. Gambin hasn’t been reimbursed by HSBC, it points to a misplaced responsibility. If there’s no sweat by the bank, there’s no incentive to fix their system. There are too few victims and the bank can stonewall them. On the other hand, if they were forced to compensate victims, you can be sure that they would clean up their act. For example, as Mr. Harbige suggests, by tightening up the certification of client terminals.

  16. “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.”

    ===

    Well I do not believe so – the ‘replayed ARQC’ carries in itself the actual original transaction date – bank authorization host must catch this if submitted on a different date, also the most bank authorization hosts will catch ‘duplicate ARQC’ submission and simply DECLINE the transaction.

  17. so 1350 Euros in five transactions. Was each transaction for 270 Euros?

    If not had Alex made a transaction for each of the amounts previously at similar ATMs?

  18. Mike,

    fascinating research and yet another timely reminder that real world security is often broken by poor implementation (and complicated, confusing specifications!).

    The timing aspect of the final stage of the attack would seem to make it harder to exploit in attended payment environments, although I may be wrong about that.

    I would like to ask how the complexity/risk/reward balance of this attack plays out in an attended payment environment (for example in retail, rather than against ATMs).

  19. Dear me! All this fuss over something as simple as identity authentication…
    What would be really good, would be some kind of telepathic password, which you could communicate to your bank, each time you needed to access your account online, and it would be really handy, if your mind could also transmit this password to the ATM.
    Well, that’s obviously not going to happen so, how about a compromise, where you transmit to your bank, information about your telepathic password, which only your bank understands?
    Yes, but the camera, and the malware, would record what you typed, and use it to get into your account. Okay, then, how about, if what you typed only worked once. Then, using the same keystrokes a second time would be useless. That would work, but how does the bank know that, what you typed the second time, represented the same telepathic password? Also, you certainly wouldn’t want to contact your bank every day, to get a new method of transmitting your telepathic password.
    How about this, then? Each time you want to access your account, a popup shows you an alphabet, with a number under each letter, and you type the numbers, instead of the letters?
    Okay, that’s obviously bad because the camera would pick up the numbers but, what if the numbers were all scrambled? That’s better, but the camera would still get you, and the malware would still send them back to the sociopath who, after a few months, would be able to guess your password, from the patterns of the numbers.
    What about, if there were only two numbers and, what if there were two alphabets, in upper and lower case? Then your telepathic password would be represented by a selection from 52 letters, each letter identified by one of two random digits. If the pattern of the digits changed randomly, with each access, then your telepathic password of “gobbledeygook” would be “1000110011001” the first time but, the second time, it would be “1110010001101”.
    Now we’re getting somewhere. The camera sees you entering a pattern of 1’s and 0’s, each of which could correspond to any one of 20 or 30 letters, the network snooper sees the numbers, but not the letters, and the malware sees both, but doesn’t know what they mean. Luckily, you took maths in college, and spend a lot of time in the casino, so you know how to calculate odds, and you can see they’re now in your favour, but you still want them to be better, because you work with classified documents, and really need to have tight security. What if you had two passwords, and added them together? What if you added or subtracted ‘1’ from every other letter What if…? You’re tempted to call this ‘Uncrackable Authentication’
    Aha! I hear you cry. How do I get my telepathic password, in the first place? The malware is watching my browser and my email, and will pick up the keystrokes when I type it into any form I fill in. How am I going to enter my password? Well, it might ne good, if I had a set of alphabets but, this time, the letters were pictures of letters, and they, themselves, were scrambled, and referenced by a set of numbers. Then, the malware would pick up the mouse strokes, but would only know that they corresponded to a selection of pictures, with random names. Let’s be realistic, however. If there’s a spy camera, watching you do this, it will pick up what you enter. On the bright side, you’ll be doing this at home, probably only once a year, or so, with only the malware to contend with – unless you’ve fallen foul of the CIA, or your wife has her suspicions about you…
    One day, quite by chance, you stumble upon a site at http://www.designsim.com.au recommended by your friend at the FBI (he got it from some guy in military intelligence), and you say to yourself, Hey, they stole my idea”, but you look at it anyway.

  20. We all know that no technology is absolutely secure – if enough effort, time and money spent, it can be compromised.
    The report quoted was based on work done in a lab environment. More importantly, the report states that they used test cards with known card Master keys to generate the cryptogram. This is the flaw of the test. The card Master key cannot be extracted from the card – the cards have hardware and software in place to prevent tampering and will self-destruct if they are tampered with.

  21. Mike, as usual, fantastic work from you and your team. My concern is precisely the one you raise in your conclusion. In the case of the U.S credit card system, since banks pay for fraud they have a vested interest in stopping it. Merchant banks in the U.S. have some idea as to where fraud is being committed, because they can see it in the merchant sales patterns. Here, the onus is on the consumer, who has no access to the merchant sales pattern. What economic motivation does the bank have in this case to take action to fix the problem? Why would the merchant do anything?

  22. My debit card and pin and been used fraudulently. I have my debit card in my possession and only use it at Bank and ATM. I just reported the fraudulent use of my card and was told as it’s chip and pin the user must have had physical possession. Just found this sie while trying to ascertain how this could happen when my card has been in my possession 24/7.

  23. Two months ago, there were cash withdrawals from ATM’s in the town where I live, Lausanne, Switzerland. This was done using my credit card and it was quite a large amount. The credit card is still in my possession and I did not make the withdrawals myself.

    However, the bank claims the money was withdrawn with the chip on the card using the PIN code. They also claim it is impossible to copy and for that reason it must have been me.

    The problem is that it was not me, nor did i ever give my PIN code to anyone. So how could this have happened? I have used my credit card in some shops in Lausanne the week before, could it have been copied?

    Thanks for your help and comments!

  24. Mike, I have a question, apologies if this is a silly one, but Ive read the Cambridge paper, and although it was on the verge of being out of my technical expertise, I think I understand the basics.

    From what I gather, what is needed to replay the transaction is the following:
    ARQC (a DES wrapper of: transaction counter, card details and the MAC)
    MAC (a des wrapper of 4-byte TVR data, UN, amount, currency and time/date stamp)
    This leaves us with a DES message of 16bit number, the symmetrical key-encrypted IAD, and the DES encrypted MAC.

    If we can predict the UN, then we can retrieve the MAC. What is the significance of this, when we cannot access the IAD, or can the IAD encrypted block simply be sent to the acquirer, who will check it as if it came from a real card? The only unique piece of data, it seems to me, within an EMV transaction will be the internal transaction counter within the card and the timestamp. In theory, every other piece of information can be identical. Why, then, is predicting the UN the key to replaying a transaction?

Leave a Reply

Your email address will not be published. Required fields are marked *