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

Mike Bond, Omar Choudary, Steven J. Murdoch, Sergei Skorobogatov, Ross Anderson
Computer Laboratory, University of Cambridge, UK
[email protected]

Abstract—EMV, also known as “Chip and PIN”, is the card chip, and are more difficult to clone than the magnetic-
leading system for card payments worldwide. It is used strip cards that preceded them.
throughout Europe and much of Asia, and is starting to be EMV was rolled out in Europe over the last ten years, with
introduced in North America too. Payment cards contain a
chip so they can execute an authentication protocol. This the UK being one of the early adopters (from 2003–5). After
protocol requires point-of-sale (POS) terminals or ATMs to it was deployed, the banks started to be more aggressive
generate a nonce, called the unpredictable number, for each towards customers who complained of fraud, and a cycle
transaction to ensure it is fresh. We have discovered two serious established itself. Victims would be denied compensation;
problems: a widespread implementation flaw and a deeper, they would Google for technical information on card fraud,
more difficult to fix flaw with the EMV protocol itself. The
first flaw is that some EMV implementers have merely used and find one or other of the academic groups with research
counters, timestamps or home-grown algorithms to supply this papers on the subject; the researchers would look into their
nonce. This exposes them to a “pre-play” attack which is case history; and quite often a new vulnerability would be
indistinguishable from card cloning from the standpoint of the discovered.
logs available to the card-issuing bank, and can be carried out
The case which kicked off the research we report here
even if it is impossible to clone a card physically. Card cloning
is the very type of fraud that EMV was supposed to prevent. was that of a Mr Gambin, a Maltese customer of HSBC
We describe how we detected the vulnerability, a survey who was refused a refund for a series of transactions that
methodology we developed to chart the scope of the weakness, were billed to his card and which HSBC claimed must have
evidence from ATM and terminal experiments in the field, and been made with his card and PIN at an ATM in Palma,
our implementation of proof-of-concept attacks. We found flaws
Majorca on the 29th June 2011. In such cases we advise
in widely-used ATMs from the largest manufacturers. We can
now explain at least some of the increasing number of frauds in the fraud victim to demand the transaction logs from the
which victims are refused refunds by banks which claim that bank. In many cases the banks refuse, or even delete logs
EMV cards cannot be cloned and that a customer involved during the dispute process, leaving customers to argue about
in a dispute must therefore be mistaken or complicit. The generalities. Some courts have recently criticised banks for
second problem was exposed by the above work. Independent
this and in the Gambin case the bank produced detailed log
of the random number quality, there is a protocol failure:
the actual random number generated by the terminal can data. We observed that one of the fields on the log file, the
simply be replaced by one the attacker used earlier when “unpredictable number” or UN, appeared to be increasing
capturing an authentication code from the card. This variant steadily:
of the pre-play attack may be carried out by malware in an
ATM or POS terminal, or by a man-in-the-middle between Date Time UN
the terminal and the acquirer. We explore the design and
implementation mistakes that enabled these flaws to evade 2011-06-29 10:37:24 F1246E04
detection until now: shortcomings of the EMV specification, 2011-06-29 10:37:59 F1241354
of the EMV kernel certification process, of implementation 2011-06-29 10:38:34 F1244328
testing, formal analysis, and monitoring customer complaints.
Finally we discuss countermeasures. More than a year after
2011-06-29 10:39:08 F1247348
our initial responsible disclosure of these flaws to the banks,
action has only been taken to mitigate the first of them, while
The UN appears to consist of a 17 bit fixed value and the
we have seen a likely case of the second in the wild, and the low 15 bits are simply a counter that is incremented every
spread of ATM and POS malware is making it ever more of few milliseconds, cycling every three minutes.
a threat. We wondered whether, if the “unpredictable number”
generated by an ATM is in fact predictable, this might
I. T HE S MOKING G UN create the opportunity for an attack in which a criminal with
temporary access to a card (say, in a Mafia-owned shop) can
EMV is now the leading scheme worldwide for debit and compute the authentication codes needed to draw cash from
credit card payments, as well as for cash withdrawals at that ATM at some time in the future for which the value of
ATMs, with more than 1.62 billion cards in use worldwide. the UN can be predicted. We term this scenario the “pre-
US banks were late adopters, but are now in starting to issue play” attack.
EMV cards to their customers. EMV cards contain a smart We discovered that several ATMs generate poor random

To appear at the IEEE Symposium on Security and Privacy, 18–21 May 2014, San Jose, CA
 Chip & PIN deployment period
numbers, and that attacks are indeed possible. Even more, ●

300
●

we found that such attacks are also possible when an ATM ●

generates a cryptographically strong random number due to

250
●

a flaw in the protocol. Following our responsible disclosure ●

●
●

200
Losses (£m)
policy, we informed bank industry organisations in early ●

150
2012 so that ATM software can be patched. We are now Card−not−present ● ●

Counterfeit ●
publishing the results of our research so that customers Lost and stolen ●

100
● ●

whose claims for refund have been wrongly denied have the
●
●
Mail non−receipt ● ●
● ●

50
● ●

evidence to pursue them, and so that the crypto, security and Cheque fraud ●
ID theft
●
●
● ●
●
● ●
●
●
●
●
●
●
●
●
●
●
●
●

●
●
●
●
●
●
●
●
●
●
● ●
Phone banking ●

bank regulation communities can learn the lessons. These Online banking ● ●
● ● ●
●
●
●
●
● ● ●

