Practical EMV Relay Protection

Andreea-Ina Radu∗ , Tom Chothia∗ , Christopher J.P. Newton† , Ioana Boureanu† and Liqun Chen†
∗ University of Birmingham, UK † University of Surrey, UK

Abstract—Relay attackers can forward messages between a from a locked iPhone to any EMV shop reader (with non-
contactless EMV bank card and a shop reader, making it possible transit merchant codes), for any amount; we tested up to
to wirelessly pickpocket money. To protect against this, Apple Pay £1000. For Mastercard, we found that relays from locked
requires a user’s fingerprint or Face ID to authorise payments,
while Mastercard and Visa have proposed protocols to stop such phones were only possible to readers with a transit merchant
relay attacks. We investigate transport payment modes and find code. We formally model these protocols and verify the results,
that we can build on relaying to bypass the Apple Pay lock screen, using the Tamarin prover; we extend the state-of-the-art EMV
and illicitly pay from a locked iPhone to any EMV reader, for models from [2] to support mobile apps in different modes.
any amount, without user authorisation. We show that Visa’s We disclosed this attack to both Apple and Visa, and
proposed relay-countermeasure can be bypassed using rooted
smart phones. We analyse Mastercard’s relay protection, and discussed it with their security teams. Apple suggested that
show that its timing bounds could be more reliably imposed at the best solution was for Visa to implement additional fraud
the ISO 14443 protocol level, rather than at the EMV protocol detection checks, explicitly checking Issuer Application Data
level. With these insights, we propose a new relay-resistance (IAD) and the Merchant Category Code (MCC). Meanwhile,
protocol (L1RP) for EMV. We use the Tamarin prover to model Visa observed that the issue only applied to Apple (i.e., not
mobile-phone payments with and without user authentication,
and in different payment modes. We formally verify solutions to Samsung Pay), so suggested that a fix should be made to
our attack suggested by Apple and Visa, and used by Samsung, Apple Pay. We verify Apple’s and Visa’s possible solutions
and we verify that our proposed protocol provides protection in Tamarin and show that either would limit the impact of
from relay attacks. relaying. At the time of writing neither side has implemented
a fix, so the Apple Pay Visa vulnerability remains live.
I. I NTRODUCTION We found that Samsung Pay did not use “magic bytes”,
Contactless Europay, Mastercard, and Visa (EMV) pay- instead it was always possible to perform an EMV transac-
ments are a fast and easy way to make payments and are tion with a locked Samsung phone. However, we found that
increasingly becoming a standard way to pay. However, if locked Samsung-Pay would only allow a zero-value payment,
payments can be made with no user input, this increases requiring the transport providers (currently only TfL) to have
the attack surface for adversaries and especially for relay an arrangement with their banks to charge for tickets based
attackers, who can ferry messages between cards and readers on these zero value transactions. This makes it impossible to
without the owner’s knowledge, enabling fraudulent payments. relay Samsung Pay to shop readers to buy goods, but it is still
Payments via smart-phone apps generally have to be confirmed possible to relay Samsung Pay to other transport readers.
by a user via a fingerprint, PIN code, or Face ID. This makes It seems unlikely that transport modes will be removed from
relay attacks less of a threat. phones so, as relaying attacks are still possible, there is a need
Apple Pay uses the EMV standard, however, for usability, for general EMV relay-countermeasures. Visa have proposed a
iOS 12.3 (May 2019) introduced the “Express Transit/Travel” relay-countermeasure [3]; their protocol binds the ISO 14443
feature that allows Apple Pay to be used at a transport-ticketing Level 1 data to the Level 3 protocol on the presumption
barrier station without unlocking the phone. In October 2019, that (relay) attackers cannot easily tamper with Level 1 data.
Samsung introduced the same feature. We refer to this feature This protocol has yet to be fully specified and implemented.
as “Transport mode”. We found that a non-standard sequence Mastercard specifications include a Relay Resistance Protocol
of bytes is broadcast by Transport for London (TfL) ticket-gate (RRP) [1]. This has been in the specifications since 2016, but
readers, and that these “magic bytes” bypass the Apple Pay as far as we are aware it is not yet implemented in commercial
lock screen. Apple Pay then checks that its other requirements readers, or on customers’ cards. RRP operates at the EMV
are met (different for Visa and Mastercard) and if so it allows application layer. In this protocol, the reader times a nonce
a transaction to be performed with no user interaction. exchange with the card. If the time taken to communicate
For Apple Pay Visa we alter, replay and relay both ISO with the card is within the bounds provided by the card, it is
14443 Level 11 messages, as well as EMV protocol Level 3 likely that the card is close to the reader and no relay attack
messages; with this, we are able to make a fraudulent payment is taking place. If the time taken is outside these bounds then
the nonce exchange is repeated. If three nonce exchanges fail,
1 In EMV terminology [1], Level 1 is the ISO 14443 protocol, Level 2 is then payment is rejected as a possible relay.
the exchange of bytes encoded as Application Protocol Data Units (APDUs), We show that the previously proposed relay-protection pro-
and Level 3 corresponds to the EMV application protocol. We cover the ISO
14443 protocol in Appendix A and the EMV protocol in Section II-A. We do tocol from Visa can be defeated with standard hardware: the
not manipulate the APDUs and so they are not detailed further. Level 1 data they bind into Level 3 can be forged. The Level 1
data used comes only from the card, without involvement in place, and we are the first to show that neither Visa, nor
from, or timing by, the reader. This leaves the protocol open Mastercard’s current relay-protection solutions are reliable.
to Man-in-the-Middle (MitM) attacks. When contacted, Visa Our work on mobile payments and transit modes adds im-
stated that their proposal provides protection against off-the- portant new insights to the field. For instance, Basin et. al. [2]
shelf smart phone relays. However, we show that a replay/relay present an attack that bypasses the contactless-transaction limit
is possible with standard phones, if one of them is rooted. for Visa plastic cards by making it look like the card has
To test the Mastercard RRP, we measured the timings of used user authentication (CDCVM) when the card is not even
responses coming from a test RRP-capable card, provided by capable of it, and they suggest changes to Visa’s protocol to fix
ICC Solutions, as well as a range of other payment cards. this. However, we show that the CDCVM status of a capable
We find that the distance of the card from the reader has a device is recorded in the IAD field in Visa’s protocol, and this
noticeable effect on the response times for the card’s Level 3 field may be authenticated by the bank, so all Visa need to
messages, including the timed nonce-exchange on the RRP do to stop this attack is to check this existing field in their
card. The Level 1 messages, which require less processing, protocol. So, we delay discussion of related work until the
show much shorter and more consistent response times. As end of the paper, after we have presented our new findings.
users will commonly place payment cards at a range of The contributions of this paper are:
distances and angles from the reader, it may be difficult for 1) Explaining how Transit/Transport mode and the Issuer
the reader to tell the difference between a card at the optimum Application Data work and are used in EMV.
position being relayed, and a legitimate card in the worst 2) Showing how to bypass the Apple Pay lock screen take
position. In the case of our test RRP-capable card, we show any amount of money from a Visa on an iPhone.
that this difference is enough to make a relay possible. While 3) Showing that Visa’s Level 1-relay-protected protocol is
other card implementations may have regular enough timing insecure against an attacker with rooted phones
to make a relay more difficult, relays are also becoming faster, 4) Showing that EMV distance bounding can be done more
even with cheap off-the-shelf hardware [4]. Requiring the user reliability at Level 1 than Level 3.
to place their card in a fixed position would mitigate this 5) Proposing a Level 1 distance bounding protocol for EMV.
problem, but it would not be a usable solution.
II. BACKGROUND
We propose the L1RP protocol that combines elements from
both Visa’s and Mastercard’s relay protections. We leverage A. Overview of EMV
the timed nonce-exchange as proposed by Mastercard, yet we The EMV standard includes many different protocols, with
move it to the ISO 14443 Level 1 part of the EMV protocol, many variations. We present the versions of Mastercard’s Pay-
which –as we show– gives stable round trip time (RTT) Pass and Visa’s PayWave that we observed in mobile phone
measurements. From Visa, we take the idea of tying together transaction traces. All of the annotated traces we collected can
data from Level 1 with the EMV application authentication. be found in [9]. We summarise the most important acronyms
By having a nonce-exchange and not just a one-directional used by EMV in Appendix D.
message as in Visa’s case, we solve the replay/relay issue with 1) Mastercard’s Protocol: The version of PayPass we
Visa’s proposal. Our L1RP protocol satisfies the requirements observed is shown in Fig 1. It runs after the Level 1 ISO
of the ISO 14443 specifications and can be made backwards 14443-3 anti-collision protocol; the relevant parts of the ISO
compatible, allowing both cards and readers to complete a 14443 protocol are described in Appendix A.
transaction with a legacy reader or card (i.e., one without our The card and the bank share a symmetric key KM , and
relay protection). the card has a certificate chain for a public key, which the
We formally verify our L1RP protocol, and prove it se- reader can verify. The first two messages exchanged select the
cure using Tamarin. For relay-security, we rely on a pre- payment application (i.e., Mastercard). Next, the reader sends a
viously published method in [5]. Concretely, we show that Get Processing Options (GPO) message with terminal-specific
no downgrade attacks (to the EMV protocol without relay information, and the payment device answers with a list of the
protection) are possible, and that our design provides the relay records available on the card (the Application File Locator
protection, as described in the threat model section below. We (AFL)) and a list of the card’s capabilities (the Application
also implement our protocol’s Level 1 nonce-exchange using Interchange Profile (AIP)). The AIP indicates whether the
Proxmarks [6], providing some evidence that our protocol is device is capable of user authentication, but does not indicate
practical. whether user authentication has actually been used.
Novelty & Positioning: There have been a range of The reader will then request all of the records listed in
attacks against contactless EMV (e.g., [7], [2], [8]). Most of the AFL, which includes “Track 2” (the user’s account in-
these attacks make use of a relay to alter messages going formation) and the Card Risk Management Data Object List 1
between a card and a reader, i.e., the relay aspect of our (CDOL1), which lists all of the information the card needs to
work is not new. However, we note that (1) None, of these complete the transaction. The information requested may vary
past attacks work against EMV payments from mobile devices between cards; however, for mobile devices using Mastercard
that require strong user-authentication, (2) None of these past this always includes the amount of the transaction, a unique
attacks would work if good relay-protection protocols were number/nonce from the reader (Unpredictable Number (UN))
and the MCC, which identifies the business associated with the
Reader Card
reader (e.g., 5732:electronics stores or 4111:local transport).
The proof of payment that the reader requires from the card SELECT 2PAY.SYS.DDF01

is a MAC on the transaction data, referred to as an Application FCI(AID-MC)

Cryptogram (AC). The reader now requests this AC with a SELECT AID-MC
GEN AC command, which sends all of the data the card FCI(API),PDOL
requested in the CDOL. GPO(PDOL-DATA)
The card will then generate a session key, KS , based on AIP, AFL
the key it shares with the bank, KM , and its Application READ RECORDs
Transaction Counter (ATC), which represents the total number CDOLs, Track2, CVM List, IAC, Certs
of times the card has been used. The card generates the AC as
a MAC of the CDOL1 data, ATC, and AIP, keyed with KS . UN ∈R {0, 1}32 , Check CVM
The reader cannot check this MAC as the key is known only list, CDOL1-DATA=(amount,
amount other, country code, TVR,
to the bank and card, so the card signs data for the reader to currency, date, type, UN, terminal
type, data auth code, ICC no.,
check, the Signed Dynamic Application Data (SDAD), which CVM, TRM, MCC, MNL)
includes the CDOL1 data, the AC, the AIP (if present in the
GEN AC (CDOL1-DATA)
Static Data Authentication Tag List), any records marked to
be included in data authentication and the UN.
KS = EncKM (ATC)
The SDAD and the AC are sent by the card to the reader AC = MACKs (CDOL1-DATA,AIP,
along with the ATC, needed by the bank to calculate the ATC,AID,IAD)
SDAD = Sign(CID,AC,CDOL1-
MAC key, a CID (which indicates the type of the AC) and DATA,AIP,UN)
the IAD (which we discuss below). The reader checks the CID, ATC, SDAD(AC,AIP), IAD
SDAD signature and the data in the SDAD and, if this is
correct, it sends the AC, the AIP, CDOL1 data, ATC and IAD Check certs, use these to check sig
on SDAD. CDCVM in IAD for high
to the bank/payment network, which will verify the AC. If it amounts
is correct the bank will authorise the payment. The MCC is
also sent securely to the bank, by the terminal, as part of this
“authorisation request message”. Fig. 1. MasterCard’s PayPass from EMV standard & observed traces
We note that there are many variations of this protocol,
e.g., the specification includes a card nonce, Nc , which is Verification supported by the card, as well as the conditions
included in the SDAD, however we did not see this in any of in which these rules apply. For plastic cards, this is generally
our runs. The protocol presented here uses Combined DDA done by requesting that the card’s Personal Identification
with application cyptogram (CDA) mode, as specified in the Number (PIN) is input into the terminal (this PIN is sent
AIP; the specification allows for an “online” mode without a encrypted to the bank for verification). On mobile devices,
SDAD, although we have not seen this for any of our tested the CV can be done on the device, called Consumer Device
cards and readers, which are online and still use CDA. Cardholder Verification Method (CDCVM), i.e., the user’s
Below, we present the Visa protocol, which is similar to fingerprint is scanned by the mobile app. Importantly, this
Mastercard’s protocol, but before doing so we include some allows the reader to accept contactless payments above the
extra details common to both. normal contactless limit. We note that the AIP indicates if
IAD: This hex-string follows the defined format set out CDCVM may be possible, not that it has been used.
in the EMV standard, but the details are proprietary; see Visa “Tap-and-PIN”: The way of requesting the PIN can
Contactless Payment Specification and Visa Mobile Contact- differ from country to country (i.e., residing country of the ter-
less Payment Specification [10]. The IAD, in combination with minal, issuing country of the card and combinations thereof).
the transaction data, is used by the bank/payment networks For instance, in the UK and Singapore, when using a UK-
for anti-fraud checks. We discovered details of the IAD via issued card, an “over-the-limit” transaction asks for the card to
investigation of cards and our disclosure processes with Visa, be inserted into the terminal and for the PIN to be used. Yet, in
Apple and Mastercard, we give details in Section IV-C. Spain, France, Switzerland, Norway, and others, the card does
Cardholder Verification: EMV transactions with NFC not need to be inserted in the terminal, but the user is asked
cards remain fully contactless as long as certain spending to type in the PIN (or confirm via a button). We refer to the
limits are not reached: a limit per transaction (e.g., £45 in the latter type of PIN-request as Tap & PIN mode. Investigating
UK) and/or cumulative daily limits (e.g., C150 in the EU); if Tap & PIN cards from Romania and non-Tap & PIN cards
either is reached, then normally the transaction would require from the UK, we found that non-Tap & PIN cards would stop
proof of “user presence”, i.e., a Cardholder Verification (CV) the transaction for any amount over the limit, whereas Tap &
mechanism is enforced. PIN cards would continue, requesting the reader perform CV.
The Cardholder Verification Method (CVM) list informs To the best of our knowledge, we are the first to point out
the terminal of a set of rules for performing Cardholder that there are two types of EMV cards, although some past
 which determine what type of CV can/should be performed at
