All posts by Mike Bond

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:


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.

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

A truly marvellous proof of a transaction

When you transact with an EMV payment card (a “Chip and PIN” card), typical UK operation is for the bank to exchange three authentication “cryptograms”. First comes the request from the card (the ARQC), then comes the response from the bank (the ARPC) and finally the transaction certificate (TC). The idea with the transaction certificate is that the card signs off on the correct completion of the protocol, having received the response from the bank and accepted it. The resulting TC is supposed to be a sort of “proof of transaction”, and because it certifies the completion of the entire transaction at a technical level, one can presume that both the money was deducted and the goods were handed over. In an offline transaction, one can ask the card to produce a TC straight away (no AQRC and ARPC), and depending on various risk management settings, it will normally do so. So, what can you do with a TC?

Well, the TC is sent off to the settlment and clearing system, along with millions of others, and there it sits in the transaction logs. These logs get validated as part of clearing and the MAC is checked (or it should be). In practice the checks may get deferred until there is a dispute over a transaction (i.e. a human complains). The downside is, if you don’t check all TCs, you can’t spot offline fraud in the chip and pin system. Should a concerned party dispute a transaction, the investigation team will pull the record, and use a special software tool to validate the TC – objective proof that the card was involved.

Another place the TC gets put is on your receipt. An unscientific poll of my wallet reveals 13 EMV receipts with TCs present (if you see a hex string like D3803D679B33F16E8 you’ve found it) and 7 without – 65% of my receipts have one. The idea is that the receipt can stand as a cryptographic record of the transaction, should the banks logs fail or somehow be munged.

But there is a bit of a problem: sometimes there isn’t enough space for all the data. It’s a common problem: Mr. Fermat had a truly marvellous proof of a proposition but it wouldn’t fit in the margin, and unfortunately while the cryptogram fits on the receipt, you can’t check a MAC without knowing the input data, and EMV terminal software developers have a pretty haphazard approach to including this on the receipts… after all, paper costs money!

Look at the following receipts. Cab-Inn Aarhus has the AID, the ATC and various other input goodies to the MAC (sorry if I’m losing you in EMV technicalities); Ted Baker has the TC, the CVMR, the TSI, TVR and IACs (but no ATC), and the Credit Agricole cash withdrawal has the TC and little else. One doesn’t want to be stuck like Andrew Wiles spending seven years guessing the input data! Only at one shop have I seen the entire data required on the receipt (including CID et al) and it was (bizarrely) from a receipt for a Big Mac at McDonalds!

Various POS receipts

Now in case of dispute one can brute force the missing data and guess up to missing 40 bits of data or so without undue difficulty. And there is much wrangling (indeed the subject of previous and current legal actions) about exactly what data should be provided, whether the card UDKs should be disclosed to both sides in a dispute, and generally what constitutes adequate proof.

A "fake" transaction certificate
A “fake” transaction certificate

But most worrying is something I observed last week, making a credit card purchase for internet access at an Airport: a fake transaction certificate. I can tell its a fake because it firstly its the wrong length, and secondly, it’s online — I only typed in my card number, and never plugged my card into a smartcard reader. Now I can only assume that some aesthetically minded developer decided that the online confirmation needed a transaction certificate so took any old hex field and just dumped it. It could be an innocent mistake. But whether or not the “margin was too small” to contain this TC, its a sad reflection on the state of proof in EMV when cryptographic data fields only appear for decorative purposes. Maybe some knowledgeable reader can shed some light on this?

Marksmen, on your marks!

The beginning of a Call of Duty 4 Search and Destroy game is essentially a race. When the game starts, experienced players all make a mad dash from the starting post, head for their preferred defensive or offensive positions, to dig in before the enemy can bring their guns to bear. From these choice spots, they engage the enemy within seconds, and despite moderately large maps which are a few hundred metres across, up to a third of the kills in a 3-5 minute game do take place in the first 15 seconds. Of course there is skill in figuring out what to do next (the top 1% of players distinguish themselves through adaptability and quick thinking), but the fact remains that the opening of an S&D match is critically important.