0
are considerable. For engineers, it is fascinating to unravel 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013
why such a major failure could have been introduced, how Total, ex phone (£m) 503 491.2 591.4 704.3 529.6 441.4 410.6 463 518.9
Year
it could have persisted undiscovered for so long, and what
this has to tell us about assurance. At the scientific level,
it has lessons to teach about the nature of revocation in Figure 1. Fraud levels on UK-issued payments cards [1]
cryptographic protocols, the limits of formal verification,
and the interplay between protocol design and security
economics. Many countries, including the UK, moved to authenticat-
The rest of this paper is organised as follows. In Section II, ing cardholders with a PIN rather than a signature at both
we give the high-level background, telling the history of POS and ATM, where previously PINs had only been used at
EMV and discussing its effect on fraud figures overall. In ATMs. The goal was to make it harder to use a stolen card.
Section III we give the technical background, describing This simultaneous introduction gave rise to the term “Chip
how an EMV transaction works, and how our “pre-play” and PIN” being commonly used in the English-speaking
attack can be mounted. Section V describes our experimental world to refer to EMV. In layman’s terms, the chip protects
methods and results: how we developed a data capture against card counterfeiting, and the PIN against stolen card
card to harvest UN sequences from ATMs, and what we abuse.
learned from examining second-hand ATMs bought on eBay. EMV did not cut fraud as its proponents predicted. While
Section VI describes the protocol flaw, and Section VII using counterfeit and stolen cards did become more difficult,
discusses the possible defences. Section VIII presents our criminals adapted in two ways, as can be seen from Fig-
scientific analysis: what the crypto and security communities ure 1. First, they moved to “card-not-present” transactions
should take away from this, how EMV can be made more – Internet, mail-order, and phone-based payments – which
robust, and how such failures can be made less likely in remained beyond the scope of EMV.
future large-scale systems that employ cryptography for Second, they started making magnetic-strip clones of
authentication and authorisation. Finally in Section IX we EMV cards. There had always been some ATM “skim-
draw some conclusions. ming” where crooks put devices on ATM throats to cap-
ture card data and record PINs; and now that PINs were
II. BACKGROUND demanded everywhere and not just at ATMs, the oppor-
tunities for skimming increased hugely. The simultaneous
EMV (named after its original developers Europay, Mas- deployment of EMV with magnetic strip meant that fallback
terCard and Visa) was developed in the mid 1990s to tackle and backwards-compatibility features in EMV could be
the developing threat of magnetic strip card counterfeiting, exploited; for several years, all ATMs would still accept
where organised crime gangs with access to card manufac- mag-strip cards, and even once this started to be phased
turing equipment produced cloned cards using data from dis- out in the UK for locally-issued cards, it was still possible
carded receipts, or skimmed surreptitiously from legitimate to use mag-strip clones of UK cards in ATMs in the USA.
cards, first at point-of-sale (POS) and later at automated This is why, soon after the completion of the UK EMV roll-
teller machines (ATMs). The payment terminal executes out in 2005, counterfeit fraud went up. Instead of entering
the EMV protocol with the chip, which exchanges selected PINs only at ATMs, customers were now entering their PIN
transaction data sealed with a cryptographic message au- in POS terminals, which are much easier to tamper with [2].
thentication code (MAC) calculated using a symmetric key Total fraud levels were brought down after 2008 through
stored in the card and shared with the bank which issued improvements to back-end fraud detection mechanisms; by
the card (the “issuer”). The idea is that the bank should be more aggressive tactics towards customers who dispute
able to detect a counterfeit card that does not contain this transactions; and by reducing the number of UK ATMs
key, and the physical tamper-resistance of the chip should that accept “fallback” magnetic-strip transactions on EMV-
prevent an attacker from extracting the key. issued cards. Fallback fraud is now hard enough to push the
criminal community to more sophisticated smart-card-based 3) transaction authorization in which the issuing bank
attacks. decides whether the transaction should proceed.
Prior research showed that it was possible to use a stolen The principals are the card, the ATM and the issuer1 . The
EMV card in a POS device without knowing the PIN. Given process is illustrated in Figure 2. The description below
a suitable man-in-the-middle device, a crook can trick the has been somewhat simplified, and represents typical UK
terminal into believing that the right PIN was entered, while transaction flow. Other countries may differ slightly, but will
the card thought it was authorising a chip-and-signature be substantially similar.
transaction [3]; criminals have now gone on trial in France During card authentication, the card provides data records
for exploiting this “no-PIN” vulnerability [4]. to the ATM, which include the card number, start and expiry
However, the “no-PIN” vulnerability does not explain all dates and which protocol options the card supports. The card
the cases where people contacted the authors having been also provides a static RSA digital signature over selected
refused a refund for an ATM or POS transaction which they records, which aims to prevent crooks from fabricating cards
adamantly deny having made. One such case was that of from known or guessed account numbers. Some cards also
Alain Job who sued his bank for a refund, but lost after provide dynamic signature generation capabilities, known as
the judge concluded that the customer’s card was probably “Dynamic Data Authentication” (DDA).
used, not a clone [5]. In that case, the bank destroyed the log Following card authentication, cardholder verification pro-
files despite the fact that a dispute was underway, contrary ceeds by signature or PIN. In an ATM transaction the card
to Visa guidelines, and the judge warned that a court might is not involved in this. The customer enters their PIN on
not be so tolerant of such behaviour in the future. the PIN pad, where it is encrypted and returned to the card
The number of such cases is unknown. The UK fraud issuer for verification through the ATM network.
figures quoted above only count losses by banks and by Finally, transaction authorization is carried out. The ATM
merchants, not those for which customers are blamed; and sends to the card various transaction fields: the amount, the
since the introduction of EMV, the banks have operated currency, the date, the terminal verification results (TVR –
a “liability shift” as they describe it, which means that the results of various checks performed by the ATM), and a
when a transaction is disputed, then if a PIN was used nonce (in EMV terminology, the “unpredictable number” or
the customer is held liable, while if no PIN was used UN). The card responds with an authorization request cryp-
the transaction is charged back to the merchant. Disputed togram (ARQC), which is a cryptographic MAC calculated
transactions where the bank’s records show a PIN was used over the supplied data, together with some card-provided
are seen by the banks not as frauds against the customer but data including the application transaction counter (ATC –
as attempted frauds by the customer (or perhaps negligence a 16 bit number stored by the card and incremented on
by the customer) regardless of the fact that the no-PIN attack each transaction) and the issuer application data (IAD – a
falls into this category. This may be ideal from the banks’ proprietary data field to carry information from the card to
viewpoint but is less so for their customers. The 2008/2009 its issuer).
British Crime Survey [6] found that 44% of fraud victims The ARQC is sent by the ATM to the issuer along with
didn’t get all their money back, despite both bank guidelines the encrypted PIN. The issuer verifies the PIN and checks
and the European Payment Services Directive requiring that the ARQC by recalculating the MAC over the received data
customers who have not acted negligently or dishonestly fields. Additional checks include whether sufficient funds
be refunded. Of the 44% who were not fully refunded for are available, that the card has not been reported stolen,
their losses, 55% lost between £25 and £499 ($40 to $790) and risk-analysis software does not flag the transaction as
and 32% lost £500 or more. So there’s a large gap between suspicious. Then the issuer returns to the ATM an autho-
the banks’ statistics and those from the crime survey. We rization response code (ARC) and an authorization response
believe that the vulnerability we expose in this paper could cryptogram (ARPC) destined for the card.
explain some of it; Mr Gabin’s case is not the only one The ARC authorises the ATM to dispense cash, which
that has come to us where the attack we describe here is a in turn passes the ARC and ARPC also to the card. The
compelling explanation. card verifies the ARPC (which is typically a MAC over
the ARQC exclusive-or’ed with the ARC), and returns an
III. OVERVIEW OF AN ATM TRANSACTION authenticated settlement record known as a transaction cer-
tificate (TC), which may be sent to the issuer immediately,
An EMV transaction consists of three phases:
or some time later as part of a settlement process.
1) card authentication in which card details are read
and authenticated by the ATM or POS terminal; 1 The bank that operates the ATM (the acquirer) and the network that links

2) cardholder verification in which the person who the issuer to the acquirer are also involved in settlement, dispute resolution
and assurance, but they do not participate in the authentication protocol run
presents the card is verified whether by PIN or sig- other than to route messages, so have been omitted from the discussion in
nature; and this section.
issuer ATM card EMV command protocol phase
select file 1PAY.SYS.DDF01
available applications (e.g Credit/Debit/ATM) SELECT/READ RECORD

select application/start transaction SELECT/ Card authentication

GET PROCESSING OPTIONS
signed records, Sig(signed records)
READ RECORD...
unsigned records

Cardholder verification

T = (amount, currency, date, TVR, nonce, ...)

GENERATE AC
ARQC = (ATC, IAD, MAC(T, ATC, IAD))
T, ARQC, encrypted PIN
ARPC, ARC
Transaction authorization
ARPC, ARC EXTERNAL AUTHENTICATE/
TC = (ATC, IAD, MAC(ARC, T, ATC, IAD)) GENERATE AC
TC

Figure 2. Outline of an EMV transaction at ATM. Note that while the messages between card and ATM have been verified, messages between issuer
and ATM may vary depending on card scheme rules