Reader Card
the point of sale. The allowed options are decided by the bank
SELECT 2PAY.SYS.DDF01 issuing the card and are programmed at the time of issuance.
FCI(AID-VISA) The “CDCVM performed” bit (byte 2 bit 5) is of interest – it
SELECT VISA AID tells the terminal that on-device CV has been performed.
PDOL, FCI(API) Unlike for Mastercard, we saw both online and offline mode
in the Visa traces. If the “offline data authentication for online
UN ∈R {0, 1}32 , PDOL-DATA=(TTQ, transactions” flag was set by the reader then the card would
amount, amount other, country, TVR, cur-
rency, date, type, UN) report extra records in the AFL field and would send the
GPO(PDOL-DATA) SDAD; the fields in square brackets in Fig 2. For Visa, the
mobile devices we tested used tokenization [14] to obscure the
KS = EncKM (ATC) account details (done by the read record in angle brackets in
AC = MACKs (PDOL-DATA,AIP,ATC,IAD)
SDAD = Sign(ATC, UN, amount, currency,
Fig 2), whereas plastic cards do not do this.
NC, CTQ, AIP)
Other = PAN Seq no., AC info,form factor
AIP, [AFL] IAD, AC, ATC,
CTQ, Track2, [SDAD], Other
B. Over the Limit Attacks Against Tap & PIN cards
h READ RECORD i

h ICC,TRID,PAR i
Two attacks have demonstrated how user authentication can
[ READ RECORDs ]
be bypassed for high-value transactions with Tap & PIN cards.
[ Certs, PAN, CARD(NC ) ] Galloway and Yunusov [7] show that, for high-value Visa
transactions, a MitM attacker clearing the TTQ bit, which
requests user authentication, leads to a high-value transaction
being accepted without a request for the PIN. This shows that
Fig. 2. Visa’s PayWave protocol. Brackets indicate optional messages. the TTQ used by the card is not being authenticated by the
reader or EMV back-end.
authors have presented attacks that only work against Tap & Basin et. al. [2] present an attack against contactless Visa
PIN cards [2], [7] and others have presented attacks that only plastic cards, in which a MitM attacker flips CTQ bits, making
work against non-Tap & PIN cards [11]. the terminal believe that CDCVM was performed on the device
2) Visa’s Protocol: The version of Visa’s protocol, as per when in fact it wasn’t. This too leads to a high-value Visa
the standard and validated by our traces, is shown in Fig 2. transaction being accepted without the reader asking for a PIN.
Unlike Mastercard, the list of data needed for the transaction The authors of [2] state that their attack is “possible because
(e.g. amount, UN, etc.) is returned in answer to the second no cryptographic protection of the CTQ is offered”. While the
SELECT message. The function of the GEN AC and the GPO lack of CTQ authentication is true, this is not the root cause.
messages in the Mastercard protocol is merged into the GPO We show in sub-section IV-C that the IAD generated by the
message in Visa’s protocol. Checks on the SDAD and AC plastic card in their attack would have a Visa “plastic-IAD”
remain the same. While the MCC is not sent to the card, it format [10] which, if checked by the payment network, would
is sent securely from the reader to the bank and payment- reveal that the device is not capable of CDCVM authentication,
networks (i.e., Visa), for anti-fraud checks and fees [12]. and so the transaction should be rejected. Therefore, the attack
The type of Cardholder Verification supported or performed of Basin et. al. [2] is due to missing checks at the EMV back-
is signalled through a number of different EMV data elements end rather than a flaw in Visa’s protocol.
throughout the transaction, in particular a mobile Visa trans- We observed some discrepancies regarding how the TTQ-
action uses the Terminal Transaction Qualifiers (TTQ), Card AC relationship is presented in the above mentioned attacks.
Transaction Qualifiers (CTQ) and AIP. Galloway [7] claims that for Visa cards, the AC does not
The Terminal Transaction Qualifiers (TTQ) inform the card contain the TTQ, based on information from the Visa Con-
of the online and CVM options that the terminal supports; tactless Payment Specification [15], which is a proprietary
of relevance are the bits flagging support of “EMV Mode” specification. Basin et. al. [2] claim that the TTQ is in the
(byte 1 bit 6), “offline data authentication for online trans- AC, based on EMV Book 2 [16], and explain that this is
actions” (byte 1 bit 1) and “CVM required” (byte 2 bit 7). why their formal model does not identify the Galloway attack.
Offline data authentication for online transactions is a feature EMV Book 2 states that it is recommended that the whole
used in special-purpose readers, such as transit system entry Processing Options Data Object List (PDOL) be included in
gates [13], where EMV readers may have intermittent con- the AC (which would include the TTQ in this case), but the
nectivity and online processing of a transaction cannot always minimum set of data elements they specify does not include
take place. In such cases, offline verification is performed and the TTQ. Therefore, whether the TTQ is included in the AC
the payment is processed once the terminal is back online. or not (and if the attack of Galloway [7] is due to missing
The Card Transaction Qualifiers (CTQ) are a set of options back-end checks or a flaw in the protocol) is unclear.
 Reader Card the card and denoted in Fig. 3 as NC , (2) three timing
...
estimates from the card, denoted in Fig. 3 as timing info, i.e.,
...
EXCHANGE RELAY RESISTANCE DATA (U N )
the minimum and maximum expected time for the card to
timed NC , Timing information process the ERRD command and an estimate of the round trip
READ RECORDs time (RTT). All these values are signed in the Signed Static
... Application Data (SSAD), which the reader should check.
SDAD, AC, ATC
If the message RTT is smaller than the maximum listed
in the timing data, then the ERRD phase finishes and the
Fig. 3. Mastercard’s PayPass-RRP Protocol – PayPass with ERRD protocol continues. If the RTT is larger than the maximum
time three times in a row, then the reader stops the transaction
C. Visa Relay Protection Protocol
as a suspected relay attack. If a terminal has done a PayPass-
Visa proposes a relay-counteraction measure [3], [17], RRP check and it passed, then the TVR should be set to
which we call the VISA-L1 protocol. This protocol is based 0000000002. We will use “RRP” for the whole payment
on two ideas. First, it requires the card to use a random 4-byte protocol by Mastercard (PayPass-RRP).
Unique Identifier (UID) in each run of the protocol (random
UIDs are common in RFID devices). This means that the UID III. T HREAT M ODEL
now functions as a nonce, and is referred to by Visa as the
L1SessionParameter. This is sent by a card to the reader Our threat model is that of an active Man-in-the-Middle
as part of the Level 1 anti-collision process (see Appendix A). (MitM) adversary, who can also relay. The attacker operates in
The L1SessionParameter is then tied into the Level 3 an environment where: (1) the banks/issuers/payment networks
of Visa’s PayWave protocol. While Visa’s patent and current are honest; (2) the EMV terminals are honest; (3) cards can
documents do not specify how the Level 1-to-Level 3 binding be compromised, except for the card that the attacker is trying
must be done, we understand from conversations with Visa to relay in the current attack (i.e., we do not consider attacks
that the “EMVCo NextGen” specification will specify that the such as distance fraud or terrorist fraud).
L1SessionParameter be added to the SDAD, alongside Formal-Verification Adversary: Our attacker is modelled
the normal Level 3 EMV data that the SDAD contains. If the as a Dolev-Yao attacker [18] allowing for corrupt cards and
UID received at Level 1 and Level 3 do not match then the an unbounded number of sessions. For proximity-checking, we
transaction is rejected as a possible relay. follow the state of the art formalism of Mauw et. al. [5], where
Visa’s Relay-Security: In the specification documents [3], distance and timing are safely abstracted into event-ordering
[17], the security argument relies on the difficulty of setting the on traces, and we are only interested in MitM-security (i.e.,
UID to a particular value, especially with off-the-shelf devices not distance fraud or terrorist fraud).
such as mobile phones. Thus, a proxy card used in relaying Practical Adversary: Our practical attackers use, for
to impersonate the real card would fail to produce the right relaying or other MitM manipulations, Commercial Off The
messages to the legitimate reader. Shelf (COTS) equipment, i.e., commercial, relatively non-
Through our conversations with Visa Research, there is expensive, easy-to-use hardware or software such as mobile
another implicit security argument, common in the RFID field: phones (rooted or not). More specifically, our practical attacks
relaying at Level 1 is harder than at Level 3, because ISO do not rely on extensively modifying firmware on hardware or
14443-4 framing is more restrictive than at the EMV level. building new hardware (for relaying or other MitM attacks),
So, relay protections may be more effective at Level 1 than and our practical adversaries stop at application-level devel-
Level 3. However, we note that if the attacker can set the UID opment/manipulation on COTS devices. This is the same type
of the proxy to equal the UID of the card, then Visa’s defences of attacker that Mastercard and Visa aim to stop with their
will no longer work , because there is no dynamic/fresh reply proposals. No current proposal for relay protection for con-
by the reader based on said UID and there is no distance tactless EMV aims to stop specialist, expert-built relay/MitM
bounding used in the VISA-L1 protocol. equipment (e.g., [19]).
There are fast and effective, purposely built hardware-based
D. Mastercard Relay Protection Protocol relays in other domains such as remote car-unlocking [19], as
Mastercard’s PayPass-RRP (shown in Fig. 3 and described well as solutions [20] designed specifically for the physical-
in EMV Book-C2 [1], Sections 3.10, 5.3 and 6.6) is a direct layer (e.g., bespoke modulation schemes) to combat such
extension of the PayPass protocol, in which a timed nonce- efficient, hardware-based attacks. Our threat model does not
exchange at Level 3 is used in order to detect relay attacks. include hardware-based EMV relays that operate at Level-
PayPass cards indicate they support the protocol with a AIP 1 (or the physical-layer) and such relays might be able to
of 1981; a PayPass-RRP reader then sends an Exchange compromise our proposed solution. In fact, in Section VI, we
Relay Resistance Data (ERRD) command that contains the give certain timing measurements for an implementation of our
“Terminal Relay Resistance Entropy”. This is the same reader- L1RP protocol, mention the bottlenecks observed, and leave as
generated UN nonce sent in PayPass inside the GEN AC. an open question the possibility of successful hardware-based
The ERRD response contains (1) the nonce returned by relays against current contactless EMV technologies.
 IV. M OBILE -PAYMENTS VIA T RANSPORT M ODE By setting these flags in a relay we found we could relay
