July/August 2012

More Problems With EMV Terminal (in) Security and How to Control Somebody else's Phone via NFC

More Problems With EMV Terminal (in) Security and How to Control Somebody else's Phone via NFC

This last month has seen more attacks on the terminals that are used to make electronic payments and mobile phone devices that can be used to do just about anything including electronic payments.

In the case of EMV POS terminals and ATMs a Cambridge University team (Mike Bond, Omar Choudary, Steven Murdoch, Sergei Skorobogatov and Ross Anderson) has published their results on flaws in the implementation of unpredictable numbers (i.e. can't be pre-determined by an observer such as a random number sequence) as part of the authentication protocol which could lead to unauthorised payments.

In the case of mobile phones which are increasingly being used to both make and receive electronic payments Charlie Miller from Accuvant Labs has demonstrated the weaknesses in implementing the NFC software stack in mobile phones that may even allow the hacker to take control of the phone.

The thing is which of these is more important to the security fraternity or more particularly the payments industry. Both pieces of work are pretty smart but which one, either, both or none might actually lead to serious security breaches?

I still can't believe that people don't get it, in the world of smart cards or more precisely the secure chip or element the security of the chip has never really been the big problem, it's the terminals and that includes mobile phones that cause the real problems. So often people explain to me how it's the cryptography, whatever you do don't use Triple DES or 1024 bit RSA. If it hasn't got 4096 bits it just can't be long enough. I've never forgotten the story told to me by a famous mathematician who many years ago posted an innocuous blog (yes, blogs have been around for ages in the academic world) explaining tongue in cheek his difficulty in writing a program to factorise numbers. He published a 512 bit number (carefully chosen as the product of two large primes, there's the clue this happened in the late 70's a little after RSA was first published) in the blog and asked if somebody would mind factorising the number for him. Of course nobody succeeded but a surprisingly large number had a go!

I feel the same way about security hardened integrated circuit chips, no back bedroom buddy is going to read out the contents of memory on his PC but many seem to imagine they can. Now I appreciate there are specialised reverse engineering laboratories and universities that may be able to reverse engineer the chip and even aggregated shared computing resources that might be able to factorise large numbers but these are not the sort of attacks that are really going to damage a modern commercial system unless you can be sure you can defraud the system without getting caught. I really can't imagine Cambridge University doing that because they are making a totally different point more about the fact that you don't get perfection in information systems and that the service providers, in this case the banks shouldn't make such claims. But make mistakes in the terminal protocol and/or implementation and now you move into the world of the back bedroom hackers which is a much more likely attack surface.

The Cambridge University attack is based on the observation that many ATMs implement a poor calculation of Unpredictable Numbers (UNs) which are used in the EMV protocol as evidence of freshness, i.e. the transaction is happening now and wasn't pre-calculated earlier. In particular what they have demonstrated is that if you can collect from a genuine card a set of ARQC (Authorisation request message from card to Issuer which is cryptographically protected by a secret key in the card and shared by the Issuer) messages with enough UNs to match one that will be generated by the ATM then you can fool the system with a fake card. So for example if the target ATM only generates 4 UNs you would just need to pre-collect 4 ARQC messages from a genuine card. This data collection does of course require the user to go to a bogus POS terminal where the terminal sets about collecting all these ARQC messages without the customer becoming suspicious.

In addition when collecting these ARQC messages it will be necessary to pre-set the core parameters such as the amount of the transaction and the date. All this information is then loaded into the fake card which will set out to fool the system by playing one of these pre-stored ARQC messages. Note it is not a replay attack because as far as the Issuer is concerned these messages have never been previously used. The ARQC does also include an Application Transaction Counter (ATC) which increments every transaction or more precisely every time the terminal does a Generate AC request to the card to get the ARQC. However the Issuer is only likely to detect a repeat transaction counter, for operational reasons he will have to allow with some gaps in the transaction counter sequence.

It is not really in doubt that this form of attack is possible and arguably the ATM manufacturers have been careless in their implementation of the protocol or at the very least the certification test conditions are inadequate. However the claim in the paper from the Cambridge team that 'We can now explain at least some of the increasing number of frauds in which victims are refused refunds by banks which claim that EMV cards cannot be cloned and that a customer involved in a dispute must therefore be mistaken or complicit' is to say the least misleading. A more realistic statement would be that 'it is possible that EMV cards could be cloned but is the least likely of the possible error scenarios'. However where I would agree with the Cambridge team is over the software integrity of the POS terminals. This is not only difficult to achieve but is difficult to measure and even more difficult to maintain in any form of uncontrolled environment. You might argue that a mobile phone falls into this category rather neatly.

The beauty of the Blackhat conference is that the researchers actually demonstrate what you always thought was possible and quite often things you didn't imagine were possible. This year in Las Vegas has been no exception and perhaps of particular interest to us is some work undertaken by Charlie Miller of Accuvant Labs on the vulnerability of NFC implementations in mobile phones using Android (Android 2.3.3) and MeeGo (1.2 Harmattan PR1.2) OS's as examples.

Charlie describes how to fuzz (don't you love this word) the NFC software protocol stack for the Samsung Nexus S and the Nokia N9. Then he goes on to describe how he can see for these devices what software is built on top of the NFC stack. It turns out that through NFC, using technologies like Android Beam or NDEF content sharing, one can force some phones to parse images, videos, contacts, office documents, and even open up web pages in the browser, all without user interaction. In some cases, it is even possible to completely take control of the phone via NFC, including stealing photos, contacts, even sending text messages and making phone calls. He concludes that the next time you present your phone to pay for your cab, be aware you might have just gotten owned.

This to me is a far more serious statement about software integrity. Every day we are using mobile phones and are integrating them into our way of life including electronic banking and payments. If you can't trust the software then you have a problem. I suspect your first reaction is to assume that the correctness of the software comes by default and that you only need to worry about malware. The problem is in fact far more inherent particularly when you can't trust the core platform by those who try to get it right long before the hackers try to take over.

History is full of problems with the software right the way back to the software compliers which produce the code that actually runs on the target device. All ideas of Code walk through's and Common Criteria evaluations are important but there is absolutely no proof of software correctness. Next time you use your phone just think of all that code all from different sources in which you have no real participation. It is a subject we will come back to but let Charlie at least alert you to a problem that is not going to be solved any time real soon. The answer for those that are impatient is in the question 'in any system what can you actually trust'?

Dr David Everett, SCN Technical Researcher.


Unable to open RSS Feed https://www.smartcard.co.uk/RSS/scnrss.xml with error SSL certificate problem: certificate has expired, exiting

Video Interviews

Tim Jones talks on the wealth of networks

Christophe Dolique of Gemplus talks about ·SIM

Dominique Brule of Philips Semiconductors talks about Near Field Communication