I have previously posted about “Neo-Tactics” – unintended side-effects of low-level game algorithms which create competitive advantage. Once a player seems to win without a visible justification this sort of effect causes a problem – it creates the perception of cheating. At a second level, actual cheats might deliberately manipulate their network infrastructure or game client to take advantage of the effect. Well I think I might have found a new one…

The screenshots below give a flavour of the sort of sneaky position that players might hope to be first to reach, affording a narrow but useful line of sight through multiple windows and doorways, crossing most of the map. NB: Seasoned COD4 players will laugh at my choice of so-called sneaky position, but I am a novice and I cannot hope to reach the ingenious hideouts they have discovered after years of play-testing.

Continue reading Marksmen, on your marks!

Card Wars: The Phantom Menace

Just like George Lucas can’t help but return to his old projects, I have been returning to mine. After three years of stagnation, I am pleased to announce the re-launch of, freshly re-vamped, updated and turned into a wiki editable by the general public.

In fact, it’s not just great artists like Mr. Lucas and I starting up old projects, our honourable colleagues wearing the black hats have got the same idea. We have new victims reporting in, rumours abound of an auth system compromise at Citi, the Ombudsman is backlogged with months of disputed withdrawal cases, and some like Alain Job are even going to court.

One original contributor to the phantom case histories has just been hit by a second phantom withdrawal five years on and is chalking up another case in the files. While her new phantom is a bread-and-butter skim incident (a magstripe clone used in the far east), amongst this mass, true phantoms — the real mystery cases — are on the rise too. Two new victims with whom I have been corresponding very kindly offered to fund the hosting for the revamped site.

Let’s consider one of these mysteries. The McGaughey case has been reported in the media in Northern Ireland: dozens of withdrawals taking place over four weeks, totaling almost five thousand pounds, all within a ten mile radius of the McGaughey’s home. Summarised that way it looks like a classic first party fraud (couple short on cash withdraw money, then deny it later). But no-one in the family is short on cash, the McGaugheys look after their card details carefully, and have solid alibis at the time of many of the withdrawals, and the interlocking pattern of real and disputed withdrawals is such that any third party would have a hard time taking and returning the card (whether covertly or in collusion with the McGaugheys). No-one appears to have either the means or the motive.

Unusually the bank has been very cooperative, providing logs from their authorisation system (BASE24), including all of the cryptograms, input data and transaction parameters covering the affected transactions. Everything turns on the Application Transaction Counter (ATC), an on-card counter which increments with every transaction initiated. If an EMV chip can be fully cloned (secret keys and all), then it will have to submit an ATC value when transacting, and if used in parallel with the real card, it won’t be long before the same number pops up twice in the auth system, or large gaps in the sequence appear. The McGaughey’s ATC sequence appears to interlock perfectly: clearly the original card was used?

Of course logs can be misinterpreted (Badger) or even faked, auth systems may not work as expected, and customers may lie and cheat following all sorts of agendas; just around the corner the missing piece of the jigsaw may lie, which reveals the truth behind the case. And there is the totally separate matter of who should suffer the loss in the interim, whilst the truth remains unclear. Liability for disputed withdrawals is the most hotly contested issue of all. can’t do much more for the McGaugheys, but it can bear witness. Documenting the incidence of phantoms and the experiences of customers disputing them adds much needed transparency to the process, and helps researchers and experts seek out the really interesting cases.

Maybe we can lift the lid and discover the truth behind the “phantom menace” — everyone is united in that goal at least — but let’s also hope that Episode 2: Attack of the Clones has not yet started shooting!

Action Replay Justice

It is a sad fact that cheating and rule-breaking in sport gives rise to a lot of bile amongst both competitors and supporters. Think of the furore when a top athlete fails a drugs test, or when the result of a championship final comes down to a judgement call about offside. Multiplayer computer games are no different, and while there may be some rough team sports out there, in no other setting are team players so overtly trying to beat the crap out of each other as in an online first-person shooter. Throw in a bit of teenage angst in 1/3rd of the player base and you have a massive “bile bomb” primed to explode at any moment.