POS transactions proceed similarly, except that cardholder The specification flaw that enables the basic pre-play
verification is usually performed by sending the PIN to the attack is that EMV does not include the identity of the
card which checks it against a stored value. Whether the PIN terminal – a classic protocol mistake; in fact it’s strikingly
is verified locally or online makes no difference to the attack reminiscent of the notorious Woo-Lam protocol [7]. While
discussed here. If a POS device generates unpredictable the EMV framework can support this through designation
numbers that can in fact be predicted, then it too will be in a list of fields to be MACed in the ARQC (the CDOL1),
vulnerable to a pre-play attack. the standard format developed by Visa (the version 10
cryptogram format [8]) requires only the terminal country
IV. T HE TWO VARIANTS OF THE PRE - PLAY ATTACK code. The country in which the attacker will use its skimmed
data is trivial to predict in advance.
In a normal EMV transaction the card sends an ARQC to
the ATM to prove that it is alive, present, and engaged in The specification flaw means that when an ATM or POS
the transaction. The ATM relies on the issuer to verify this terminal generates predictable random numbers, there is
and authorise the transaction. Simply replaying an ARQC a “pre-play” attack – authentication data are collected at
should not work, because a competent issuer prevents replay one moment in time, and played to one or more possible
by rejecting any transaction whose application transaction verifying parties at some later time that is already determined
counter (ATC) it has already seen2 . The ATC prevents when the data are harvested. The practical implementation is
simple replay attacks but cannot assure the issuer that the that a tampered terminal in a store collects card details and
ARQC was computed today rather than yesterday. To ensure ARQCs as well as the PIN from a victim for use later that
freshness, a nonce is used – the unpredictable number (UN). day, or the following day, at ATMs of a given type. Indeed,
This is a 32 bit field generated by the ATM. However, if the attacker knows how to predict the UNs in a given
we have discovered two major flaws that make the UN make of ATM, he can harvest ARQCs for use in any ATM
almost redundant: (a) a specification and engineering flaw of that type in a given country and at a given date in the
that results in predictable UNs that can be exploited; (b) a future. We will discuss this variant in detail in Section V.
deeper, more difficult to fix protocol flaw, which allows an The deeper protocol design flaw is that while the terminal
attacker to choose an arbitrary UN with the pre-play attack. generates the random number, it is the issuing bank that
These flaws, together with an additional classical protocol relies on it. This means that a man-in-the-middle device
mistake make the entire EMV system vulnerable to the pre- between the terminal and the bank can be used to attack
play attack. a system where the random number generation is sound.
The attacker records an ARQC in response to the nonce
2 We have seen incompetent issuers who accepted repeated transactions N , and presents it to a terminal that actually generated the
with the same ATC. nonce N 0 . The terminal sends the ARQC along with the
transaction data and N 0 to the bank; the MITM changes N 0 1) Analysis of log files: We regularly investigate ATM
to N ; and the transaction may well be accepted. This means withdrawals on behalf of customers in dispute with their
that a terminal infested with malware can debit your card banks. In most cases the level of detail in logs provided by
not once, but multiple times, and for arbitrary amounts. We the bank is low, but in a minority of cases detailed logs are
will discuss this variant in detail in Section VI. handed over. The Palma case got us started on this research
track, and we found one or two other cases of suspicious
V. P RE - PLAY ATTACKS BASED ON A WEAK RNG
UNs in logs.
The EMV protocol designers did not think through care- Following our responsible disclosure of this vulnerability
fully enough what is required for the UN to be “un- to the banks and card brands, we delivered our random
predictable”. The specifications and conformance testing number analysis toolkit to several parties but so far received
procedures simply require that four consecutive transactions little or no feedback at all about their findings. We suggest
performed by the terminal should have unique unpredictable that anyone in dispute with a bank over ATM transactions
numbers [9, test 2CM.085.00]. Thus a rational implementer where this vulnerability might be an explanation should
who does not have the time to think through the conse- subpoena the bank’s logs for analysis.
quences will probably prefer to use a counter rather than a We have also discussed the vulnerability with a large
cryptographic random number generator (RNG); the latter online services firm, but it turned out that they do not retain
would have a higher probability of failing conformance records of the UN.
testing (because of the birthday paradox). We are particularly interested in collecting UN data from
The latest version of the EMV specification [10, Book 4, Italy, which is the only country of which we are aware where
p57] offers some guidance as to how to generate the un- UNs are routinely printed on all customer receipts.
predictable number, but previous versions left the algorithm 2) Active probing of ATMs: Even where ATM logs are
entirely up to implementers. Even the suggested construc- available, the timestamps have an accuracy of only a second
tion (hash or exclusive-or of previous ARQCs, transaction or so rather than a millisecond, so perhaps only grossly non-
counter and time) would not be adequate for generating random UN generation algorithms can be identified. For both
a truly unpredictable number because the ARQCs would researchers and crooks, a better data collection approach is
be zero if the ATM was rebooted and both the time and required. This needs to be moderately covert as the public
transaction counter are predictable. Yet if the attacker can are aware of the problem of ATM skimming; using primitive
predict an “unpredictable number” ahead of time, he can analysis tools repeatedly at an ATM may be a way to get
harvest ARQCs from a card one day and use them at the arrested.
ATM the next. We therefore constructed a set of passive monitoring
For example, in the case of the ATM in Palma that cards by adding our own ATM protocol analyser circuitry,
started this line of research, the counter rolls over every consisting of an additional microcontroller with data storage
three minutes, so an attacker might ask a card in his store memory, to a standard debit card. This was done as follows.
for twenty ARQCs at points in the 15-bit counter’s cycle. First, the plastic from the rear side of the card, above the
On visiting the ATM he could use his attack card to first chip, was removed with a knife thus exposing the chip
calibrate the ATM’s counter, and then initiate transactions package. Then a cheap engraving tool with a flat metal cutter
when the counter is expected to be at a value for which he was used to carefully mill away some plastic between the
has a captured ARQC. chip slot and the card edge (Figure 3 top left). This was done
This is all very well in theory, but is it viable in practice? carefully so as not to remove too much plastic and to avoid
We decided to find out. cutting through to either the card edge or the card face. The
A. Experimental Method and Results chip itself, being encapsulated in epoxy, is relatively well
Pre-play attacks against EMV have been discussed theo- protected from mechanical damage during this surgery.
retically before, but for a real-world attack to work, there Then we fitted a Microchip PIC18F24K22 in a 0.5 mm
are many practical challenges. In this section we describe thin UQFN package into this space, glued some protection
our own approach to them: surveying for an exploitable resistors to the plastic next to the chip and wired them up
vulnerability, skimming data, and deploying the attack. Each to the terminal pins using thin wires. This microcontroller
stage of the process must be completed by criminals with operates from 1.8 V to 5.5 V, so can be connected directly
reasonable yield and an acceptably low cost (including to the card terminals; but as we used a 3.3 V memory chip
probability of being caught). for fast data storage, some additional power control and
interfacing circuitry was added in thin packages of 0.3 mm
B. Identifying vulnerable ATMs to 0.5 mm (Figure 3 top right). The memory chip came in
To identify vulnerable ATMs we took three approaches: a standard 0.7 mm WSON package, so we had to slim it
analysis of log files, collection of UNs in the field, and to 0.5 mm; it was carefully milled on sandpaper, removing
reverse engineering of ATMs. 0.15 mm from the front and 0.05 mm from the back. Then it
 Figure 3. Passive monitoring card containing real EMV chip, with monitoring microcontroller and flash storage