This section presents our results from experimenting with transactions between a locked iPhone and any of our shop
Apple Pay Express Transit (known as Express Travel in readers, therefore, allowing the attacker to wirelessly pick
Europe) and Samsung Pay “Transport card”. We refer to these pocket money from the iPhone’s owner. The attack may also
two systems as “Transport mode”. The transport mode on these be used to extract money from a stolen, locked iPhone. We
phones is a convenience feature, which allows a user to pay on note that it would be possible for Visa to try to authenticate
certain transport networks without prior authentication to the the TTQ and so limit the attack to just shop readers that have
device (fingerprint, face ID or passcode), by simply tapping the Online/Offline mode flag set, however, as shown by [7],
the phone on the EMV reader of the transport network. Visa do not authenticate this field.
Apple Pay’s transport mode is available in London (TfL), Attack Details: This vulnerability has a Severity Score
New York City, Portland, Chicago, Los Angeles, Washington, of 7.1 and a High Severity rating (based on the Common
Beijing, Shanghai, Hong Kong and Japan [21]. Samsung Vulnerability Scoring System v3.1 [24], [25]).
Pay’s transport mode is only advertised to work in London For carrying out the attack, we used a Proxmark RDV4, with
(TfL) [22]. Google Pay allows, by design, for certain small- small modifications to the device firmware (details to follow)
value transactions without user authentication2 and does not which acted as a reader emulator, the EMV readers mentioned
have a dedicated transport mode. above and an NFC enabled Android device which acted as a
card emulator (Nokia 6 TA-1033, running Android 9 Pie, in
A. Setup and Data Collection our case). A device to run the relay server was also needed;
Hardware: As target devices we had two Apple products for our experiments we used the same laptop as above.
(an iPhone 7 and an iPhone 12, running iOS 14.4.2 and two To carry out the attack a Proxmark acts as a terminal
Samsung products (a Samsung Galaxy S9 Edge and S10 emulator, and it is connected to a laptop via USB. The Nokia
running Android 11. We tested our findings on a number of phone acts as a card emulator, using the CardEmulator app
commercially available EMV terminals: iZettle v1, SumUp, from [26], and communicates with the laptop via some net-
and SquareUp readers. work (cellular or WiFi). We modified the Proxmark firmware
Preparation Stage: We collected transport mode trans- such that, when emulating an ISO 14443 type A reader, it
action traces between a locked phone and TfL ticket gate would first send the Magic Bytes, wait 8ms for the iPhone to
readers at Clapham South, Clapham Common, Balham and process the message, then send the WUPA command. The rest
Epson London Underground stations. For this we used a Prox- of the ISO 14443 protocol is run according to the standard,
mark RDV4 fitted with the high frequency antenna, running after which the EMV protocol can begin. This step only
standard firmware3 . The Proxmark was chosen both due to involves the iPhone and the Proxmark, and no messages are
its versatility and excellent ISO 14443-A support, as well as relayed in this part of the attack.
its small form factor, which meant we could carry out the The relay server runs a Python script which handles
sniffing experiments without drawing too much attention. The the communication with the Proxmark, via the pm3 client,
Proxmark was connected via USB to a Linux laptop in order and the communication with the CardEmulator via a
to issue the sniffing commands. socket. It relays the messages between the Proxmark and the
Analysing the sniffed traces, we noticed that an extra, static CardEmulator, and can modify them in-flight, as needed.
15-byte message is sent before the ISO 14443-3 Wake-UP Once the iPhone is in the ACTIVE state (as described in
command, Type A (WUPA) [23], which we refer to as the ISO 14443-3), we can start the interaction between the card
Magic Bytes. emulator and reader. They will complete the standard ISO
B. Visa Apple Pay Express Transit Replay & Relay Attack 14443 activation protocol.
The EMV protocol then starts, and the messages are relayed
We found that by replaying the Magic Bytes to an iPhone, between the EMV reader and the iPhone. A diagram of the
Apple Pay would unlock and allow us to start a transaction relay can be seen in Fig. 4. At the point in which the reader
for both Mastercard and Visa, even if no authentication (PIN, provides the transaction information, as part of the GPO
FaceID or TouchID) has taken place. However neither would message, in order to continue with the transaction, we set the
initially let us then complete an EMV transaction. Offline Data Authentication (ODA) for Online Authorizations
By examining the Visa traces we found that in order to
supported bit (byte 1 bit 1), as well as the EMV mode
continue with the transaction in transit mode, we have to make
supported bit (byte 1 bit 6) in the TTQ – we denote the
sure the TTQ, contained in the GPO, has the Offline Data
modified message as GPO’ in our diagram. The EMV protocol
Authentication (ODA) for Online Authorizations supported bit
continues as normal. We would like to highlight that as part of
set (byte 1 bit 1) as well as the EMV mode supported bit set
the answer to the last READ RECORD command the phone
(byte 1 bit 6). The former flag indicates to the device that the
sends, among other details, the Card Authentication Related
reader may be offline, but that the device should use online
Data (CARD), which contains the card nonce (Nc ) and a copy
mode anyway.
of the CTQ. Once the last reply is received by the reader, the
2 https://support.google.com/pay/answer/7644132 transaction is successfully completed - the iPhone shows a tick
3 https://github.com/RfidResearchGroup/proxmark3 and displays ‘Done’ in the user interface (UI), and issues its
 iPhone Proxmark
Relay Card
Reader payment limit. We were able to escalate this attack to work for
Server Emulator
any amount. We could bypass the contactless limit by setting
Magic Bytes the CDCVM performed bit in the CTQ (bit 8 in byte 2), as well
14443-A activation protocol 14443-A activation protocol
as setting the same bit in the CTQ copy of the CARD field.
We successfully tested this with amounts up to £1000. The
SELECT 2PAY.SYS.DDF01 code for the proof of concept is open sourced and available
FCI(AID-VISA)
in [9] along with a video of the attack being performed.
SELECT VISA AID
PDOL,FCI(API)
Disclaimer: For ethical reasons, we used our own per-
GPO(PDOL-DATA) sonal cards while carrying out this research and we do not
publish the value of the Magic Bytes.
modify TTQ (GPO’)
GPO’(PDOL-DATA)
Mastercard: We have also investigated whether this at-
EMV

AIP,AFL,AC,IAD,ATC,SDAD,CTQ tack works when using a Mastercard with Apple Pay Express
Transit. In order to complete a transport transaction, we found
READ RECORD 1 READ RECORD 1
that the Merchant Category Code (MCC), which the EMV
ICC,TRID,PAR ICC,TRID,PAR
READ RECORD 2 READ RECORD 2
reader sends, needs to map to transportation services [27];
Issuer PK Cert Issuer PK Cert we confirmed it works with MCC 4111 (local commuter
READ RECORD 3 READ RECORD 3 transport) or 4131 (bus lines). However, the MCC is authenti-
ICC PK Cert,PAN,CARD ICC PK Cert,PAN,CARD cated in the Mastercard protocol (it is included in the SDAD),
Records can be cached, therefore this and therefore this modification is detected and the transaction
exchange would not be needed rejected. This check on the MCC is the reason why we cannot
relay Mastercard transactions from a locked iPhone to a shop
Fig. 4. Communications diagram for the Apple Pay Express Transit attack reader, although relays to other transit readers are possible.
trademark sound, and the reader shows the payment has been
received. C. Investigation of Mode-Change in Samsung Pay
If the attacker can interact or eavesdrop the iPhone before We investigated Samsung Pay Transport Card, the equiva-
the attack then the READ RECORD commands can also be lent of Apple Pay Express Transit, on a Samsung Galaxy S9
cached, in which case the Proxmark no longer needs to relay Edge and Galaxy S10, running Android 11, with all updates
the requests for these to the iPhone. The replies can be cached applied. We found that the transaction logic of the Samsung
on the relay server or, ideally, on the device acting as the card phone differs from the iPhone; when it comes to choosing
emulator. If the replies are cached the UI does not show the whether a transaction should be executed via its transport
transaction as completed; instead, it displays ‘Try Again’ and mode or through the normal mode. The Samsung phone did
a red exclamation mark. There is also no audio cue. However, not require the presence of the Magic Bytes to respond to
the reader shows the payment has been successful, and the EMV commands. Samsung’s solution relies on one of the
transaction can be confirmed by unlocking the iPhone and suggested mitigations we had for Apple: small/zero value
checking the Apple Pay transaction history. payments. If the transaction value is 0, the phone considers
The reader is running in online mode and is not expecting this to be a transaction with the public transport infrastructure
the SDAD from the iPhone, which is only sent because we and executes it through the transport card (no authentication
flipped a bit in the TTQ, i.e., the iPhone is running in DDA required). A larger amount is considered to be a normal
mode and the reader is running in EMV mode. We could transaction, and requires authentication. If the fingerprint (or
remove the SDAD from the DDA message to make it look like Samsung Pay PIN) is not provided beforehand, the phone
a EMV message, however we found that, if sent, the reader replies with a message to signal that the conditions of use
will just ignore the SDAD and does not check it. have not been satisfied and stops the transaction.
Relay Success Rate: The full relay has a success rate We could activate the Samsung Transport card by replaying
of approx 40% (8 out of 20 trials). This success rate is a TfL trace to it. However, when trying to relay a non-
achieved by a slight modification in the attack flow, whereby zero value transaction between a real EMV reader and the
when the first READ RECORD command is issued, we phone, the transaction was always cancelled by the phone,
continue the phone-side only messages exchange with the two and a message that authentication to the device is required
subsequent read commands. We then relay them to the reader, was displayed. Changing the amount of the transaction while
as it requests them (as opposed to forwarding each READ relaying (in the same way we changed the TTQ when relaying
RECORD command when received from the reader). We point the iPhone) resulted in the transaction reaching the end of the
out that the success rate is not due to any Apple protection protocol on the phone, but being declined by the EMV reader.
mechanism, but due to the timing of relaying the messages, As it is clear that the transaction is cancelled by the phone
and for the cached READ RECORD variant, the success rate if any non-zero value is present in the authorised amount field
is 100%. of the GPO message (which is used for purchases), we also
Over the CVM Limit Payments Escalation: The above experimented whether the same occurs for the other amount
described attack works for transactions under the contactless field, which is used for cashback. Here we found that we could
complete a transaction with a locked Samsung phone (and E. Responsible Disclosure
therefore had an AC generated) with some value in the other The details of this vulnerability have been discussed with
amount field, as long as the authorised amount value was zero. Apple and Visa. In a meeting with the Apple Pay security
Plans have been announced to allow cashback without team, they stated that they believed that this was a serious
a purchase on contactless cards4 transactions from locked security issue, but they believe Visa would be responsible
Samsung phones. Unfortunately, we were unable to acquire for allowing this IAD-unchecked transaction to go through.
readers that support the cashback functionality, in order to Explicitly, they stated that Visa should identify iPhone transac-
test this. We hope to be able to try this attack in future. tions, check the CDCVM status in the IAD, and that iPhone
transactions without CDCVM should only be allowed when
D. Investigating the IAD
the MCC code indicated transit payment.
To find out how CDCVM was authenticated we carried out We suggested restricting transactions to low or zero value,
a byte-by-byte comparison of mobile device transactions with when Apple Pay is unlocked with the Magic Bytes. Zero value
and without CDCVM (transport mode). Looking at Mastercard is in line with the operations/transactions needed by TfL,
we found that the only differences were in the UN, AC, which calculates the correct amount to charge travellers at the
SDAD, and the IAD. The AIP was the same whether CDCVM end of the day based on all their trips, but Apple stated that
was used or not, always indicating that the device supports they support transit systems that require non-zero payments,
CDCVM, i.e., the AIP does not indicate that device has so they do not want to put any bound on the payment value in
performed user authentication. We would expect the UN, AC transport mode. Apple did not pay a bug bounty, even though
and SDAD to be different for each run because they are they advertise $100,000 for bypassing a lock screen, and our
designed to be fresh values, therefore this suggests that the attack bypasses the Apple Pay lock screen.
IAD indicates if CDCVM was successfully performed on the We have also discussed this attack with Visa, who pointed
device. out that this attack only affected Apple Pay, and suggested
We tried a MitM attack that inserted the IAD from a Apple were best placed to fix the issues. Visa also stated
user authenticated transaction into a transaction with no user that back-end anti-fraud checks weregenerally applied, when
authentication and the transaction was rejected, indicating that needed. So, if this attack was to raise fraud-alerts, they claim,
the IAD is authenticated. Mastercard later confirmed to us that it would be eventually stopped. That said, we performed our
the IAD is included in the AC and this is checked. attack multiple times, on large values, from the same card,
For Visa plastic cards, we found that there are multiple and we were never blocked and flagged for fraud. Until either
IAD formats used. We saw in our transactions IADs with Apple or Visa implement a fix, we recommend that iPhone
“Format 0/1/3”, for example: 065C0A03A00000. The general owners disable transit mode for Visa cards.
description of an IAD is defined in EMV Book 3 [28]. Bytes
5-7 of the IAD are the Card Verification Results (CVR), which F. Comparison with Existing Attacks Over the Limit Attacks
indicate whether a second GEN AC was issued, and the type The attack presented by Galloway [7] is used to perform
of AC returned, among other things. over the CVM limit transactions without Cardholder Verifica-
On mobile devices we saw 32 byte IADs starting: tion on plastic cards and involves clearing the CVM bit in the
Apple (CDCVM) : 1F4A5732A0000000001003... TTQ – i.e. the reader will believe that no CDCVM is required.
Apple (transport) : 1F4A5760A0000000001003... For over the limit transactions on Apple Pay Express Transit,
Google Pay (CDCVM) : 1F434651200000000000000... only clearing the CVM bit in the TTQ (without the CTQ flips)
Samsung (transport) : 1F436300200000000000000... results in the transaction failing on the reader side, i.e., this
Samsung (CDCVM) : 1F434642200000000000000... attack does not work against Apple Pay.
The attack presented by Basin et. al. [2] is a different
While the format of these longer IADs is not public, we
approach to achieving over the CVM limit transactions without
see that the first byte of the CVR, highlighted in red, always
requiring Cardholder Verification, on plastic cards. It involves
reflects whether or not CDCVM was used, therefore indicating
clearing the online PIN verification required bit and setting the
to the EMV back-end if CDCVM was used on the device.
CDCVM performed bit in the CTQ – i.e. tricking the EMV
During the disclosure process Visa confirmed this, and that
reader into believing the card has performed CDCVM. Our
these bytes were in the AC, but that Visa does not check them.
Apple Pay Express Transit CVM limit escalation also targets
In summary, Mastercard use the IAD to authenticate the
the CTQ. However, the online PIN verification bit is not set
use of CDCVM. From the IAD, Visa could determine if the
in our case. We target the CDCVM bit in CTQ in two places:
transaction was with a device capable of performing CDCVM,
it first appears in the response to the GPO message (under
and if CDCVM was used, and these could be authenticated
tag 9F6C), and in a record template, as part of the CARD
against the value in the AC, however this check is not currently
(tag 9F69). The CDCVM bit needs to be set in both of these
performed. If this check was performed then the Visa over the
EMV tags, otherwise the transaction is not successful.
limit attack against the iPhone would not be possible.
As a side-note, we confirm the Galloway attack still
4 https://www.moneysavingexpert.com/news/2020/10/ works against Google Pay (Pixel 5), two years after being
shoppers-to-be-able-to-get-cashback-without-buying-anything-unde publicised [7]. We found that the Basin et. al. attack did
not work against Google Pay: the combination of over the transition-rule applying to both behaviours wherever possible.
limit transaction amount and set CVM bit in TTQ results Before the app actually responds to the GPO, we have a
in the phone terminating the transaction after it receives ComputeCVR rule firing that implements the mobile-app
the GPO message, with the code 6986 (Command not logic of judging if CDCVM is needed based on the “magic
allowed), and therefore the CTQ is never sent. We conclude bytes” being received or not (i.e., perceived app operation
that Google detects and rejects any Visa transaction that mode) and value (high/low) sent in the GPO command.
requests authentication in the TTQ unless the phone has been We have two GPO-responding rules separated by the
unlocked. Unfortunately Apple Pay does not have this defence. Handset(’samsung’) vs Handset(’apple’) and
otherwise the facts produced by this ComputeCVR rule; these
G. Formal Verification two GPO-responding rules are the only way we differentiate
To analyse these protocols we use the Tamarin prover [18]. between Samsung and Apple Pay w.r.t. EMV-card behaviour;
This is a verification tool that supports symbolic/Dolev-Yao i.e., in the case of Samsung, we impose a restriction
analysis [29], [30]. Tamarin models are transition systems over _restrict(ZeroOnly_in_nonAuthen_Transport
a multi-sorted term algebra, operating on the semantics of (CDCVM_noCDCVM, perceivedAppMode, value))
multiset rewriting logic [31]. Security properties can expressed to allow only zero payments when in the ComputeCVR rule
as lemmas about the labels on the rewrite rules. Tamarin can it judged it is in transport mode.
then automatically either prove that a security proprieties holds Unlike the Basin et. al. model, in the GPO-responding rule,
or provide a counter example, i.e., find an attack. the cards create a more detailed IAD. Concretely, e.g., in the
1) Verifying Visa in Apple & Samsung Pay: We use formal Basin et. al. model, the IAD for Visa EMV mode was IAD =
verification to show that our attack is exhibited on the <’IAD’, CID>; ours is IAD=<’IADmobile’, CID,
EMV specification of Visa used inside an Apple Pay app but CVR, format>, and this additionally denotes that the CVR
not inside the Samsung Pay app. We show, formally, that (denoting if CDCVM was performed is included in the IAD),
the countermeasures proposed to Apple and Visa stop the and “format” specified if the card believes it is operated in
attack. Finally, we show that our attack cannot be completely transport or non-transport mode. This is entirely in line with
counteracted by any/all of the countermeasures, i.e., that it is Visa IAD formats for mobiles. Also, in our model, we add
still possible to relay to terminals that share the same MCC. that the MCC of the terminal is finally sent to the issuing
We endeavoured to create this model to account for a bank along with the whole transaction on a secure channel.
modular treatment of the countermeasures we discussed, e.g., The Bank. We implement three transaction-processing rules,
Apple and Samsung Pay differing only in the answers to accounting for the different possible behaviours: (case1) as in
GPO commands based on value inside this message, etc. The the models by Basin et. al., in this case the bank does not
Tamarin file can be found in Mobile Visa.spthy in [9]. check the CVR and format values inside the IAD, (case2) the
Tamarin Model for Mobile Visa: We used as starting bank does check the CVR and format values inside the IAD,
point the Tamarin models for contactless Visa “plastic cards” but does not cross-check these against the MCC; (case3) the
by Basin et. al. [2]. Unlike Basin et. al., we have one single bank checks all of the IAD, MCC and transaction data.
model which contains: (a) both EMV transaction-authorisation Verification. In the model, we add numerous sanity-check
modes (“DDA” – with SDAD, used in mobile transport mode, lemmas to show that all and only faithful behaviours w.r.t.
and “EMV” – no SDAD, used in non-transport mobile); to Apple/Samsung, transport/non-transport, and values are
(b) transaction-values above and below the limit (“high” vs present. We then prove/disprove the following lemmas: respec-
“low”). Most of our Tamarin rules for card, terminal and bank tively meaning:
are similar to the one in Basin et. al., but other extensions/- 1) the Apple-Pay attack is found:
modifications are necessary as we explain in the following.
a) via falsifying the “all-traces” payment-security
Terminals. A “Create_Terminal” rule generically
lemma1.a, for “case1” of the bank-checks above,
creates our terminals as follows. A terminal can be a
where the bank does not check the IAD;
“transport” vs “non-transport” terminal, and if it is the
b) via proving an “exist-trace” lemma1.b
former it sends the “magic bytes” we observed TfL
to send. Terminals can send “zero”, “low” and “high” 2) Samsung Pay does not suffer from the mode-
values. Terminals have an MCC value, which in the abusing payment attack (via proving an “all-traces”
model is as broad as “transport”/“non-transport” MCCs. To payment-security lemma2, quantifying over traces of
encode the Apple Pay business model, our protocol rules Handset(’samsung’))
indeed allow transport terminals to send any value (see 3) either of our two countermeasures stops the Apple attack:
Terminal_Sends_GPO_AnyValue_AnyMode_Visa i.e., the bank checking the CVR (lemma3), and the bank
rule). In this rule, we impose however a realistic restriction checking the MCC against the IAD-format (lemma4).
that non-transport terminals cannot accept zero values (i.e., see 4) it is still possible to relay a transaction from a transport
_restrict(NonTransportNonZero(mode,value)). terminal to another transport terminal, if they share the
Cards/Mobile Apps. We create rules for cards/apps as same MCC (lemma5)
generically and modularly as possible, with the same Note. Checking the format of the IAD (i.e., case2
above) is enough to stop the “CTQ-change”, “Tap & a complicated task in 2021, with plenty of resources available
PIN” attack in [2]. This is shown indirectly by our and tools which take care of the more “technical” steps of
lemma3 above. We also show this for the original model the process. We have tested a rooted Nexus 5 phone, which
Visa EMV High.spthy from [2]. I.e., the authentication for has the Broadcom BCM20793M NFC controller, running its
the bank (i.e., lemma auth_to_bank_minimal) holds stock firmware (Android 4.4) and running CyanogenMod 14.1
if the IAD format is checked. In the GPO-processing rule, (Android 7.1.1). On both versions we were able to successfully
the TTQ info received by the card now dictates the IAD set any UID we wanted by editing the NFC configuration file.
format, and in the rules relating to the bank processing the By building on the work of [26], we modified their Android
CVM (for the case of online/not-online PIN) we added IAD relay apps to add an extra step before any EMV messages
format checking (see lines 425, 749 of the amended file were exchanged. We ran the CardEmulator app on the
Visa EMV High BasinEtAl.spthy in [9]). Nexus 5 phone and used a Nokia 6 phone to run the
2) Verifying Mastercard in Apple & Samsung Pay: We use TerminalEmulator app. A server forwards data between
Tamarin to verify that no similar attack is possible against ex- the apps (no change to the original from [26]).
press transit mode for Mastercard on Apple Pay. The Tamarin On the TerminalEmulator app we added extra func-
file can be found in Mobile Mastercard.spthy in [9]. tionality which allows us to retrieve the UID of the card
We detail slightly less in this case, building on the previous the phone is in contact with. This is done through retriev-
section. Like for Visa, we base our model of Mastercard on ing the ID of the Tag object that was discovered by the
the work of Basin et. al. [2], to this model we add a) the ACTION_TECH_DISCOVERED intent, and sending it to the
more detailed IAD that encodes if the device used the user server, which will then forward it to the CardEmulator app.
authentication (CDCVM) or not, b) that devices may indicate
In the CardEmulator app we receive the UID and set it
in the AIP that the device supports CDCVM but that a device
as the phone’s UID by:
might not use it, c) we add the Merchant Category Code
(MCC). Our experiments and conversations with Mastercard’s • Remounting the system partition with read and write
security team indicate that (unlike Visa) all of these values are permissions;
actually checked. We also make some simplifications to the • Replacing the NFA_DM_START_UP_CFG parameter in
model in [2]: i.e., we only model Mastercard with a SDAD, the /etc/libnfc-brcm-20791b05.conf configu-
as we have not seen any support for transactions without this ration file such that it includes the UID:
across any of our devices or readers. Unlike for the Visa model, – we add 6 to the first byte of the config parameter, which
we only consider two payment amounts, a low and a high holds the length of NFA_DM_START_UP_CFG, as we
value. For Apple Pay Express Transit, we add that devices will be adding 6 more bytes;
may function without the device authentication if the “magic- – at the end of NFA_DM_START_UP_CFG, we add the
bytes” action is present in the trace and if the MCC code NCI parameter LA_NFCID1 (0x33), which means the
indicates that the terminal is a transport reader. UID is declared in this configuration parameter, the
Using Tamarin we are able to prove that: for uncompro- length of the UID (0x04), and the UID itself;
mised Mastercard Apple Pay devices, if the bank accepts • Restarting the NFC service.
a high transaction amount then the device must have used
CDCVM user authentication and we can further show that The complete set of steps for setting the UID on the phone
this is based on Mastercard checking the IAD, indicating that takes approximately 181ms. After this, the EMV level relay
this is an important part of Mastercard’s protocol. can proceed as normal. We confirmed with a Proxmark that
To show that the Visa Apple Pay attack is not possible the UID of the Nexus phone was equal to the UID of the
against Mastercard, we show that the bank will only accept relayed card. Fig. 12 in Appendix B presents the overview
a non-CDCVM transaction from a terminal with a transport of the communication between all the devices involved. Our
MCC code. This means that relay attacks using transit express modified apps are available in [9].
mode are limited to only relaying to other transit terminals. With this attack we can break Visa’s relay protection
protocol. When the L1SessionParameter is sent signed
V. V ISA’ S L EVEL 1-R ELAY P ROTECTION as part of the EMV protocol, the EMV reader will decrypt
As stated in their attacker model, Visa’s solution relies on it, and it will match the UID of the phone. We can achieve
the inability of the attacker to change the UID of a card or mo- this both because we can set a phone’s UID as desired and
bile phone, which they refer to as L1SessionParameter, because, although there is an overall timeout for the transaction
and the difficulty of relaying the Level 1 messages due to (the EMV specification says 500 ms [34]) there is no round-
their timing constraints. However, setting a desired UID on trip timing measurement within Visa’s protocol, which means
some mobile devices is possible [32], if the device is rooted. the card may wait in the PROTOCOL state (before the EMV
This has been introduced in Android 4.4, as host-based card protocol starts), for the SELECT 2PAY.SYS.DDF01 message
emulation, and allows an app to emulate a card (or NFC from the EMV reader, as the transaction timing is enforced
tag) and talk directly to a NFC reader [33]. While this is a by the EMV reader with which we start interacting after the
departure from Visa’s attacker model, rooting a phone is not UID change has happened.
 Start | End | Src | Data (! denotes parity error) | CRC | Annotation