For this reason, cheating and the perception of cheating is a really big deal in the design of online shooters. In Boom! Headshot! I voiced some theories of mine on how a lot of the perception of cheating in computer games may be explained by skilled players inadvertently exploiting the game mechanics, but I have recently seen a shining example in the form of the game Call of Duty 4: Modern Warfare (COD4) of how to address and mitigate the perception of cheating.

First lets review two sorts of cheating that have really captured the imagination of the popular player base: wall hacks and aimbots. With a wall hack, the opponent can see his target even though he is concealed behind an object because the cheat has modified the graphics drivers to display walls as translucent rather than opaque (slight simplification). Aimbots can identify enemy players and assist a cheat in bringing his rifle to bear on the body of the enemy, usually the head. Many players who meet their death in situations where they cannot see how the person has managed to hit them (because they have been hiding, have been moving evasively, or are at great distance) get frustrated and let rip with accusations of cheating. Ironically this sort of cheating is pretty rare, because widespread adoption can be effectively countered by cheat detection software such as punkbuster. There will always be one or two cheats with their own custom software, but the masses simply cannot cheat.

But the trick the Call of Duty 4 developers have used is to make an action replay. Now this has been done before in games for dramatic effect, but crucially COD4 makes the replay from first-person view of the enemy who makes the kill, and winds back a full 5 or 6 seconds before the kill. Should you be unconcerned to see the replay, you may of course skip it. The embedded youtube video shows multiplayer gameplay, with a action replay occurring about 40 seconds in. Now, read on to consider the effect of this…

Continue reading Action Replay Justice

The ATM Protection Racket

EMV (or “Chip and PIN” as it’s known in the UK) is changing the fraud landscape, no doubt about it. Counterfeit card fraud at POS is down, card theft is down, card-not-present is up, phishing is up, ATM fraud is up. Fraud migrates, we get the picture. But as EMV reaches maximal deployment in the next five years or so, the banks and other investors in this technology are hoping that the flood will abate to a trickle, and that some holes can be totally plugged.

I’ve been thinking about whether or not EMV is capable of sorting out the ATM fraud problem (also known as “phantom withdrawals”) once and for all. Well as I wandered around town this afternoon, I snapped some pics at WH Smiths this afternoon of an ATM in distress, and it reminded me how horribly vulnerable our ATM infrastructure is.


It’s not just the “look of vulnerability” exuded by them… like these cheap wafer-locks on the housing of the aforementioned ATM (I’m sure there must be a better lock before the cash safe itself), it’s that all the security is based around keeping the money and the secrets safe, and very little attention is focussed on keeping the machine alive and operating.


Read on to find out my master plan…

Continue reading The ATM Protection Racket

Boom! Headshot!

It’s about time I confessed to playing online tactical shooters. These are warfare-themed multiplayer games that pit two teams of 16 — 32 players against each other, to capture territory and score points. These things can be great fun if you are so inclined, but what’s more, they’re big money these days. A big online shooter like Counterstrike might sell maybe 2 million copies, and tactical shooter Battlefield 2 has almost 500,000 accounts on the main roster. The modern blockbuster game grosses several times more than a blockbuster movie!

In this post, I consider a vital problem for game designers — maintaining the quality of experience for the casual gamer — and it turns out this is somewhat a security problem. People gravitate towards these games because the thrill of competition against real humans (instead of AI) is tangible, but this is a double-edged sword. Put simply, the enemy of the casual gamer is the gross unfairness in online play. But why do these games feel so unfair? Why do you shake the hand of a squash player, or clap your footie opponent on his back after losing good game, but walk away from a loss in a tactical shooter angry, frustrated and maybe even abusive? Is it just the nature of the clientele?

This post introduces a draft paper I’ve written called “Boom! Headshot! (Building Neo-Tactics on Network-Level Anomalies in Online Tactical First-Person Shooters)”, (named after this movie clip”), which may hold some of the answers to understanding why there is so much perceived unfairness. If the paper is a little dense, try the accompanying presentation instead.