was glued inside the card (Figure 3 middle left). Finally all handling between harvesting attempts. This conflicted with
the components were wired together (Figure 3 middle right). our desire to maintain a low profile by behaving as a normal
This process required a magnifying glass as some compo- ATM user, so normal practice became to transfer the card
nents have a 0.4 mm pin pitch. A special card interface was from safe storage to wallet while approaching and leaving
built for programming the microcontroller and downloading the ATM. To guard against losing track of which UNs were
the ATM transaction data to a PC via an RS-232 connection harvested from which ATMs after a day in the field, we
(Figure 3 bottom-left). After initial laboratory testing, the inserted dummy transactions into the stream recorded by
area with added circuitry was filled with epoxy and tested the logger. This was done by using the card to perform a
with calipers to ensure it still fit the 0.8 mm card profile, test transaction with a terminal emulator on a laptop back
so that the card would not get stuck in an ATM (Figure 3 in the car.
bottom-right). The epoxy potting protected the circuitry but The modified card remains a valid payment card – the
made that part of the card more brittle - requiring careful transaction flow proceeds as normal – so it should always
be accepted. However, it can be inserted into a variety of
ATMs and POS devices without arousing suspicion3 . More
primitive approaches with a card wired to a laptop leave
wires trailing from the slot and may cause problems in ATMs
that hold the card internally during reading.
Other possible monitoring equipment includes wireless
relay cards transferring data to a card outside, a wired card
adapted to be compatible with ATM card slots, an overlaid
shim glued on top of a thinned-down existing card, or an
ultra-simple shim consisting simply of an antenna suitably
connected to the card data line (which we could observe
using “TEMPEST” techniques).
In the case of POS terminals, sales assistants are often
briefed to turn away during PIN entry and avoid handling
the customer card. Thus existing monitoring tools such as
the Smart Card Detective [11] have been proven suitable
Figure 4. ATMs acquired for reverse-engineering
for surreptitious use with a hidden wire running up the
experimenter’s sleeve. We used the Detective to analyze
unpredictable numbers from a POS terminal close to our containing a hardware random or pseudo-random number
offices, with the agreement of the POS owner. source. Currently we are confident that each byte of the
For each ATM investigated, we harvested between five unpredictable number is independently generated from an
and fifty unpredictable numbers by performing repeated off-CPU resource. This would either be the DES chip, a real-
balance enquiries4 and then a small cash withdrawal. The use time clock (also present as a separate chip) or possibly the
of balance enquiries minimises the number of withdrawals smart card control unit which is a MagTek board accessed
on the card, as sudden repeated withdrawals might trigger via a serial interface.
a fraud detection system and cause the card to be retained. At the outset we believed that older, primitive platforms
Such cards cost a few hundred pounds in component and would be less likely to have a strong source of randomness
labour costs so it is desirable to avoid their being captured than modern platforms in all cases. However our broader
by ATMs. research across ATM and POS indicates a subtly different
3) Reverse engineering ATM code: In order to get a better conclusion. Entirely modern platforms are likely to call the
understanding of the generation of unpredictable numbers typical OS resources for random number generation, which
inside ATMs we acquired two real machines for analysis. nowadays are relatively strong. Meanwhile legacy platforms
Figure 4 shows EMV-enabled NCR and Hanco/Triton ATMs may have either strong or very weak randomness depending
acquired via eBay for £100 each. Some of these had been on whether this issue was thought about by the designers
in recent service, and some were out of service, having only at the time. Curiously, legacy platforms which have been
been used for development. Barnaby Jack [12] described ported to more modern environments are most likely to have
how second-hand ATMs can be brought back into service weak randomness as during the porting the random number
easily by simply phoning for a repairman. generate custom call on the legacy platform is simply
We have performed an analysis of the hardware and mapped across to the easiest standard library call, such as
software of the two ATMs, although our analysis has been the C rand() function. In summary, it is as important to
complicated by the obsolete architectures. We found that consider the lineage of the ATM or POS software as it is to
one ATM was running OS/2 (see Figure 5(a)), and another consider the current platform when estimating the likelihood
on primitive hardware based on the Zilog Z180 CPU (see of vulnerability.
Figure 5(c)). We identified the manufacturer of the EMV
kernel from information inside the ATM, and documentation C. Analysing the RNG
on their website [13] indicates that the EMV kernel requires In Section V-B2 we described our own approaches to data
seeding with an external source of randomness. Hardware collection. Using this approach we collected data to analyse
analysis revealed presence of a dedicated crypto chip im- the RNGs in EMV devices in our local area. We performed
plementing DES (see Figure 5(b)) and we theorise also more than 1,000 transactions across 22 different ATMs and
five POS terminals. We were successful at locating ATMs
3 For ethical and prudential reasons we informed the Metropolitan Police
with weak RNGs, but attackers need to go further and
that such experiments were underway; we also consulted our local ethics identify which specific UNs are most likely to occur at a
process.
4 It seems all transactions at ATM are authenticated by EMV protocol predictable future time. There are three broad classes of
runs, but some with a zero withdrawal amount. ineffective RNG to consider:
 • an obviously weak RNG algorithm. This includes
using counters or clocks directly as the UN, homegrown
algorithms which combine obvious transaction data,
and severe programming errors which cause the state-
space of a better algorithm to be limited (e.g. casting
down to the wrong integer size, or submitting four
BCD coded random bytes rather than four truly random
bytes);
• a simple RNG with little or no seeding. There
are many flavours, from a linear congruential gener-
ator, through encryption of the clock, to more messy
schemes where we may find some fixed bits and some
bits that cycle, or where a state machine starts off
appearing random but ends up in a tight loop cycling
through just a small number of values. From an em-
bedded systems standpoint the typical options are the C
standard library time() and rand() calls, neither of
which have unpredictable outputs from a cryptographic
point of view;
• an RNG that can be put into a predictable state.
The simplest failure mode is a strong RNG fed by a
weak source of randomness that’s restarted on power-
up, so an attacker can force an outage or follow the
replenishment crew. There are also proposed RNG
(a) Extracting disk image from NCR ATM algorithms drawing noise from an untrustworthy source,
such as when an RNG uses data from previous trans-
actions. The attacker could insert a card which seeds
the RNG with known values, or temporarily spoof the
authorisation response from the bank, to push the RNG
into a predictable state.
Table II(a) shows a selection of data collected from
various ATMs falling broadly into the first category of
ineffective algorithms. ATM1 and ATM2 contain a typical
characteristic, which we denote characteristic C, where the
high bit and the third nibble of each UN are always set to
zero. This alone reduces the entropy of the unpredictable
numbers from 32 to 27 bits. 11 of 22 ATMs we looked at
exhibited this characteristic.
Such patterns allow us to prove a non-uniform hypothesis
(b) Board with DES chip from Triton ATM on the data from most of these 11 ATMs with a very good
significance level. Table I shows two ten-transaction se-
quences from an ATM where the characteristic was proven.
However further analysis beyond confirming this characteris-
tic has not yielded statistically significant results yet. ATMs
of wildly different ages and running different operating
systems exhibited characteristic C, so we believe it to be
an artifact of a particular EMV kernel post-processing an
RNG source rather than of the RNG source itself.
We wondered whether ATM and POS devices were simply
be using the C standard library rand() function, or other
weak sources, and analysed our data using techniques based
(c) CPU board from Triton ATM on spectral tests. Such analysis was complicated by the
unknown levels of post-processing of the RNG: for example,
Figure 5. Detail of hardware reverse engineering we know in the case of one EMV library that each byte of the
 Table I Table II
T EN TRANSACTION SEQUENCES FROM A SINGLE ATM C ATEGORISED UNPREDICTABLE NUMBERS

(a) From Various ATMs

SRC2 EXP6 SRC2 EXP6B
Counters Weak RNGs
0 77028437 0 5D01BBCF
1 0D0AF8F9 1 760273FE ATM4 eb661db4 ATM1 690d4df2
2 5C0E743C 2 730E5CE7 ATM4 2cb6339b ATM1 69053549
3 4500CE1A 3 380CA5E2 ATM4 36a2963b ATM1 660341c7
4 5F087130 4 580E9D1F ATM4 3d19ca14 ATM1 5e0fc8f2
5 3E0CB21D 5 6805D0F5
6 6A05BAC3 6 530B6EF3 ATM5 F1246E04 ATM2 6f0c2d04
7 74057B71 7 4B0FE750 ATM5 F1241354 ATM2 580fc7d6
8 76031924 8 7B0F3323 ATM5 F1244328 ATM2 4906e840
9 390E8399 9 630166E1 ATM5 F1247348 ATM2 46099187