VI. L EVEL 1 AND L EVEL 3 T IMING IN EMV ------+-------+-----+------------------------------------+----+-----------
0 | 1056 | Rdr |26 | | REQA
We experimented with the reliability of timing at Level 1 2260 | 4628 | Tag |04 00 | |
13296 | 15760 | Rdr |93 20 | | ANTICOLL
and Level 3, and therefore the feasibility of relaying at 16964 | 22788 | Tag |3f af e3 54 27 | |
44144 | 54672 | Rdr |93 70 3f af e3 54 27 9a 70 | ok | SELECT_UID
these two levels. We experimented with several commercial 55860 | 59444 | Tag |20 fc 70 | |
EMV cards (Visa and Mastercard), as well as aprototype, 67680 | 72384 | Rdr |e0 50 bc a5 | ok | RATS
77364 | 91252 | Tag |0a 78 80 70 02 20 63 cb b7 80 8b 30 | ok |
test prototype PayPass-RRP card, bought from a vendor
called ICC Solutions. We found no commercial/bank-issued Fig. 5. Excerpt from a Proxmark trace (timing in carrier periods ≈ 0.074µs)
PayPass-RRP cards.
Mastercard RRP select uid average Mastercard rats average
We show that timing exchanges at Level 1 are much faster
than at Level 3, and show much less variation, and the Level 3
variation in timing is considerable for all EMV cards that we 1124.37 3521.41