Do you want to know more? If so, read on…
Continue reading Boom! Headshot!

How many Security Officers? (reloaded)

Some years ago I wrote a subsection in my thesis (sec 8.4.3, p. 154), entitled “How Many Security Officers are Best?”, where I reviewed over the various operating procedures I’d seen for Hardware Security Modules, and pondered why some people chose to use two separate parties to oversee a critical action and some chose to use three. Occasionally a single person is even deliberately entrusted with great power and responsibility, because there can be no question where to lay the blame if something goes wrong. So, “one, two, or three?”, I said to myself.

In the end I plumped for three… with some logic excerpted from my thesis below:

But three security officers does tighten security: a corrupt officer will be outnumbered, and deceiving two people in different locations simultaneously is next to impossible. The politics of negotiating a three-way collusion is also much harder: the two bad officers will have to agree on their perceptions of the third before approaching him. Forging agreement on character judgements when the stakes are high is very difficult. So while it may be unrealistic to have three people sitting in on a long-haul reconfiguration of the system, where the officers duties are short and clearly defined, three keyholders provides that extra protection.

Some time later, I mentioned the subject with Ross, and he berated me for my over-complicated logic. His general line of argument was along these lines “The real threat for Security Officers is not that they blackmail, bribe or coerce one another, it’s that they help! Here, Bob, you go home early mate; I know you’ve got to pack for your business trip, and I’ll finish off installing the software on the key loading PC. That sort of thing. Having three key custodians makes ‘helping’ and such friendly tactics much harder – the bent officer must co-ordinate on two fronts.”

But recently my new job has exposed me to a number of real dual control and split knowledge systems. I was looking over some source code for a key loading HSM command in fact, and I spotted code that took a byte array of key material, and split it into three components each with odd parity. It generates two fresh totally random components with odd parity, and then XORs these onto the third. Hmmm, I thought, so the third component would contain the parity information of the original key, dangerous — a leakage of information preferentially to the third key component holder! But wrong… because the parity of the original key is known anyway in the case of a DES key… it’s always odd.

I chatted to our chief technical bod about this, and he casually dropped a bombshell — that shed new light on why three is best, an argument so simple and elegant that it must be true, yet faintly depressing to now believe that no-one agonised over the human psychology of the security officer numbers issue as I did. When keys are exchanged a Key Check Value (KCV) is calculated for each component, by encrypting a string of binary zeroes with the component value. Old-fashioned DES implementations only accepted keys with odd parity, so to calculate KCVs on these components, each must have odd parity as well as the final key itself. For the final key to retain odd parity from odd parity components, there must be an odd number of components (the parity of keys could be adjusted, but this takes more lines of code, and is less elegant than just tweaking a counter in the ‘for’ loop). Now the smallest odd integer greater than one is three. This is why the most valuable keys are exchanged in three components, and not in two!

So, the motto of the story for me is to make sure to apply Occam’s Razor more thoroughly when I try to deduce the logic behind the status quo, but I still think there are some interesting questions raised about how we share responsibility for critical actions. There still seems to be to me a very marked and qualitative difference in the dynamics of how three people interact versus two, whatever the situation: be it security officers entering keys, pilots flying an aircraft, or even a ménage à trois! Just like the magnitude of the difference between 2D and 3D space.

If one, two and three are all magical numbers, qualitatively different, are there any other qualitative boundaries higher in the cardinal numbers, and if so, what are they? In a security-critical process such as an election, can ten people adjudicate effectively in a way that thirty could not? Is there underlying logic or just mysticism behind the jury of twelve? Or, to take the jury example, and my own tendency to over-complicate, was it simply that in the first proper court room built back a few hundred years ago, there happened only to be space for twelve men on the benches on the right hand side!

Fraud or feature?

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.

ATM attachment detail side

Continue reading Fraud or feature?

Chip and skim

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.

EMV Interceptor picture

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.