Light Blue Touchpaper

Dual use technologies are everywhere. Myself and colleagues have been presenting Phish and Chips, and the Man-in-the-Middle Defence at the Security Protocols Workshop this week, in which we describe how the EMV protocol suite can be modified in unintended ways, and that a card interceptor can be used for both fraudulent and beneficial activities.

A second example is how the waters in which internet phishermen angle for account details regularly become muddied by the marketing departments of enterprising banks. Every once in a while, these chaps manage to send out genuine emails entreating the user to click on the link in the email, or to navigate to a site not clearly part of the bank’s site, then provide their personal details.

Today I discovered that the same dilemma has been playing out in the fight to secure the fascia of cash machines against the attachment of illicit skimmers. I was off to work promtly this morning, to open up shop for an ITN TV crew doing a piece on Chip and PIN. After cleverly managing to miss my train, I was forced to take a rather expensive taxi ride to Cambridge — so much so that I had to have the taxi stop for me to withdraw some cash. It was then that I spotted this device attached to the slot of the Barclays Bank ATM on White Horse road in Baldock, Hertfordshire.

(more…)

We recently built an EMV transaction interceptor to aid us in understanding the viciously complex EMV protocol suite. A useful byproduct is that we can now give demonstrations of interception and relay attacks on Chip and PIN — topics discussed in our paper Chip and Spin. Since German TV picked up on our interceptor experiments, there has been some discussion about whether these attacks really work, and what it means for Chip and PIN security.

First off, intercepting smartcard communications is not rocket science; EMV is built on the ISO 7816 standard for smartcards. Interceptor hardware necessarily exists for test purposes (Micropross is a well known test rig manufacturer) but it doesn’t come cheap. Not willing to cough up a grand, we decided to do it on the cheap: we wrote a very basic microcontroller program which samples the smartcard I/O data line as fast as it can, and passes the data back via USB for decoding on a laptop.

This prototype is a useful price point for the cost of a smartcard interceptor: for example, we bought a suitable microcontroller development board from Siphec for about $60. Our Chip and PIN (EMV) Point-of-Sale Terminal Interceptor page describes both this device and claims that sufficient information can be captured from a trace of an EMV transaction to recover the customer PIN, and to produce a magnetic stripe counterfeit of the card.

That we built a working interceptor is not under dispute, but is the above claim true? Would it actually work in practice? For this goal, a number of extrapolations must hold true:

• The PIN must travel in the clear across the wires to the smartcard. UK cards are SDA cards, so the PIN is not encrypted. In theory the PIN could be routed for verification at the bank rather than by the card, but the UK also opted for local verification only.
• The customer PAN and CVV1 must be sent by the smartcard. More generally, all the information required to reconstruct the magnetic stripe must be present. The PAN is clearly sent as it is required for the EMV transaction itself. In the half dozen or so UK cards we have examined, the same CVV1 appeared to present in the chip data as on the magstripe, though we were aware of some suggestions that the CVV1 was blanked out on the chip equivalent data. The EMV specification says that all records stored on the chip are read out during a transaction, and the traces appear to confirm this.
• There must be no further secret authentication mechanisms for the card or magstripe. In Germany, magstripe cards carry a hidden “MM-code” which is correlated with a copy encoded on the magstripe; the method to read the MM-code is kept secret. In the USA there is some use of automated counterfeit hologram detection. It seems no such methods are in use in the UK; journalist Jonathan Maitland from Tonight with Trevor MacDonald successfully produced and used a counterfeit white card produced purely from a dump of track 1 and 2 magstripe data.
• A suitable target ATM must be found at which to use the counterfeit card. Clearly there are plenty of ATMs in foreign countries which do not support Chip and PIN, so targets do exist. Within the UK there are three ways for an ATM to be vulnerable. First, if it has not been upgraded to support chip cards, it must necessarily use the magstripe. Second, if the chip-enabled ATM cannot tell with certainty that a card is supposed to be a chip card, then it may assume it is a magstripe card. Seeing as practically all UK ATMs are online the issuing bank can always be queried, so this second vulnerability mode is unlikely. Third, if the ATM supports fallback to magstripe, for instance in the case of damaged chips, then it will work. Conditions under which ATMs permit fallback actually appear to be quite complex, dependent for example on time of day and fraud history on that machine. There was certainly no problem finding viable ATMs in the UK when the Trevor MacDonald program aired, this time last year.
• It must be possible to adequately miniaturise and camouflage the interceptor. Miniaturisation of the circuitry is not the bottleneck here, very small form-factor microcontrollers can be found, and few other discrete components are needed. The real miniaturisation challenge comes in gaining physical access to the electrical contacts covertly. The reader slot is wide enough to admit a thin second item, such as a flexible PCB, or maybe some other sort of plastic sheet with conductive ink, but the space is of the order of 0.1 mm, a typical card being about 0.8 mm thick. The alternative is not to go for a miniature solution per se, but a well camouflaged fake slot which sits outside the main slot. Different form-factor terminals would clearly have different optimal designs for cheap interceptors.
• The POS terminal must not be able to detect the presence of an interceptor. Some modernised ATMs are able to detect unauthorised attachments designed to directly skim PIN and magstripe, there is no fundamental reason why such technology could not be applied to POS terminals as well. However we have found that there definitely are UK POS terminals which do not detect such attachments, for reasons of cost, we suspect.

Is there missing piece to this jigsaw that we have overlooked in our investigations, or are banks simply reluctant to admit that POS terminals are at least equally vulnerable to the same sorts of magstripe skimming attacks as ATMs? I’m eager to find out.

I recently got an email from Bank of America offering me a pretty good credit card deal. Usually, I chuck those offers away as spam (both electronic and physical) but this time I decided to bite.

The “apply now” button pointed to http://links.em.bankofamerica.com:8083/…, fair enough. I click. But wait… IE6 says…

Firefox provides more info without layers of abstraction…

I clicked “OK” and got to… https://www.mynewcard.com/! (you’ll notice that going there directly redirects to https://mynewcard.bankofamerica.com/, so only when you click “apply” do you get to see mynewcard.com.)

I consequently emailed BofA with my concerns and got this (surprisingly expedient) reply:

“We recognize that any unsolicited e-mail, legitimate or otherwise, is reason for concern. I can assure you that www.mynewcard.com is a legitimate website of Bank of America.”

Well, not much assurance there since I replied to the original email (cardservices@replies.em.bankofamerica.com), but a whois query confirms that mynewcard.com indeed belongs to BofA. What percentage of the population would go beyond clicking that “OK” on the IE warning as just another annoyance? You know the answer.

So, BofA got three things wrong. Firstly, they had links in the body of the email; the argument has been beaten to the ground… don’t educate people to click them. If the bank has great offers, they should have them available when people log into their accounts. Secondly, they messed up on the certificate… it’s for mynewcard.bankofamerica.com, not what appears in the address bar, mynewcard.com. And finally, they used an unfamiliar domain to process the application. Why? I think the answer lies somewhere in the marketing department where they decided that mynewcard.com is cooler sounding than sound security measures and long term good customer training.

Update: Richard mentioned that the rapid response meant that BofA have heard this concern once before. I found this thread [dansanderson.com] discussing mynewcard.com in August 2003! Which adds a fourth thing BofA did wrong: they didn’t fix it!