Time (us)

Time (us)
tested, and more so, for a proprietary card that implements a 1123.95 3339.17
1123.54 3156.92
test version of PayPass-RRP, we can relay at Level 3 with 1123.13 2974.67
a standard relay program. Overall, the variation at Level 3 1122.71 2792.43
30.6 27.4
across all cards, has led us to propose a new Level 1 protocol 27.4
24.2
24.2
21.0

)
0 0

m
21.0
for relay protection in EMV, in Section VII, which improves

(m

(m
45 45 11.4

ce

ce
90 11.4 90
Angle Angle

tan

tan
s (deg 135 5.0 s (deg 135 5.0

Dis

Dis
on both Visa’s and Mastercard’s current solutions for relay ) 180 ) 180

counteraction.
Fig. 6. Mean reply time for the 14443-A SELECT UID and RATS commands
A. Level 1 and Level 3 Timings for EMV Cards (note the different scales here)
We measured the Level 1 and Level 3 message round trip to a reader command, both for Level 1 and Level 3 level
times (RTTs) for: (1) a Mastercard-RRP test card; (2) a messages. The reply time for one command is defined as
“normal” commercial Mastercard; (3) a commercial Visa card. t = p (RdrStart − T agEnd ), where Rdrstart is the time when
All the raw data, processing scripts and other programs we the reader starts transmitting its message and T agEnd is the
used are available in [9]. time when the card stops sending its reply.
Hardware/Software Setup: We used an Advanced Card
Systems ACR122u reader. A program acts as an EMV reader, B. Timing All EMV Cards at Level 1
prepares the correct sequence of challenges (ISO 14443 mes- For Level 1 timings, we focused on the responses to the
sages, or Level 2 Command Application Protocol Data Units SELECT UID and Request for Answer To Select (RATS)
(C-APDUs)) for a transaction with the card and, via the commands that both occur after the anti-collision routine is
ACR122u reader, sends this to the card; the sequences were complete. Note that the reply to the SELECT UID requires
different for each card (PayPass-RRP, Mastercard, Visa), as no computation from the NFC chip on the card and would
each executes a different protocol. To obtain RTTs and other be consistent with the behaviour of a nonce exchange if the
timings related to these exchanges, we placed a Proxmark in- card’s nonce was prepared before the challenge was received.
between the reader and card, to sniff the transaction, and thus Fig. 6 shows the average reply times for the Level 1
we obtained the full traces of the exchanges. This is discussed SELECT UID command and the RATS commands. The RATS
further in Appendix C. command involves more processing and its times are longer,
Experimental Design: To capture the variations that occur but still much shorter than those at Level 3. It can be seen
when someone makes a contactless payment, we varied the that there is little change in the timings for the SELECT UID
yaw angle at which the card was placed in the field and the as we vary the angle or distance of the card. The standard
distance between the card and the reader. The distance was deviation did not vary across angles or distances and was
maintained by resting the card on a spacer. We tested at angles only 0.91µs and the time difference between the quickest reply
of 0°, 45°, 90°, 135° and 180°, and at distances of 5mm, and the longest is only 2.36µs. For the RATS, the “normal”
11.4mm, 21mm, 24mm, 27.4mm and 30.6mm. These are all Mastercard, had the longest average response time out of all
realistic positions a card may be held in to make a payment. the cards, of 3231µs, with a standard deviation of 286.50µs.
We took 20 measurements for each physical configuration, So, for our experiments, timings at Level 1 appear relatively
making a total of 600 tests. We note that, apart from the stable across all EMV cards.
initial Level 1 messages, what we are actually measuring is
the time from when the reader sends the C-APDU (at Level 2) C. Timing a RRP Test-Card at Level 3
until it receives the Response Application Protocol Data Unit For Level 3 timings, we focus on the nonce-exchange in
(R-APDU) (also at Level 2) back from the card. the ERRD command, although results were obtained for the
Generally, the reader sends a message/C-APDU and other APDUs, so that they could be compared with the other
waits for a response/R-APDU from the card. We used the cards that we tested (see Appendix C).
hf 14a sniff command of the Proxmark client, which Our Mastercard-RRP test card implements up to three
sniffs the ISO 14443-A traffic and produces traces as per nonce-exchanges, as per the ERRD command we described
Fig. 5. Thus, we can calculate the reply time of a card in Section II. In our tests, we sent all three nonce challenges,
 Mastercard RRP rrp 1 average Mastercard RRP rrp 2 average

56545.71 56545.71

Time (us)

Time (us)
50542.87 50542.87
44540.03 44540.03
38537.19 38537.19
32534.35 32534.35
26531.50 26531.50
30.6 30.6
27.4 27.4
24.2 24.2

)
0 0
m

m
21.0(m 21.0

(m
45 45
ce

ce
90 11.4 90 11.4
Angle Angle
tan

tan
s (deg 135 5.0 s 135
(deg) 5.0
Dis

Dis
) 180 180
Fig. 8. Relay setup used to investigate possible PayPass-RRP relaying.

Fig. 7. Mean reply time for the nonce exchange commands implemented on card, we presented it to the reader and of ten trials, three gave
our Mastercard-RRP Test Card
timings within those seen in our measurements (for rrp 1, these
i.e., three C-APDUs, and measured the response times for each times were 67.79, 74.70 and 77.05ms, while the maximum
(labelled: rrp 1, rrp 2 and rrp 3). The average timings for seen for a direct replay was 79.62ms.).
the first and second nonce-exchange messages at the different We discussed this relay attack against the test PayPass-
heights and angles are shown in Fig. 7. The timings for the RRP card, and all the measurements, with Mastercard. They
third nonce exchange are very similar to those for the second. welcomed the research and our suggestion that doing the timed
The statistics for these three exchanges (mean/SD in µs) are: nonce-exchange at Level 1 may indeed be more robust against
53,000/13,170, 40,100/15,700 and 40,100/15,680. We note: even slightly stronger relay “boxes”. They also mentioned that
• The time for the first RRP exchange is significantly the three trials in the ERRD command should not be seen
longer. The Proxmark traces showed us that for the first only as an opportunity for re-tries by the relayer, but also
challenge only, the card responds to the ERRD command as a usability/recoverability feature: correcting human error,
by sending a wait request and then the response. and alerting the user that the card is in a non-ideal position.
• The time taken depends on the distance of the card from Finally, they mentioned that newer cards (test or commercial),
the reader, and not so much on the angle. A correlation which may appear soon, will be faster than our test card, and
analysis confirmed this dependence. Similar correlations so much harder to relay.
were seen for the other APDUs that were measured.
• The standard deviations did not vary between positions
VII. A N EW L EVEL 1- BASED R ELAY-P ROTECTION FOR
and was approximately 13,170, 15,700 and 15,680µs for EMV: T HE L1RP P ROTOCOL
the different nonce exchange rounds. A. Protocol Design
• The timings measured inside the replay program are
Our L1RP protocol is an extension of the Mastercard EMV
significantly longer than those reported here, there is protocol, and it provides relay resistance by timing a nonce
an approximately 17 ms difference (see, for example, exchange at Level 1. The aim of our protocol is to ensure
Figure 14 in Appendix C which shows the results for all that the EMV reader cannot successfully complete an EMV
of the first ERRD command exchange (denoted as rrp 1) transaction unless the card responds to the reader with its
measurements). We initially thought that these delays nonce within the given time bounds. As in Mastercard’s RRP
were due to the time taken to communicate with the protocol the card also returns timing information to enable
ACR122u reader, but subsequent tests with an Adafruit the reader to adjust its thresholds to allow for different timing
PN532 interface connected to a Raspberry Pi showed profiles on different cards.
that the delays arose due to the PN532’s handling of
We work in the threat model outlined in Section III. To
the protocol. (The ACR122u also uses the PN532 IC to
this we add the requirement that cards must be backwards
handle the NFC signalling).
compatible with readers that do not support relay resistance,
In conclusion, all measurements, for all the cards tested, without the possibility of downgrade attacks. Additionally,
showed that timings at Level 3 are far less stable than at we must ensure that the timing profile from the card can be
Level 1. This suggests that timing for relay-protection should, authenticated by the reader.
for better all-round security, be done at Level 1 for EMV (and Protocol Overview: Following our findings in Section VI,
for other application-layer protocols). our L1RP protocol takes ideas from both the Mastercard and
the Visa relay-protections, improves on aspects of them and
D. Relaying & Disclosure to Mastercard combines the result into a new protocol.
Given the observed Level 3 timing variation, we looked at Our L1RP protocol moves the timed nonce-exchange, pro-
the feasibility of relaying the timed nonce exchange from the posed in Mastercard PayPass-RRP, into the ISO 14443
PayPass-RRP test card. Using the simple setup shown in Level 1 commands. This is informed by our measurements
Fig. 8 we found that it is indeed possible to relay at Level 3 in Section VI-B, where we concluded that Level 1 Relay
faster than the time taken by the card in the worse position to Resistance makes the RTT-measurements more reliable. As
complete a normal run. While holding the test PayPass-RRP with the proposed Visa protocol, we tie together data at Level 1
 Reader Card but this is left to the card implementer. We opt for this
EMV-driven approach, that is – we do not specify our card-
nonceR ∈R {0, 1}32 AIP = Relay Protection,..
nonceC ∈R {0, 1}32 side nonce generation at the low-level. Normally, this is
proprietary to manufacturers (e.g., NXP), and should adhere to
ISO 14443
messages
WUPA
ATQA
the AIS 20/31 requirements (PTG.1/2/3, DRG.1/2/3/4) [36] for
ANTICOLL
PRNG security certification. Should a manufacturer implement
UID our protocol, we recommend similar PRNG-security practice
SELECT UID

SAK
guidelines, as well as checking developments in the field of
NONCE REQ nonceR PRNGs for cards [37] and for other computationally-limited
timed NONCE RES nonceC
devices [38].
RATS

ATS
Including Proof of the Level 1 Nonce Exchange in
Level 3: At the EMV application level our protocol runs ex-
MasterCard’s
protocol as Fig. 1
SELECT 2PAY.SYS.DDF01
actly as the Mastercard PayPass protocol, but after receiving
...

...
the AC, the L1RP-compatible reader will use a new READ
KS = EncKM (ATC) RECORD command to read out the timing information for
AC = MACKs (CDOL1,AIP,ATC,AID)
SDAD = Sign(AIP,CID,AC,CDOL1,UN) the card (expected, maximum and minimum response times)
CID, ATC, SDAD(AC), IAD
and the Level 1 nonces signed by the card along with the AC.
READ RECORD These signed nonces attest that the Level 1 nonce exchange
SignP rivC (AC, nonceC , nonceR , timing info)
was done with the the card, and binds the nonces to the AC.
Protection from Downgrade Attacks: The card’s ability to
run our protocol is recorded in the AIP, described in Section
II-A, it is signed by the card in the SDAD which is checked by
Fig. 9. Our new L1RP protocol
the reader. So, any attempts to downgrade a card by changing
with the EMV application authentication at Level 3. However, the AIP, to make the reader believe it doesn’t support L1RP
note that at Level 1, we include nonces issued not just from will be detected by the reader as a mismatch in the SDAD.
the card but from the reader as well, to avoid the problems Separate Relay Resistance and Payment Proofs: We note
with the Visa proposal that we highlighted in Section V. the separation of relay resistance and payment proofs (e.g.,
A run of our protocol L1RP is shown in Fig. 9. The card adding a “special” SDAD-like message sent by the card for
signals to the reader that it supports our protocol using one of the distance bounding proofs). It would have been possible to
bits in the ISO 14443 Answer to Request (ATQA) message put the Level 1 nonces into the SDAD, rather than having a
reserved for future use (bit 6 & bits 9-16). A bit value of 0 separate new signature. We did not do this because: (1) we did
means the card does not support the nonce exchange, whereas not want the possibility that a normal EMV transcript could be
a value of 1 will signal that the exchange is supported. confused with a transcript of our protocol; (2) this separation
Level 1 Relay Resistance: As per ISO 14443-3 [23] and allows for better backwards-compatibility especially over vari-
outlined in Appendix A, after a card responds with a Select ous operation modes; (3) the separation allows clearer security
Acknowledge (SAK) message, it enters the ACTIVE state. The proofs (adhering to both established EMV as well as distance
protocol activation command (RATS) can then be sent by the bounding security models).
reader to start the application level protocol. However, a card L1RP vs Visa’s Level 1 Relay-Protection: We now sum-
that is compliant with ISO 14443-3, and in the ACTIVE state marise why L1RP does not suffer from the attack we showed
can accept proprietary commands from the reader instead. in Section V against Visa’s Level 1 relay-protection proto-
This allows us to introduce our new Level 1 command, col. Recall that the security claims in Visa’s relay-protection
NONCE_REQ, coupled with our NONCE_RES response; they protocol rely on a value called UID coming only from the
are used to execute the nonce exchange at the ISO 14443 level. card/phone’s side, i.e., the claimed security does not hinge
If the reader and card support our protocol, the reader sends on any input from the reader side.
the NONCE_REQ command with a 32-bit nonce. A reader that Unlike the Visa protocol, our L1RP protocol uses random
does not support the protocol will send the RATS command, nonces (as opposed to UIDs) and they are issued from both
missing this NONCE_REQ command. The L1RP card replies the card and the reader’s sides of the EMV protocol. Even if
with the NONCE_RES response, with a 32-bit nonce. The we weakened our protocol, and let the card/phone send a UID
NONCE_REQ – NONCE_RES exchange is timed by the reader, as per Visa’s case, just applying our attack from Section V as
to prevent MitM attackers from relaying the messages. See is would still not work against this weakened L1RP. In our
Fig. 10. After this exchange, the RATS command can be used attack, only the card’s UID is manipulated maliciously; if this
to continue the protocol. were applied to L1RP, the victim’s phone would not receive
Nonce Generation by the Card: Book 4 of the EMV the nonce of the real reader and the EMV-level checks in the
specification [35] (page 57) suggests that nonces on EMV last step of L1RP would fail.
cards should be generated using specialist algorithms and Now assume we lifted our attack in Section V to a MitM
circuits, e.g., via a PRNG (pseudorandom number generator), who was resetting both the card and reader’s nonces in L1RP.
In L1RP, the reader’s nonce is sent out first, and the nonce [usb] pm3 --> hf 14a list
[+] Recorded activity (trace len = 137 bytes)
exchange is timed by the reader. So, to fall within the allowed [=] Start = Start of Start Bit, End = End of last modulation.
Src = Source of Transfer
time-bound, the attacker would have to guess preemptively the [=] ISO14443A - All times are in carrier periods (1/13.56MHz)

nonce of the reader such as to send it in time to the victim’s Start | End | Src | Data (! denotes parity error) | CRC | Annotation

phone. This would happen with a probability of 2−32 , under --------+--------+-----+-------------------------------+-----+------------

0 | 992 | Rdr |52 | | WUPA
2100 | 4532 | Tag |04 01 ← 01 indicates to do the random nonce exchange
our assumption of pseudorandom nonces. 7040 | 9504 | Rdr |93 20 | | ANTICOLL
10548 | 16372 | Tag |88 f6 53 90 bd | |
In summary, the security of our protocol is based on: (1) 19072 | 29536 | Rdr |93 70 88 f6 53 90 bd ec 2e | ok | SELECT_UID
30644 | 34228 | Tag |20 fc 70 | |
session-identifying, pseudorandom data coming not just from 36480 | 44704 | Rdr |99 76 0a 4f 8a 7e e3 |
select completed
| NONCE_REQ
timed
one side but from both sides of a two-party protocol; (2) timing 45748 | 51572 | Tag |c0 7d 6a d1 06
56192 | 60960 | Rdr |e0 80 31 73
| | NONCE_RES
| ok | RATS
this exchange of the random data, so not only can the MitM 62004 | 69044 | Tag |04 58 80 02 13 ce | ok |

attacker not guess it, given its pseudo-random nature, but this
MitM cannot relay it effectively either. Fig. 10. The nonce exchange proposal.

that our protocol provides the distance bounding protection we

B. Formal Verification of Security require. The full annotated model is in L1RP.spthy in [9].
We extend our model of Mastercard’s contactless protocol
C. Practical Experiments
from Section IV-G with support for our L1RP protocol. New
rules model the sending of the Level 1 ATQA message that The proposed extension to the current Level 1 protocol was
will indicate if a device supports our protocol and, for devices tested using two Proxmarks. On one Proxmark, we imple-
that do, the NONCE REQ, NONCE RES nonce exchange mented the reader protocol including, if required, the nonce-
messages, as well as the reader asking for the DB proof. We exchange, and on the other, we implemented a simulation of
also enhance the model with the reader checkiing of this DB- the card, again including our proposed nonce-exchange. On
proof, the protocol-type recorded in the AIP, and add lemmas top of this L1RP-driven implementation, our Proxmark-based
to verify the lack of downgrade attacks. programs include code to measure the message times needed
Our model includes devices and readers that do and do not to assess our implementation. The timings (and other tests)
support our L1RP protocol. We check that any combination of only refer to Level 1 commands up to and including the RATS
devices and readers can finish an EMV transaction. We check command, as these are the ones used in L1RP.
protection from downgrade attacks by ensuring that a reader The results from one of our timing tests are shown in
that supports our L1RP protocol can only ever finish a run, Fig. 10, which also highlights the proposed changes to the
without DB protection, if the device it is running the protocol protocol (in this case, for a 4 byte UID).
with does not support our L1RP protocol. Proxmark Implementation of L1RP: We modified the
Proxmark code to add two Level 1 functions, one to imple-
To verify protection from relay attacks we use the frame-
ment the reader side and the other the card side. These were:
work of Mauw et. al. [5], who present a definition of causality-
• noncerdr this implements the reader side and executes
based secure distance-bounding. This can be used to verify the
correctness of distance-bounding protocols without the need the protocol up to the RATS message. If bit 9 of the
to explicitly model time and locations. This model assumes a ATQA message is set it carries out the nonce exchange.
protocol with a verifier (the terminal) and a prover (the device). The nonce is obtained using the Linux getrandom
The verifier will have a timed phase; in our Tamarin model function which gets random bytes from /dev/random.
• noncesim this simulates a card which expects to do a
we indicate this by a DB Start action when the terminal sends
the NONCE REQ message and a DB End action when the nonce exchange and so sets bit 9 in ATQA. The card is
terminal receives the NONCE RES message. given a random UID and nonce, these are both obtained
The action that the device/prover is expected to perform using the Linux getrandom function.
during this phase (the reply to the NONCE REQ message) is Notes on the implementation:
tagged with a DB Action label, and we add a DB Claim label • We used ATQA bit 9 to flag that the card can do the
to the terminal Tamarin rule that verifies the DB proof. All of nonce exchange.
these actions are parameterised on the identities of the prover • To identify the reader’s nonce exchange message, we
and the verifier, and the nonces used in the transaction. chose an unused message code, 0x99. On the card side,
Mauw et. al. [5] show that the standard notion of distance- we send the nonce and a Block Check Character (BCC),
bounding security, regarding MitM attackers, holds if when- as is done when a card sends its UID.
ever there exists a DB Claim(P,V,Nc,Nr) action in a trace • We tested the backwards compatibility of our new card
then there must have been a preceding DB End (V,Nc,Nr) and reader implementations by verifying that they would
action, preceded by a DB Action (P,Nc,Nr) preceded by a work with an existing EMV reader and EMV card.
DB Start(V,Nr). I.e., the prover must have acted during the Time Measurements for L1RP: The RTT using the Prox-
timed phase of the verifier or, P or V must have been compro- marks was measured in 30 tests with a mean of 1,116µs
mised. This definition a la Mauw et. al. [5] is easy to check with a standard deviation of 2.3µs. This time is very similar
in Tamarin, which takes 327 seconds to show that it holds and to the time measured for the SELECT UID command for
the Proxmarks and for ‘actual’ payment cards (see Table I, information on this, first recounted in [47]. These show that
Appendix C), which suggests time bounding this exchange NXP’s distance bounding uses a Level 1 nonce exchange,
may work well. These Proxmark results are encouraging, and however it provides no details of how/whether this distance
we will implement L1RP and obtain more measurements. bounding is tied to the upper level protocols or applications.
Challenges when Relaying over L1RP: Analysing our Symbolic Verification of EMV: Past symbolic-verification
Proxmark-issued timing data, we observed that most of the models of EMV include [48], [2], [8] and of EMV with
time for the nonce-exchange is taken sending and receiving distance bounding [47], [26], [5], [49], [44].
the data (≈1037µs), i.e., not preparing the data. This makes a The most up-to-date and complete formal model for EMV is
relay with unmodified COTS hardware difficult. in [2]. We follow this model (for contactless Visa, Mastercard)
Reading the data directly and using this to modulate a and extend it to encode mobile apps in transport and non-
carrier signal used to transmit the data to a receiver where it is transport models, in a unitary manner (CDA, DDA, high/low
demodulated and used to drive a loop antenna could provide a in one model). We add a full model of the IAD to their models,
low-level relay, but this is a much more difficult undertaking and show that Visa/bank checking the IAD stops their attack.
than the threat model we envisage (see Section III). This type Symbolic Verification of Distance Bounding: Automat-
of lower-level relay has been illustrated for an LF RFID system able symbolic verification of distance-bounding protocols was
by Francillon et al. [19] who used it to attack a car’s RFID key- first proposed by Basin et. al. [50]. Many recent developments
entry system. However, this was for a LF RFID system and exist. Nigam et. al. [51] develop a distance bounding checking
not the HF RFID system used for EMV payment cards. While tool based on Maude. Rowe et al, [52] present a framework
implementing such a low-level (Level 1) attack on HF RFID based on strand spaces. Debant et. al. in [49], [53] are the
systems is theoretically feasible it has yet to be demonstrated. only symbolic models to encode time and location explicitly.
Symbolic models tend to eliminate timing even if this is
VIII. R ELATED W ORK
considered in some of the theoretical models. Chothia et.
Practical (relay) attacks against EMV were demonstrated in al., suggest a framework without an explicit model of time
a range of works, e.g. [39], [26]. Other attacks have been [26], [47]. Mauw et. al. [5], [54] have a proof that, under
reported against EMV. Two over the limit attacks, [2], [7] for certain conditions and for certain protocols (e.g., with one DB
Visa are discussed in sub-section II-B. In [8], a Mastercard exchange, with no other timing notions, without certain mes-
card is made to look like a Visa card in order to perform an sage inter-dependencies), timed DB-security can be reduced to
over the limit attack on Mastercard, which is now patched. checking an order of events on traces; this elegant definition
[2] describes an attack that makes an offline reader accept an can be easily checked in the Tamarin prover and is the method
invalid AC for Visa cards (an attack that was also described in we use. Boureanu, et. al. [44] extends this to support mobility.
[26, p.5]. Murdoch et. al. [40] presented a MitM attack against
contact based EMV, and evidence in practice is presented in IX. C ONCLUSIONS
[11]. Emms et. al. [41] show how the non-TAP & PIN card
limit can be bypassed by switching currencies. We investigated mobile payments-apps in different opera-
None of these attacks would work against EMV on mobile tion modes, showing their different defences against bypassing
devices if CDCVM authentication was always required, and authentication in transport mode. This allows us to make
these attacks require a relay, and so would be stopped by a fraudulent Visa payments with locked iPhones of any value we
protocol that prevented relaying (the main focus of our work). wish. This vulnerability is due to the lack of checks performed
We are the first to mount attacks bypassing authentication to on the iPhone combined with the lack of checks at the Visa
make illicit payments in mobile payment apps, and the first to back end. Apple Pay with Mastercard is not vulnerable and
look at and exploit their different operating modes. nor are Mastercard and Visa with Samsung Pay.
Distance Bounding: DB protocols were introduced by We have looked at the practical security of Mastercard and
Brands and Chaum [42] with the view of combating relay- Visa’s relay-counteraction solutions for EMV, and found that
based MitM attacks. In distance-bounding protocols a reader the former could potentially be functionally improved, whereas
and a tag (RFID card, smart card, etc.) run a challenge- the latter is lacking in security. To fix these issues, we have
response protocol in which the reader measures the RTT and if proposed an EMV relay-resistant protocol that combines ideas
this is smaller than a given bound, the reader assumes physical from both the Mastercard and Visa relay-countermeasures
proximity between it and the card. The survey in [43] gives proposals. We have proved our protocol formally correct and
numerous distance-bounding protocols, security concepts and described a trial implementation of its distance-bounding part,
attacks in distance bounding. on Proxmarks; this shows our protocol is practical for EMV
RRP closely follows the previously proposed PaySafe proto- cards, and also for use with Apple Pay and Samsung Pay to
col [26]. RRP was first formally verified in [5]. [44] performs stop relaying to the so-called express transit systems.
a timing analysis of RRP and finds it secure, but without Acknowledgements: This work is part of the “TimeTrust”
varying the positions of the card in the field, as we do. project, funded the UK’s National Cyber Security Centre
NXP provides a distance-bounding protocol on their DES- (NCSC). We thank Mastercard UK and Visa Research for
Fire cards. Patents [45], [46] are the only public source of providing useful insights and feedback.
 R EFERENCES [32] S. Jasek, “A 2018 practical guide to hacking nfc/rfid,” 2018.
[Online]. Available: https://smartlockpicking.com/slides/Confidence A
[1] EMVCo, “Book C-2 kernel 2 specification v2.7. EMV contactless 2018 Practical Guide To Hacking RFID NFC.pdf
specifications for payment system,” Feb 2018. [33] Android Developers, “Host-based card emulation overview,”
[2] D. A. Basin, R. Sasse, and J. Toro-Pozo, “The EMV standard: Break, 2019. [Online]. Available: https://developer.android.com/guide/topics/
fix, verify,” in Security and Privacy (SP), 2021. connectivity/nfc/hce
[3] C. Yuexi, M. Kekicheff, M. Top, and H. Ngo, “Binding Cryptogram [34] EMV, “Contactless specifications for payment systems, book A, version
with Protocol Characteristics,” 2019, uS Patent App. 16/348,085. 2.6 – architecture and general requirements,” 2016.
[4] H. Shan and J. Yuan, “Man in the NFC,” DefCon 25, 2017. [35] EMVCo, “Book 4: Cardholder, attendant, and acquirer interface require-
[5] S. Mauw, Z. Smith, J. Toro-Pozo, and R. Trujillo-Rasua, “Distance- ments,” May 2017.
bounding protocols: Verification without time and location,” in IEEE
[36] W. Schindler and W. Killmann, “Evaluation Criteria for True (Physical)
Symposium on Security and Privacy, SP, 2018.
Random Number Generators Used in Cryptographic Applications,” in
[6] “Lab 401 proxmark 3 rdv 4.” [Online]. Available: https://lab401.com/
Workshop on Cryptographic Hardware and Embedded Systems, 2002.
products/proxmark-3-rdv4
[37] R. N. Akram, K. Markantonakis, and K. Mayes, “Pseudorandom Number
[7] L.-A. Galloway and T. Yunusov, “First contact: New vulnerabilities in
Generation in Smart Cards: An Implementation, Performance and Ran-
contactless payments,” in Black Hat Europe, 2019.
domness Analysis,” in New Technologies, Mobility and Security, 2012.
[8] D. Basin, R. Sasse, and J. Toro-Pozo, “Card brand mixup attack:
Bypassing the PIN in non-visa cards by using them for visa transactions,” [38] A. Francillon and C. Castelluccia, “TinyRNG: A Cryptographic Random
in 30th USENIX Security Symposium, 2021. Number Generator for Wireless Sensors Network Nodes,” in Modeling
[9] “Practical EMV relay protection: Artefacts.” [Online]. Available: and Optimization in Mobile, Ad Hoc and Wireless Networks and
https://gitlab.com/practical emv Workshops, 2007.
[10] “Visa mobile contactless payment specification,” https: [39] L. Francis, G. Hancke, and K. Mayes, “A practical generic relay attack
//technologypartner.visa.com/Library/Specifications.aspx. on contactless transactions by using NFC mobile phones,” International
[11] H. Ferradi, R. Geacuteraud, D. Naccache, and A. Tria, “When Journal of RFID Security and Cryprography (IJRFIDSC), 2013.
organized crime applies academic results - a forensic analysis of an [40] S. J. Murdoch, S. Drimer, R. J. Anderson, and M. Bond, “Chip and pin
in-card listening device,” IACR Cryptology ePrint Archive, vol. 2015, is broken,” in Symposium on Security and Privacy, S&P, 2010.
p. 963, 2015. [Online]. Available: https://eprint.iacr.org/2015/963 [41] M. Emms, B. Arief, L. Freitas, J. Hannon, and A. van Moorsel,
[12] Visa, “Visa merchant data standards manual,” 2019. [On- “Harvesting high value foreign currency transactions from EMV con-
line]. Available: https://usa.visa.com/content/dam/VCOM/download/ tactless credit cards without the PIN,” in Computer and Communications
merchants/visa-merchant-data-standards-manual.pdf Security, CCS, 2014.
[13] EMVCo, “Book C-3 kernel 3 specification v2.6. EMV contactless [42] S. Brands and D. Chaum, “Distance-bounding protocols,” in Advances
specifications for payment system,” Feb 2016. in Cryptology – EUROCRYPT. Springer, 1993, pp. 344–359.
[14] ——, “EMV payment tokenisation specification – technical framework [43] G. Avoine, M. Bingol, I. Boureanu, S. Capkun, G. Hancke, S. Kardas,
v2.2,” 2020. C. Kim, C. Lauradoux, B. Martin, J. Munilla, and et al, “Security of
[15] “Visa contactlesspayment specification,” https://technologypartner.visa. Distance-Bounding: A Survey,” CSUR, vol. 4, 2017.
com/Library/Specifications.aspx. [44] I. Boureanu, T. Chothia, A. Debant, and S. Delaune, “Security Anal-
[16] EMVCo, “Book 2: Security and key management,” Nov 2011. ysis and Implementation of Relay-Resistant Contactless Payments,” in
[17] Visa Research, “Visa proposal for level 1 protocol parameter binding Computer and Communications Security (CCS), 2020.
against relay attack, version 0.1,” 2017. [45] P. Thueringer, H. De Jong, B. Murray, H. Neumann, P. Hubmer, and
[18] S. Meier, B. Schmidt, C. Cremers, and D. A. Basin, “The tamarin prover S. Stern, “Decoupling of measuring the response time of a transponder
for the symbolic analysis of security protocols,” in Computer Aided and its authentication,” November 2008.
Verification - 25th International Conference, CAV, 2013. [46] P. Janssens, “Proximity check for communication devices,” April 2015.
[19] A. Francillon, B. Danev, and S. Capkun, “Relay attacks on passive [47] T. Chothia, J. de Ruiter, and B. Smyth, “Modelling and analysis of a
keyless entry and start systems in modern cars,” Cryptology ePrint hierarchy of distance bounding attacks,” in USENIX Security, 2018.
Archive, Report 2010/332, 2010, https://eprint.iacr.org/2010/332. [48] J. de Ruiter and E. Poll, “Formal analysis of the emv protocol suite,” in
[20] M. Singh, P. Leu, and S. Capkun, “UWB with pulse reordering: Theory of Security and Applications - Joint Workshop, TOSCA, 2011.
Securing ranging against relay and physical-layer attacks,” in Network [49] A. Debant, S. Delaune, and C. Wiedling, “Proving physical proximity
and Distributed System Security Symposium, NDSS, 2019. using symbolic models,” Univ Rennes, CNRS, IRISA, France, Research
[21] “Where you can travel on public transport with apple pay,” 2020. Report, Feb. 2018.
[Online]. Available: https://support.apple.com/en-gb/HT207958
[50] D. Basin, S. Capkun, P. Schaller, and B. Schmidt, “Formal reasoning
[22] “Samsung faq,” 2020. [Online]. Available: https://www.samsung.com/
about physical properties of security protocols,” Transactions on Infor-
uk/samsung-pay/faq/
mation and System Security (TISSEC), 2011.
[23] ISO, “14443-3: 2018 – Identification cards – Contactless integrated
circuit cards – Proximity cards – Part 3: Initialization and anticollision,” [51] V. Nigam, C. Talcott, and A. Aires Urquiza, “Towards the automated
International Organization for Standardization, Standard, 2018. verification of cyber-physical security protocols: Bounding the number
[24] “Common vulnerability scoring system version 3.1: Specification of timed intruders,” in European Symposium on Research in Computer
document,” 2019. [Online]. Available: https://www.first.org/cvss/ Security (ESORICS), 2016.
specification-document [52] P. D. Rowe, J. D. Guttman, and J. D. Ramsdell, “Assumption-Based
[25] “Common vulnerability scoring system version 3.1 calculator,” 2019. Analysis of Distance-Bounding Protocols with CPSA,” in Logic, Lan-
[Online]. Available: https://www.first.org/cvss/calculator/3.1 guage, and Security, 2020.
[26] T. Chothia, F. D. Garcia, J. de Ruiter, J. van den Breekel, and M. Thomp- [53] A. Debant, S. Delaune, and C. Wiedling, “Symbolic analysis of terrorist
son, “Relay cost bounding for contactless EMV payments,” in Financial fraud resistance,” in European Symposium on Research in Computer
Cryptography (FC), ser. LNCS, 2015. Security, (ESORICS). Springer, 2019.
[27] Citi bank, “Merchant category codes,” 2015. [Online]. Avail- [54] S. Mauw, Z. Smith, J. Toro-Pozo, and R. Trujillo-Rasua, “Post-collusion
able: https://www.citibank.com/tts/solutions/commercial-cards/assets/ security and distance bounding,” in Computer and Communications
docs/govt/Merchant-Category-Codes.pdf Security, CCS, 2019.
[28] EMVCo, “Book 3: Application specification,” Nov 2011. [55] ISO, “14443-4: 2018 – Identification cards – Contactless integrated
[29] B. Blanchet, “Security protocol verification: Symbolic and computa- circuit cards – Proximity cards – Part 4: Transmission protocol,”
tional models,” in Principles of Security and Trust, 2012. International Organization for Standardization, Standard, 2018.
[30] D. Dolev and A. Yao, “On the Security of Public-Key Protocols,” IEEE [56] ——, “7816-4: 2020 – Identification cards – Integrated circuit cards Part
Transactionson Information Theory 29, vol. 29, no. 2, 1983. 4: Organization, security and commands for interchange,” International
[31] N. Durgin, P. Lincoln, J. Mitchell, and A. Scedrov, “Undecidability Organization for Standardization, Standard, 2020.
of Bounded Security Protocols,” in Workshop on Formal Methods and [57] EMVCo, “EMV Contactless Specifications for Payment Systems; Book
Security Protocols (FMSP’99), 1999. D; EMV Contactless Communication Protocol Specification,” 2016.
 stage. During this process a number of ANTICOLLISION and
SELECT messages from the reader are used, finally selecting
Reader Card a single card. In the final stage the reader sends a SELECT
message with the UID being selected and the card responds
U ID ∈R {0, 1}24 with an acknowledgement (SAK). This acknowledgement tells
WUPA/REQA
the reader that the card is compliant with ISO 14443-4 and
ATQA
can send the RATS message (bit 3=0 and bit 6=1). Fig. 11
The reader carries out the anti-collision routine. shows the process when there is only a single response and
ANTICOLLISION the anti-collision phase is cut short. This applies in the tests
UID that we have been doing and it should also be noted that, for
SELECT UID
payment cards, if the reader detects a collision the payment
SAK
is rejected [57]. Once a card is selected the reader moves on
Additional ANTICOLLISION, UID, SELECT UID
to the next part of the protocol with the card in the ACTIVE
and SAK, based on UID size transmitted in ATQA state.
RATS

ATS
B. ISO 14443-4
When a card is selected and in the ACTIVE state, the
ISO 14443-4 standard [55] specifies how the communication
should proceed. It starts with the reader sending a RATS
command and the card replying with an Answer to Select
Fig. 11. ISO 14443 Protocol Sketch (when there is a single card in the field) (ATS) response. These two message setup parameters for the
communications that follow, such as limits on the size of
frames that can be sent, or received, and for the card, timing
A PPENDIX A parameters and the “historical bytes”. Historical bytes are
T HE ISO 14443 P ROTOCOL optional and can be used to transfer card specific information
There are several standards for proximity cards defining from the card to the reader. This standard also details how
their electrical characteristics and how the fields are modu- large frames should be split, sent, and then re-combined, and
lated and data transmitted between a reader and a proximity how the card can request more time to respond by sending
(RFID) card. Contactless payment cards use the ISO 14443 frame waiting time extension requests. For our reader all of
standard [23], [55] for the lower levels of the communication these operations are carried out by the NFC chip, it sets
stack. There are four documents in this standard, the first two the parameters for the transfers (except the historical bytes)
define the electrical characteristics and modulation schemes to and once the RATS–ATS exchange is completed, frames to
be used. We do not need to consider these in the work that we and from the layer above are handled transparently. Splitting
are reporting. We focus on ISO 14443-3, which defines how frames will clearly affect the timing, so any timed exchange
a card establishes a link with a reader and on ISO 14443-4, should use as small a frame as possible.
which gives the transmission protocol to be used after the card A PPENDIX B
is “linked” to the reader. Built on top of this is a protocol, T HE PAY WAVE & VISA-L1 P ROTOCOLS
ISO 7816-4, which defines how data is packaged up into
APDUs. The EMV specifications refer to the 14443 standards The VISA-L1 protocol is an extension of the Visa Pay-
as Level 1, the ISO 7816-4 standard [56] as Level 2, and the Wave protocol shown in Fig. 2.
EMV messages themselves as Level 3. The extension of the Visa PayWave protocol to the VISA-
L1 protocol is one where the UID (the blue message in Fig. 11)
A. ISO 14443-3 is randomised (as opposed to being static) and this UID is
The ISO 14443-3 standard [23] defines how the initial link included in the SDAD. The Visa specification document [17]
between a reader and a card is setup (see Fig. 11). The reader only states that the UID should be cryptographically bound
is regularly polling for proximity cards by sending WUPA with the Level 3 protocol session data. Doing this by including
or REQA messages. When a card enters the magnetic field the UID specifically inside the SDAD (as opposed to other
generated by the reader, the card draws energy from the reader parts of the protocol, such as the AC) is based on our
and when it receives a WUPA or a REQA message it starts conversations with Visa Research.
the protocol by replying with an ATQA message. Fig. 12 shows the diagram of the relay attack against VISA-
The ATQA response gives the reader information about the L1, which can be done with a rooted Android phone.
card that it can then use in the steps that follow. In particular,
it tells the reader the size of the UID that the card uses and A PPENDIX C
this is used in the next anti-collision phase. Several cards T IMINGS R ESULTS
could respond to the same WUPA/REQA message and the For the Mastercard-RRP test card, in addition to measuring
anti-collision phase is used to select a single card for the next the RRP messages, we also measured the response times for
 TABLE I
L EVEL 1 REPLY TIME MEASUREMENTS FOR M ASTERCARD AND V ISA
Reader CardEmulator TerminalEmulator Card CARDS , IN µ S .

U ID1 U ID2 command avg std bytes range

Mastercard-RRP
ISO 14443-A activation protocol
card sends U ID2 (as per Fig. 11)
wupa 340.46 0.91 2 2.36
anticoll 699.15 0.88 5 2.36
U ID2
select uid 1123.91 0.89 3 2.36
rats 2875.93 163.82 22 549.85
setUID(U ID2 )
Mastercard
wupa 340.09 6.17 2 146.31
WUPA
ATQA
anticoll 699.08 0.70 5 2.36
ANTICOLL
select uid 1127.77 12.38 3 208.85
U ID2 rats 3231.61 286.50 21 989.97
SELECT UID Visa
SAK wupa 339.34 13.55 2 147.49
RATS anticoll 699.29 0.76 5 2.36
ATS select uid 1127.29 17.58 3 208.85
rats 1799.91 82.73 12 246.61
EMV protocol relayed

Mastercard GPO 1 average Mastercard RRP GPO 1 average

101569.77 101569.77
Fig. 12. Relay of card UID against Visa’s relay protection protocol

Time (us)

Time (us)
87122.69 87122.69
72675.61 72675.61
58228.52 58228.52
43781.44 43781.44
the other messages used. For comparison, we also measured 29334.36
27.4
29334.36
30.6
the response times for the messages from a “normal” Master- 24.2 27.4
24.2
21.0

m)

m)
0 0
21.0

(m

(m
card and Visa card running their protocols. Apart from the 45 11.4 45

ce

ce
90 90 11.4
Angle Angle

tan

tan
s (deg 135 5.0 s (deg 135 5.0

Dis

Dis
test card, none of our Mastercards responded to the RRP ) 180 ) 180

Visa GPO 1 average

messages.
The timings for the Level 1 messages are given in Table I.
We see that the average response times for the WUPA, 101569.77
ANTICOLL and SELECT UID messages are all very similar.

Time (us)
87122.69
72675.61
Although there are some differences in the variability, note 58228.52
43781.44
that these figures are in µs. For all three of these messages 29334.36
27.4
there is no correlation between the time taken and the distance 24.2
21.0

m)
0
of the card from the reader (see Table III). For the RATS 45
90 11.4
ce
(m
Angle
tan

messages the two Mastercards have similar timings, while for s (deg 135 5.0
Dis

) 180

the Visa card the response time is shorter, but so is the message
size. However, the difference in length does not totally explain Fig. 13. Average reply times for the EMV GPO command and response
the differences. The timings for the responses to the RATS
message are correlated with the distance from the reader. It
is difficult to be certain, but it seems that for the first three angle are shown in Fig. 13. Just as for the RATS command,
of these messages the response is automatic, once energised there is a clear correlation between the response times and the
by the field the card can immediately respond. The RATS distance of the card from the reader for all of these commands
message clearly needs some processing to be done before it (see Table III).
can respond and the time for this depends on the strength of We also carried out correlation analysis on the timing
the energising electromagnetic field. This is also seen in the measurements, with respect to the different distances we
Level 3 results given below. To minimise time variations, any recorded. We tested the hypothesis of whether there is a
nonce exchange at this level should be organised so that any linear relationship between the distance between a card and
processing required is kept to a minimum – the card’s nonce a reader, and the reply times observed, for each Level 1 and
should be generated as soon as the card enters the field and Level 3 command. The data reveals that for most Level 1
before it responds to the WUPA command. commands (WUPA, ANTICOLLISION and SELECT UID),
We now present selected timing results for Level 3 com- there is no significant relationship. However, for Level 3
mands, we consider the GPO message with its reply, as well as commands there is a strong significant correlation between
the nonce exchanges of the Mastercard-RRP card. The results the two variables. This confirms the intuitive observations
obtained are summarised in Table II. For the GPO 1 message, formed from the average and standard deviation analysis, that
plots of the message timings with respect to card distance and performing distance bounding at Level 1 would allow tighter
 TABLE II
L EVEL 3 REPLY TIME MEASUREMENTS FOR M ASTERCARD AND V ISA
CARDS ACROSS ALL ANGLES AND DISTANCES , IN µ S .

command avg std bytes range

Mastercard-RRP
Select 2Pay 97371.78 14495.52 42 76842.48
Select AID 67223.86 6617.87 112 23995.28
GPO 1 58862.01 8926.51 51 28307.96
rrp 1 48429.66 6373.18 17 20200.59
rrp 2 34920.51 8672.56 17 28883.78
rrp 3 34919.93 8675.94 17 27638.94
read record: 01, SFI: 2 86088.06 5675.82 178 17990.56
read record: 01, SFI: 3 104328.99 5765.41 203 18273.75
read record: 01, SFI: 4 41900.57 5419.67 40 17139.82
read record: 02, SFI: 5 83108.45 5641.58 144 17851.33 TABLE III
checksum 23401.71 8088.24 5 25137.46 C ORRELATION COEFFICIENT AND PROBABILITIES FOR REPLY TIME
Mastercard MEASUREMENTS FOR V ISA AND M ASTERCARD CARDS .
Select 2Pay 39790.21 4472.72 81 15263.72
Corr coef p-value
Select AID 45680.31 7105.98 87 25137.46
Mastercard-RRP
GPO 1 51490.57 14234.50 25 48857.82
wupa -0.08 0.06
GPO 2 390503.14 129159.73 174 571411.21 anticoll -0.03 0.47
read record: 01, SFI: 2 63134.47 6804.63 180 23153.98 select uid -0.03 0.41
read record: 01, SFI: 4 85438.76 7171.63 201 44305.60 rats 0.82 < 0.05
read record: 02, SFI: 4 85050.24 7179.88 241 26033.04 Select 2Pay 0.80 < 0.05
Visa Select AID 0.83 < 0.05
Select 2Pay 37100.56 4485.14 81 13015.93 GPO 1 0.80 < 0.05
Select AID 37755.15 6217.96 91 17715.63 rrp 1 0.82 < 0.05
GPO 1 100902.32 21548.54 81 107037.17 rrp 2 0.85 < 0.05
rrp 3 0.85 < 0.05
read record: 01, SFI: 2 0.82 < 0.05
read record: 01, SFI: 3 0.82 < 0.05
read record: 01, SFI: 4 0.82 < 0.05
read record: 02, SFI: 5 0.82 < 0.05
checksum 0.82 < 0.05
restore 0.88 < 0.05
Mastercard
wupa 0.02 0.62
anticoll -0.16 < 0.05
select uid 0.06 0.14
rats 0.74 < 0.05
Select 2Pay 0.72 < 0.05
Select AID 0.72 < 0.05
GPO 1 0.74 < 0.05
GPO 2 0.73 < 0.05
read record: 01, SFI: 2 0.73 < 0.05
read record: 01, SFI: 4 0.72 < 0.05
Fig. 14. RRP 1 timings obtained from the Proxmark and from inside the read record: 02, SFI: 4 0.73 < 0.05
replay program. Visa
wupa -0.01 0.70
anticoll -0.28 < 0.05
select uid -0.06 0.12
time bounds to be imposed. rats 0.69 < 0.05
Select 2Pay 0.81 < 0.05
Select AID 0.82 < 0.05
GPO 1 0.81 < 0.05
restore 0.78 < 0.05
 A PPENDIX D
EMV ACRONYMS & M ODELS D IFFERENCES

TABLE IV
EMV ACRONYMS USED IN THIS PAPER .

AC Application Cryptogram A cryptogram generated by the card and used by the Issuer to confirm the legitimacy of the
transaction.
AFL Application File Locator A list of application data records stored on the card. This is used to indicate to the terminal what
data should be used when processing the transaction.
AID Application Identifier An Application Identifier uniquely labels an EMV application. A card reports to a reader the AIDs
programmed into it, and the reader will select a supported one to process a transaction.
AIP Application Interchange Profile This indicates to the terminal what processing should be done for the transaction.
ATC Application Transaction Counter A counter stored on the card and incremented for each transaction. The Issuer monitors this value
which should always increase.
CARD Card Authentication Related Data Authentication data that may be returned as part of the transaction data. If returned it includes a
card nonce and the authorised payment amount.
CDA Combined DDA and AC This is one method used for offline card authentication and the signed data and application
cryptogram are generated together.
CDCVM Consumer Device CVM The authentication method used on the consumer’s own device for cardholder verification.
CDOL Card Risk Management Data Object This list specifies the data to be used when generating the AC.
List
CID Cryptogram Information Data This data is returned by the card as part of the response to the Generate AC command. It is used
to indicate the type of cryptogram and the actions to be taken by the terminal.
CTQ Card Transaction Qualifier This is set on the card when it is issued and is used to control what actions the terminal should
take during a transaction.
CV Cardholder Verification Verifying that it is the legitimate cardholder who is making the transaction.
CVM Cardholder Verification Method This is used to verify that it is the legitimate cardholder that is presenting the card for payment.
There are different verification methods and they have different payment limits applied to them.
CVR Card Verification Results Data returned to the Issuer as part of the IAD.
DDA Dynamic Data Authentication Used to authenticated the card, but unlike SDA the card is required to sign a nonce from the terminal.
This is more secure and is designed to stop replay attacks.
ERRD Exchange Relay Resistance Data The EMV command used by the Mastercard protocol for providing relay resistance for contactless
cards.
FCI File Control Information This is a template that gives information about the data fields that follow. The FCI is not specific
to EMV, it is part of the Level 2 specification (ISO/IEC 7816-4 [56]).
GEN AC Generate AC The instruction to generate the application cryptogram.
GPO Get Processing Options A command sent to the card with the requested PDOL data to retrieve transaction specific application
data (AFL and IAD).
IAC Issuer Action Code This specifies what action the Issuer wants to be taken based on the TVR. Possible actions are:
default, denial and online.
IAD Issuer Application Data Proprietary application data to be used in the transaction.
ICC Issuer Country Code Indicates the country of the card issuer.
MCC Merchant Category Code A standard code (ISO 18245) used for retail financial transactions to classify the business type.
MNL Merchant Name and Location Just what it says, although it is not always correctly initialised. For TfL it contains the station name.
ODA Offline Data Authentication Mode of authenticating the card when the terminal is offline. This may be done using DDA, or
SDA.
PAR Payment Account Reference A non-financial reference assigned to each unique Payment Account Number (PAN) and used to
link a Payment Account represented by that PAN to an affiliated Payment Token.
PDOL Processing options Data Object List A list of data sent to the card for it to use when processing the transaction.
SDA Static Data Authentication Allows the card to be authenticated when in offline mode using fixed data.
SDAD Signed Dynamic Application Data A digital signature on the data used for DDA, or SDA.
Track 2 User’s account information on the card The location of the user’s data on the card.
TRID Token Requestor ID ID which uniquely identifies the pairing of Token Requester with the Token Service Provider.
TRM Terminal Risk Management The processes carried out on the terminal to protect from fraud.
TTQ Terminal Transaction Qualifier Data fixed on the terminal detailing its abilities and requirements.
TVR Terminal Verification Results This 5 byte result contains flags that show the result of the different processing functions that have
been carried out as part of the transaction.
UN Unpredictable Number A nonce used as part of a transaction. Both the terminal and the card may generate and use nonces.

TABLE V
EMV DATA DIFFERENCES BETWEEN BASIN ET. AL . MODELS AND MODELS PRESENTED IN THIS PAPER .

EMV data Basin et. al. [2] Our models Comments

IAD Format 0/1/3 Format 4 IAD format is given by the IAD length (1st byte) and, for Format 2 & 4, the left nibble
of the CVN (2nd byte); cross-checking IAD with transaction amount would prevent
limit-bypass attack presented in [2].
CVR (part of IAD) 7 3 Format 4 contains a CDCVM bit; checking this would prevent limit-bypass attack
presented in [2].
MCC 7 3 Sent to payment network, even if not present in transaction APDUs; cross-checking
MCC with IAD would prevent limit-bypass attacks.