ATM3 650155D7
ATM3 7C0AF071
ATM3 7B021D0E
unpredictable number is sampled separately from the RNG ATM3 1107CF7D
– hence a modulo 256 or a type-cast is almost certainly post-
processing the output. Multiple calls to the RNG to produce (b) From local POS terminal
one UN makes fewer bits available to detect state per sample,
but making four consecutive calls in a row for one UN Stronger RNGs
reduces the potential interference from other services within POS1 013A8CE2
an ATM. POS1 01FB2C16
The third category could possibly be spotted from empir- POS1 2A26982F
POS1 39EB1E19
ical analysis but are best detected with reverse-engineering. POS1 293FBA89
In Table II(b) we show a list of stronger consecutive unpre- POS1 49868033
dictable numbers retrieved from a local POS terminal. Even
in this case the first bit appears to remain 0, which might
suggest the use of a signed integer.
Once UN generation is adequately understood, the attack- E. Cashing out
ers figure out what UNs to collect in order to maximise
the yield in the subsequent cash-out phase. The result is To deploy the attack against an RNG which is a fast-
a target ATM profile which is sent together with intended moving counter such as we have observed, the attacker needs
withdrawal amounts, country code and date to the gang to start the ATM transaction at precisely the right moment.
tasked with harvesting the ARQCs. Once a vulnerable ATM For a counter ticking hundreds or even thousands of times
using the known RNG is identified, the attack flow can a second, it is impractical to synchronise merely through
proceed further. timed insertion of the card into the machine. A special smart
card can be built to observe the counter and use an on-
D. Harvesting the data board clock to decide when to initiate the relevant parts of
Given temporary access to an EMV card, whose holder the protocol. Smart cards are allowed to delay processing
is prepared to enter the PIN, and a range of possible responses almost indefinitely using the request more time
unpredictable numbers to be harvested, the crook programs signal (i.e. sending byte 0x60), and timely insertion to the
his evil terminal to read the static data from the card and call nearest second will mean that the card should never need to
GENERATE AC to obtain an ARQC and TC for each pos- delay more than a few hundred milliseconds.
sible UN. This process could be performed by a dedicated Such a specialised smart card might use an on-board
device, or by a tampered point of sale terminal, vending real-time clock (RTC), kept working in the absence of
machine, or ATM, programmed to perform these operations external power by a large capacitor. The RTC is used to
after (or instead of) a legitimate transaction. Criminals have synchronise an internal high resolution timer once the card
already shown the ability to tamper with equipment on an is powered up, and waits the necessary amount of time until
industrial scale and with great sophistication. the ATM arrives at the step in the EMV protocol where the
For each card a set of ARQCs can be harvested, perhaps unpredictable number is sampled.
many dozens. The only limitation is the time that the card The feasibility of this attack depends on the speed of the
can legitimately be left in a sabotaged POS while the cus- timer, the process by which the ATM samples the timer, and
tomer believes that the machine is waiting for authorisation. the synchronisation resolution of the card. However there
Thirty seconds is the standard authorisation time limit; this are straightforward ways to relax the timing requirements:
might allow for more than 100 transactions to be skimmed. the attackers harvest a set of transactions with consecutive
 2) two transactions performed on card B
3) traces of transactions compared, GENERATE AC re-
sponses confirmed the same, proving both cards have
the same cryptographic keys and are generating the
same cryptograms (they are identical)
4) two ARQCs skimmed from card A
5) pre-play card programmed with data from data col-
lected from card A
6) two transactions performed on card B
7) two transactions performed on pre-play card
8) traces of transaction compared and shown to be identi-
cal, confirming that pre-play card is indistinguishable
from card B
Figure 6. Modified Chip and PIN terminal, playing Tetris
VI. T HE DEEPER PROBLEM : PRE - PLAY ATTACKS DUE TO
THE PROTOCOL FLAW
unpredictable numbers, and the attack card makes its best Even if the UN generation algorithms are patched, a num-
attempt at synchronisation. Once the card sees the unpre- ber of protocol attack variants may make pre-play attacks
dictable number returned by the ATM it looks this up in viable for years to come.
an internal lookup table. If the UN is not found, the card • Malware infection. There are already numerous cases
can feign failure. So if ten transactions are harvested from of malware-infected ATMs operating in Eastern Europe
the skimmed card, the timing requirements can perhaps be and depending on the internal architecture of the ATM
relaxed by a factor of ten as well. it may be easy for such malware to sabotage the choice
In the case of ATMs employing stateful predictable of UN. In fact one bank suggested to us that the ATM
pseudo-random RNGs, the implementation details differ: that kicked off this whole research project may have
the attacker samples a few unpredictable numbers and can been infected with malware [14].
then predict subsequent ones. In any case, synchronisation • Supply chain attacks. Such attacks have already been
technology can be developed and tested entirely offline seen against POS terminals in the wild, and used to
against captive ATMs without any need to interact with the harvest magnetic strip data. So it is feasible that a crim-
real payment network. inal (or even a state-level adversary) might sabotage
We show an illustration of this attack in Figure 7 (left). the RNG deliberately, either to act predictably all the
time, or to enter a predictable mode when triggered
F. Implementation and evaluation
via a covert channel. A suitably sabotaged RNG would
We have constructed proof-of-concept implementations probably only be detected via reverse engineering or
for all stages of the attack. As discussed above, we modified observation of real world attacks.
a bank smart card for data collection to identify ATMs • Collusive merchant. A merchant might maliciously
with poor UN generation. To collect card data we have modify their EMV stack to be vulnerable, or inject
implemented a Python EMV terminal implementation and replayed card data into the authorisation/settlement sys-
modified an EMV terminal to collect card data, as shown in tem. He could take a cut from crooks who come to use
Figure 6. To carry out the attack we implemented a cloned cloned cards at their store, or just pre-play transactions
card on the ZeitControl BasicCard platform. directly. In the UK, there was a string of card cloning
We used test cards with known ARQC-generation keys attacks on petrol stations where a gang bribed store
(UDK) to prove the viability of the attack at a protocol level. managers to look the other way when PIN pads were
Our proof consists of an indistinguishability experiment; we tampered with and monitoring devices inserted into
take two test cards A and B loaded with the same ARQC- network connections; exactly what you need to deploy
generation keys, initialised with the same ATC and handled a pre-play attack. We have recently seen a transaction
identically. We use our skimming trace to harvest data from dispute in which a customer claims to have made one
card A and then program it on to a “pre-play card”. We then small purchase at a merchant yet his bank claims he
compare traces between the pre-play card version of card A made six large ones too.
and the real card B, and observe that they are identical. This • Terminal cut-out. A variant is the terminal cut-out
means that at a protocol level it is impossible for the ATM or bypass, where the transaction stream between the
to distinguish between the real and pre-play cards. In detail merchant terminal and the acquirer is hacked to mis-
the flow is as follows: report the unpredictable number when triggered by a
1) two transactions performed on card A particular signal (e.g. a particular account number or
 Pre-play attack via weak RNG Pre-play attack via manipulation of UN
between ATM and bank
Step 1: profile ATM/POS

Step 1: harvest

Perform genuine transaction

(optional)

Request ARQC for chosen UN

UN list Receive ARQC for chosen UN

(from ATM profiling)

Step 2: harvest
Perform genuine transaction Step 2: cash out

(optional)

Request ARQC for target UNs

Receive ARQC for target UNs

UN1 (from ATM)

Replay transaction
Step 3: cash out from chosen UN
(ignore UN1)

UN Replace UN1 for chosen UN

in transaction data from ATM to bank
Table of UNs:
ID | UN | ARQC | TX DATA
1 | ----- | --------- | ----
2 | ----- | --------- | ----
…. Replay transaction
from list

Figure 7. Overview of the pre-play attack using a weak RNG (left) or tampering with the UN at the ATM/POS side (right)

a known ARQC). This transaction data stream is not tive way to attack merchants that process high-value
normally considered sensitive within the threat model transactions, such as jewelers or investment firms, who
and can be altered at will by merchant software. The might guard their premises and take care of their POS
attackers’ card performing the replay can then use equipment yet still fall to a targeted attack. A pre-
any UN for which it has an ARQC, and the true play attack would be much harder to detect than old-
random UN made up by the terminal will never see fashioned attacks that just convert deny authorisation
the light of day. This is hard to block: there is no messages into approve messages.
provision in currently deployed EMV cards for the Using these versions of the pre-play attack (Figure 7 right)
terminal to confirm that its choice of UN was correctly it is no longer necessary to profile an ATM or POS terminal.
included in the cryptographic MAC. The terminal cut- The attacker can simply choose an arbitrary UN and obtain
out could be implemented in malware (and there’s the related transaction data, including the ARQC, from the
evidence of bank botnets looking for POS devices), or victim’s card. Then he can replay the transaction data at a
in a merchant’s back-end system (we have evidence of terminal and replace the terminal’s real UN with his chosen
merchants already tampering with transaction data to one (via any of the methods described above).
represent transactions as PIN-verified when they were The key shortcoming of the EMV protocol is that the
not, so as to shift liability). party depending upon freshness in the protocol is not the
• UN modification in the network. A man-in-the-middle party responsible for generating it. The issuer depends on the
device between a POS device and the acquiring bank, merchant for transaction freshness. The merchant may not
perhaps at a network switch, would also be a good have the incentive to provide it, may not be able to deliver
way to deploy such an attack. This could be an attrac- it correctly due to lack of end-to-end authentication with the
issuer, and might even be collusive (directly or indirectly). It is well known that the assumptions used in the 1970s
Recently there has been some formal analysis of EMV, by the pioneers of authentication were undermined by
but this flaw was not discovered [15]. One reason is that later “progress”. The Needham-Schroeder protocol [18],
the UN was modelled as a fresh nonce, even though this famously has a “bug” in that the protocol can stall for
is not required by EMV (this omission is understandable an extended period of time between the third and fourth
given that the actual specification of the UN is buried on messages, with the effect that old session keys once compro-
p1498 in an annex to the EMV specifications, totalling over mised cannot be revoked. Needham and Schroeder defended
4,000 pages). The other is that the issuer and terminal are themselves by pointing out that their paper had quite openly
modelled as the same individual, whereas in reality the assumed that principals executed the protocol faithfully;
relying party is the issuer and has only limited control over therefore such behaviour was a priori excluded from their
the terminal behaviour. In fact, the terminal communicates model. Our modern world of equipment that fails from time
with an acquirer that in turn sends the transactions to a to time, and where life is spiced by the occasional malicious
switch that finally relays the transactions to the issuer. insider, requires us to be more careful with revocation.
As a next approximation, let’s abstract away the acquirer In exactly the same way, the deployment of a system
and the switch, and consider the EMV protocol in an ideal like EMV across an ecosystem with hundreds of vendors,
world containing only one bank. The protocol might be thousands of banks, millions of merchants and billions of
idealised as (where A is the ATM, B is the issuer, and C is cards requires us to be much more careful about who the
the card): principals are, and the incentives they have to execute their
tasks competently. Indeed, one of the new realities of the
A −→ C : N, V, T EMV world is that merchants and banks may be hostile par-
C −→ A : {N, V, T }KCB ties in the payment system, thanks to tussles over payment
A −→ B : {A, {N, V, T }KCB }KBA transaction charges and chargebacks. There have been large
B −→ A : {A, ok}KBA lawsuits between major retailers and payment networks, and
we are aware of cases where merchants deliberately falsify
An analysis using BAN logic [16] would note that KCB
record data (e.g. by claiming that transactions were PIN-
is a good key for communicating between the card and the
verified when they were not [19]) so as to push fraud costs
bank, so the bank knows that the card once said N , V and
to the bank and reduce chargebacks.
T ; if it concludes that N is fresh, then it will infer that the
So if issuing banks cannot trust merchants to buy ter-
card said all this in the current epoch. However N is not
minals from vendors who will implement decent random
the card’s nonce NC , but the terminal’s nonce NT , and we
number generators, what can be done?
can’t infer anything once we formalise this carefully.
In real life, we cannot rely on communications between VII. L IMITATIONS AND D EFENCES
the merchant and the card issuing bank to be protected The limitations of a pre-play attack are:
by encryption or even authentication. This is a well-known
• The country of attack must be chosen in advance
problem from ATM networking (see [17, p336]): if a MAC
• The dates of attack must be chosen in advance
is computed on each link from the acquirer to the switch
• The amount must be chosen in advance
to the issuer and back again, that necessitates two calls to
• The PIN must be entered in the card, if a chip-and-PIN
a hardware security module at each node in each direction,
transaction
so that the MAC can be verified with the inbound working
• The ATC may limit the attack window
key and recalculated with the outbound one, resulting in a
dozen extra HSM calls which in turn greatly increase not A. Defences against random-number attacks
just network latency but the size of the HSM fleet required
In the case of the first variant of the attack, where the
at each institution. So in the absence of significant numbers
unpredictable number is known ahead of time, the attacker
of network-based attacks, it may be a defensible business
does not need to know the terminal ID of the ATM, or time
decision to optimise the MACs away.
of transaction, as these are rarely (if at all) requested by
So there’s no KBA , and the actually implemented protocol card and are not included in the generation of the ARQC.
may be more like The cloned card can be used in any vulnerable ATM which
A −→ C : N, V, T shares the same country code.
C −→ A : {N, V, T }KCB The simplest fix is a cryptographically secure random
A −→ B : A, {N, V, T }KCB number generator. The UN field is only 32 bits, and so an
B −→ A : A, ok attacker who could collect approximately 216 ARQCs from
a card could get a decent probability of success with 216
which makes it even more clear that the bank B can’t rely transactions at an ATM. This is not a realistic concern as an
on anything at all. EMV card should disable itself after 216 transactions, and
carrying out 216 transactions at an ATM at 20 seconds each on subsequent transactions and also provides lia-
would not only take more than a day but should rapidly bility protection for acquirers.”
propel the machine to the top of FICO’s watch list. Mitigating acquirer liability in the event of stand-in pro-
The problem here is that fixing the random number cessing is all very well, but our concern here is the liability
generator is a matter for acquiring banks, ATM vendors, faced by the cardholder who is the victim of a pre-play
merchants and POS terminal suppliers, while the cost of attack.
fraud falls on the issuing banks and the customers. Hopefully In the event of a court having to decide whether a series
this article will reduce the likelihood of risk being dumped of disputed transactions from a single terminal was made
unfairly on customers, but what can an issuing bank do? with the cardholder’s collusion or by means of a protocol-
If an attacker requests many ARQCs from a card, the level pre-play attack, the first forensic test should therefore
issuer may notice gaps in the ATC sequence. Issuers should be to examine the TC. If a valid TC is generated by a
probably reject online transactions where the ATC is lower card following a correct ARPC that in turn was generated
than the highest ATC seen from that card, which would following a correct ARQC, then the card was present and
limit the attack window to the next genuine card use. For active at the time the ARPC was generated. This does not
offline transactions, however, this cannot be done because totally exclude the possibility of fraud, as there may have
there might be re-ordering of cryptograms. been a relay attack [21]; but pre-play attacks at least appear
to be unlikely.
B. Defences against protocol attacks Another approach for increasing the difficulty of the attack
is to force the card to commit to the value of the ATC
The best defence against protocol attacks in the short-to-
before the ATM presents the UN to the card. This is possible
medium term is almost certainly for the issuer to meticu-
without having to modify cards, because a mandatory feature
lously verify the transaction certificate (TC). The TC states
of EMV is that the GET DATA command retrieves the
whether the card verified the ARPC, and the ARPC in turn
current ATC. If the pre-play card were able to exactly predict
was computed by the card-issuing bank after it verified the
the value of the UN in a transaction, being forced to choose
ARQC. In the presence of a pre-play attack, the TC will still
an ATC would not affect the difficulty. However, it would
verify, but its IAD will indicate that the issuer authentication
prevent the card from searching a list of available ARQCs
did not complete successfully.
and finding one that matches. However, this technique is
In more detail, the EXTERNAL AUTHENTICATE call
available only to the terminal supplier (usually the acquirer)
(which happens during the transaction authorization, see
not to the issuer (who faces the risk of loss, or at least should
Figure 2) cannot be made, as the ARPC cannot be generated
face this risk once courts realise that pre-play attacks are
without the issuer’s involvement. This does not impair the
possible).
card’s ability to generate the ARQC (which happens before
One set of non-defences are the public-key authentication
EXTERNAL AUTHENTICATE), but it will allow the attack
features of EMV. The static digital signature on the card
to be detected by an issuer who examines the TC. The IAD
data can be trivially copied to the pre-play card. However, by
field in the TC is not covered by the EMV specification,
examining records of transactions we discovered that the ter-
but additional standards defined by Visa [8], commonly
minal verification results (TVR) field sent to the card during
implemented by cards, do go into more detail. A pair of bits
transaction authorization indicates that this digital signature
in the IAD indicates whether EXTERNAL AUTHENTICATE
was not verified. The decision not to check the digital signa-
has been performed and whether it succeeded. Although
ture could have been made by ATM manufacturers to save
this will not prevent every attack (because the TC is only
the time needed to verify the signature on the low-end CPUs
sent to the issuer once the terminal has completed the
in some ATMs (see Section V-B3), and the maintenance
transaction), it will normally allow detection later. In one
costs of updating the root certificates, because counterfeit
case we’ve seen a genuine transaction that was followed
cards should be detected during transaction authorization.
by six disputed large ones from the same terminal; in such Even the public-key challenge-response protocol of EMV
cases, an immediate alarm on a suspicious TC would prevent (used by cards supporting Dynamic Data Authentication –
all but the first fraudulent transaction and thus significantly DDA) would not adequately protect terminals from attack. If
reduce the criminals’ expected income. DDA were commonly used by ATMs (or the attack is fielded
At present, this does not appear to be done. Visa’s at a point-of-sale terminal) the signature response to the
‘Transaction Acceptance Device Guide’ [20, 5.12] states: INTERNAL AUTHENTICATE command can be recorded
“Devices operating in a single-message or host- and replayed just as the ARQC is. In our POS terminal tests
capture environment should ensure a TC is gen- the unpredictable number sent by the terminal to the card in
erated for approved transactions. Although not the INTERNAL AUTHENTICATE command is the same as
needed for clearing, generating a TC ensures that for the GENERATE AC command.
cards do not request unnecessary online approvals A protocol specialist might suggest that randomness must
be generated by the party that relies on it; so the terminal chip card. If the transaction can be kept offline (e.g. by
should request a nonce from the issuing bank before com- keeping it below the “floor limit”), the fact that such a card
mencing the transaction. A weaker but cheaper option might cannot produce a valid ARQC or TC will not prevent the
be for the terminal to authenticate the message conveying transaction, but as the YES-card is responsible for verifying
the nonce to the card issuing bank. This would however the PIN, it can be programmed to accept any PIN. The pre-
cost a lot of latency and processing, as noted above; even play attack is more powerful in some respects as it works
authentication is commonly optimised away in payment for online transactions, and less in others as the transaction
messages, let alone extra message round-trips. parameters must be known in advance. Crucially, the pre-
The only practical short-term alternative may be for play attack will work in ATMs while a YES-card won’t (a
arbitrators to shift the burden of proof, in the event of a typical YES-card attack involves buying cigarettes for resale,
transaction dispute, to the acquiring bank which should be which is less convenient than stealing cash directly).
called on to demonstrate that the unpredictable number was One might imagine that much more fraud could be
properly generated. The terminal equipment might support committed with a fully cloned card containing a copy of
audit in various ways, such as by using a generator which the ARQC-generation keys than with a card containing pre-
encrypted an underlying sequence that is revealed after the play data. However even a full clone will have its own ATC
fact, and locked to the transaction log to establish time limits which will diverge from that of the real card and in due
on possible pre-play tampering. However, this would not be course be detectable. So a full cloning attack might be not
entirely trivial; secure storage of audit data in the terminal that much more powerful in practice than a pre-play attack.
is a new problem and creates new opportunities for attack. The protocol pre-play attack could come in a number
of guises. In the version described here, and (we believe)
VIII. D ISCUSSION observed in the wild, a single terminal is compromised and
The potential vulnerability of EMV to a poor random used to duplicate transactions. There are clearly variants
number generator was discussed in the abstract by Mur- in which the terminals where the data are harvested are
doch [22]. Markettos and Moore [23] additionally explored quite remote from the terminals used for cash-out. If a gang
how otherwise secure true random number generators could succeeds in compromising a number of terminals (which
be manipulated to produce more deterministic output. But was done in the UK physically by three separate gangs in
this paper is the first work to show that poor random number the mid-2000s) or in compromising the communications to
generators exist in the wild, that they have been implicated a number of high-value stores (which was done to jewelry
in fraud, how they can be exploited, and that the EMV stores in Hatton Garden in the 1980s) the cards can have
specification does not test adequately for this problem. ARQCs harvested in one location and presented in another.
The random-number exploit scenario described in this Perhaps the main takeaway message is that an attacker
paper might be viewed as a variant of the relay attack, who can subvert a merchant’s premises, get access to his
which was explored in the context of EMV by Drimer and terminal equipment (even before it is purchased), or get con-
Murdoch [21]. But there, the relay attack required real- trol of his network connection, can do transactions that are
time bi-directional communication with the genuine card; the indistinguishable from card cloning to the bank that issued
genuine card had to be under the control of the attacker while the EMV card – even if full card cloning is impossible.
the attack was taking place. This makes it hard to deploy; the The EMV attack surface is bigger than one might think,
best attack we can think of is to have a false terminal such as especially once crooks learn how to manipulate the protocol.
a parking meter to attract cardholders, communicating with a
crook who waits with the connected false card near an ATM. A. Evidential issues in dispute
We do not know of this being deployed in practice (though Viability of the pre-play attack has significant legal ram-
we’ve heard rumours). Another variant of the relay attack is ifications. It can no longer be taken for granted that data in
the no-PIN attack where a man-in-the-middle device tricks a logged transaction was harvested at the time and place
the terminal into accepting a transaction after the wrong PIN claimed, which undermines the reliability of evidence in
was entered; that also works in real time. That has been both civil and criminal cases. To show that a given trans-
deployed, and crooks have been prosecuted for it; but so far action was made by a particular card, it is now necessary
the losses appear to of the order of a million Euros, and to show that the random number generator on the ATM or
from one or two incidents. POS was sound.
The random-number pre-play attack could also be seen as From the point of view of an issuing bank in dispute with
a kind of card cloning. We have already seen fake magnetic a customer, this attack greatly complicates matters. The bank
strip cards based on either the magnetic strip of the genuine cannot just rely on its own log data – it must collect data
card, or the copy of the magnetic strip data stored on the from a third party (the ATM operator) to prove that the ATM
chip of some EMV cards. Another approach is the “YES- was not infected with malware; that the random number
card” where the static data from a chip is copied to a cloned generator was not vulnerable due to either design failure or
a supply chain attack; and that the logs at the acquirer match of unpredictable numbers, or even said others had been
those kept at the terminal itself. A mere one-off certification explicitly aware of the problem for a number of years. If
for a class of EMV kernel does not come close to discharging these assertions are true, it is further evidence that banks
this burden. There may be practical matters in incentivising systematically suppress information about known vulnera-
the acquiring bank to cooperate with the issuer, especially bilities, resulting in fraud victims being denied refunds.
in international cases.
Under existing Visa guidelines, logs should be retained in IX. C ONCLUSIONS
case of dispute. Yet in recent cases we have dealt with, logs EMV is the main protocol used worldwide for card
were routinely destroyed after 90 or 180 days regardless of payments, being near universal in Europe, in the process of
whether a dispute was in progress. So the industry already adoption in Asia, and in its early stages in North America. It
cannot cope with dispute resolution based on issuer logs; and has been deployed for ten years and over a billion cards are
given that some of the disputes we’re already seeing would in issue. Yet it is only now starting to come under proper
require scrutiny of acquirer and ATM operator systems, scrutiny from academics, media and industry alike. Again
dispute resolution can only get harder. The only feasible and again, customers have complained of fraud and been told
way forward is by getting the liability right. Banks which by the banks that as EMV is secure, they must be mistaken or
destroy evidence should become automatically liable for lying when they dispute card transactions. Again and again,
the full sums in dispute, including costs. Above all, the the banks have turned out to be wrong. One vulnerability
burden of proof must lie on the banks, not the customer. after another has been discovered and exploited by crim-
The Payment Services Directive already requires this, yet inals, and it has mostly been left to independent security
dispute resolution bodies like the UK Financial Ombudsman researchers to find out what’s happening and publicise it.
Service routinely ignore the law and find for banks who In this paper, we report the shocking fact that many ATMs
destroy evidence. We discuss the issues of evidence further and point-of-sale terminals have seriously defective random
in [22], [19]. number generators. These are often just counters, and in
fact the EMV specification encourages this by requiring only
B. Industry Response that four successive values of a terminal’s “unpredictable
We disclosed these flaws to the major card schemes and to number” have to be different for it to pass testing. The result
selected banks and payment switches in early 2012, initially is that a crook with transient access to a payment card (such
with an emphasis on the random-number variant as we did as the programmer of a terminal in a Mafia-owned shop) can
not realise how powerful the protocol variant could be. All harvest authentication codes which enable a “clone” of the
parties acknowledged receipt and several contacted us to ask card to be used in ATMs and elsewhere.
further questions. The card schemes chose initially not to We now also disclose that the pre-play attack is not limited
circulate the work, but after several weeks a different contact to terminals with defective random number generators. Be-
did decide to circulate our report and our vulnerability cause of the lack of end-to-end transaction authentication, it
disclosure report received several thousand downloads. The is possible to modify a transaction made with a precomputed
vast majority of contacts refused to talk to us on-the- authentication code, en route from the terminal to the acquir-
record, but in April 2012 EMVCo published a specification ing bank, to edit the “unpredictable number” to the value that
update [24] which partially tackled the random number gen- was used in the pre-computation. This means that as well as
erator problem. The bulletin required that the unpredictable inserting a man-in-the-middle devices between the payment
number field should be “truly unpredictable even given card and the terminal, an attacker could insert one between
access to all previous numbers, and it should be infeasible the terminal and the acquirer. It also means that malware
for an attacker to control the next Unpredictable Number that in the terminal can attack the EMV protocol even if the
the terminal generates.”. EMVCo also gave notice that the protocol itself is implemented in a tamper-resistant module
testing and approval procedures for terminal random number that the malware cannot penetrate. The banks appear to have
generators would be strengthened. Yet almost two years ignored this, perhaps reasoning that it is difficult to scale
after our disclosure of the protocol flaw, nothing appears to up an attack that involves access to specific physical cards
have been done. The world’s fleet of EMV terminals remain and also the installation of malware or wiretaps on specific
vulnerable to attacks involving either terminal malware or terminals. We disagree. The Target compromise shows that
man-in-the-middle manipulation of communications. This is criminals can deploy malware on merchant terminals widely
particularly shocking given that industry insiders told us that and exploit it to earn serious money. The move to terminals
Mr Gambin’s case probably involved ATM malware. based on mobile phones may expose this flaw to industrial
Beyond the direct impact of influencing a specification scale exploitation by malware that can be spread through the
change, we received some informal responses: the extent mobile phone population much more easily than through the
and size of the problem was a surprise to some, whereas terminal fleet. The recent announcement that card payments
others reported already being suspicious of the strength via phones need no longer rely on cryptography in the SIM
card, or in a secure element or TEE, opens the door wide [5] A. Kelman, “Job v Halifax PLC (not reported) case number
to malware there too. 7BQ00307,” in Digital Evidence and Electronic Signature
This flaw challenges current thinking about authentication. Law Review, S. Mason, Ed., vol. 6, 2009.
Existing models of verification don’t easily apply to a [6] D. Moon, J. Flatley, J. Hoare, B. Green, and
R. Murphy, “Acquisitive crime and plastic card
complex multi-stakeholder environment; indeed, EMV has
fraud: Findings from the 2008/09 British crime
already been verified to be secure. We explained why such survey,” Home Office, Statistical Bulletin, April 2010,
verifications don’t work and discussed the sort of analysis http://webarchive.nationalarchives.gov.uk/20110218135832/
that is required instead. Ultimately we feel that the tools http://rds.homeoffice.gov.uk/rds/pdfs10/hosb0810.pdf.
needed to build robust systems for millions of mutually mis- [7] R. Anderson and R. Needham, “Programming Satan’s com-
trustful and occasionally hostile parties will involve game- puter,” in Springer Lecture Notes in Computer Science vol
theoretic analysis as well as protocol-theoretic modelling. In 1000, 1995, pp. 426–441.
addition, mechanisms for rolling out fixes across networks [8] Visa Integrated Circuit Card – Card Specification, Visa Inter-
with huge installed bases of cards and terminals, and strong national, October 2001, version 1.4.0.
externalities, will have to be much better than those we [9] EMVCo, LLC, “Terminal level 2, test cases,” Type Approval,
November 2011, version 4.3a.
have at present, with incentives that put the pain where it’s
deserved and technical mechanisms that offer the prospect [10] EMV 4.2, EMVCo, LLC, June 2004, http://www.emvco.com/.
of remedial action to the sufferers. [11] O. Choudary, “The smart card detective: a hand-held EMV
In the meantime, there is a structural governance failure interceptor,” University of Cambridge, Computer Laboratory,
Tech. Rep. UCAM-CL-TR-827, December 2012.
that gives rise to systemic risk. Just as the world’s bank
[12] B. Jack, “Jackpotting automated teller machines redux,” Pre-
regulators were gullible in the years up to 2008 in accepting
sentation at Black Hat USA, July 2010, http://blackhat.com/
the banking industry’s assurances about its credit risk man- html/bh-us-10/bh-us-10-archives.html#Jack.
agement, so also have regulators been credulous in accepting [13] EMV.LIB Integration Guide, CreditCall, 2009, http://www.
industry assurances about operational risk management. In level2kernel.com/emvlib documentation.html.
a multi-party world where not even the largest card-issuing [14] ATM Malware, SC Magazine, October 2013,
bank or acquirer or scheme operator has the power to fix a http://www.pcworld.com/article/2058360/atm-malware-
problem unilaterally, we cannot continue to rely on a slow may-spread-from-mexico-to-englishspeaking-world.html.
and complex negotiation process between merchants, banks [15] J. de Ruiter and E. Poll, “Formal analysis of the EMV pro-
and vendors. It is time for bank regulators to take an interest. tocol suite,” in Theory of Security and Applications (TOSCA
It is welcome that the US Federal Reserve is now paying 2011), ser. LNCS, S. Moedersheim and C. Palamidessi, Eds.,
vol. 6693. Springer, March 2011, pp. 113–129.
attention, and time for European regulators to follow suit.
[16] M. Burrows, M. Abadi, and R. Needham, “A logic of authen-
Acknowledgments tication,” ACM Transactions on Computer Systems, vol. 8, pp.
18–36, 1990.
The authors thank Dan Bernstein for the photo in Fig-
ure 5(b). Steven J. Murdoch is funded by the Royal Society. [17] R. Anderson, Security Engineering – A Guide to Building
Dependable Distributed Systems. Wiley, 2003.
Omar Choudary is a recipient of the Google Europe Fellow-
[18] R. M. Needham and M. D. Schroeder, “Using encryption
ship in mobile security and this research is supported in part
for authentication in large networks of computers,” Commun.
by that fellowship. The opinions expressed in this paper do ACM, vol. 21, pp. 993–999, Dec. 1978.
not represent the views of Google. [19] S. J. Murdoch and R. Anderson, “Security protocols and
R EFERENCES evidence: where many payment systems fail,” in Financial
Cryptography and Data Security, 2014.
[1] Financial Fraud Action UK, “Scams and computer attacks [20] Visa International, “Transaction acceptance device guide
contribute to increase in fraud, as total card spending rises,” (TADG) v 2.1,” 2013.
Press Release, March 2014.
[21] S. Drimer and S. J. Murdoch, “Keep your enemies close: Dis-
[2] S. Drimer, S. J. Murdoch, and R. Anderson, “Thinking inside tance bounding against smartcard relay attacks,” in USENIX
the box: system-level failures of tamper proofing,” in IEEE Security Symposium, August 2007.
Symposium on Security and Privacy (Oakland), May 2008, [22] S. J. Murdoch, “Reliability of chip & PIN evidence in banking
pp. 281–295. disputes,” in Digital Evidence and Electronic Signature Law
Review, vol. 6. Pario Communications, November 2009, pp.
[3] S. J. Murdoch, S. Drimer, R. Anderson, and M. Bond, “Chip 98–115, ISBN 0-9543245-9-5.
and PIN is broken,” in IEEE Symposium on Security and [23] A. T. Markettos and S. W. Moore, “Frequency injection attack
Privacy (Oakland), May 2010. on ring-oscillator-based true random number generators,” in
Workshop on Cryptographic Hardware and Embedded Sys-
[4] S. Sellami, “L’imparable escroquerie à la carte bancaire,” tems, 2009, pp. 317–331.
Le Parisien, 24 January 2012, http://www.leparisien.fr/faits-
divers/l-imparable-escroquerie-a-la-carte-bancaire-24-01- [24] EMVCo, LLC, “Specification bulletin no. 103, unpredictable
2012-1826971.php. number generation,” Bulletin, April 2012.