Card Brand Mixup Attack: Bypassing the PIN in

non-Visa Cards by Using Them for Visa Transactions

David Basin, Ralf Sasse, and Jorge Toro-Pozo

Department of Computer Science
ETH Zurich

Abstract Terminal Acquirer Payment Network Card Issuer

Most EMV transactions require online authorization by the

card issuer. Namely, the merchant’s payment terminal sends
an authorization request to the card issuer over a payment
network, typically operated by the company that brands the
card such as Visa or Mastercard. In this paper we show that Figure 1: Communication flow for online transaction autho-
it is possible to induce a mismatch between the card brand rization. Upper and lower arrows represent the authorization
and the payment network, from the terminal’s perspective. request and response, respectively.
The resulting card brand mixup attack has serious security
consequences. In particular, it enables criminals to use a vic-
tim’s Mastercard contactless card to pay for expensive goods that the MAC is correct. While these checks offer cryptograph-
without knowing the card’s PIN. Concretely, the attacker fools ically verifiable guarantees to cardholders and merchants, one
the terminal into believing that the card being used is a Visa must understand the properties of the payment system as a
card and then applies the recent PIN bypass attack that we whole, including the process by which terminals and issuers
reported on Visa. We have built an Android application and exchange requests and responses.
successfully used it to carry out this attack for transactions Figure 1 displays the communication flow of the online
with both Mastercard debit and credit cards, including a trans- authorization process, involving four parties: (1) the payment
action for over 400 USD with a Maestro debit card. Finally, terminal; (2) the merchant’s acquirer, which is a bank or fi-
we extend our formal model of the EMV contactless protocol nancial institution that processes card payments on behalf of
to machine-check fixes to the issues found. the merchant; (3) the payment network, which connects the
acquirer and the card issuer; and (4) the issuer itself. There are
several payment networks, such as the Visa or Mastercard net-
1 Introduction works, and the mechanism by which the acquirer chooses the
one which the authorization request is sent to is called routing.
There are more than 3.3 billion Visa credit and debit cards Typically, routing is based on the payment card’s brand. For
in circulation worldwide [23]. Under the Mastercard brand example, if the card is Visa branded, then the authorization
(excluding Maestro and Cirrus products) there are over 2 bil- request is routed to the Visa payment network.
lion cards [22]. These two companies, together with Europay, The payment terminal can determine the card brand from
are the founders of EMV, the de facto protocol standard for different data objects supplied by the card during the trans-
in-store smartcard payments. Other companies like American action. These objects include the Primary Account Number
Express, JCB, Discover, and UnionPay have also joined the (PAN) and the Application Identifiers (AID). From the PAN,
EMV consortium. more commonly known as the card number, the card brand
EMV transactions for high amounts require online autho- can be inferred from the leading digits. For example, if the
rization from the card issuer. For this, the payment terminal PAN starts with 4 then it is a Visa card. From the AIDs, which
sends an authorization request to the card issuer, carrying indicate the EMV applications that the card supports (e.g.,
transaction details and a cryptographic Message Authentica- Visa Electron or V Pay), the card brand can be inferred from
tion Code (MAC) computed by the card over these details. the shared prefix, called the Registered Application Provider
Upon reception, the card issuer performs various checks, in- Identifier, which is usually a 10-digit value (5 bytes).
cluding that the associated account has sufficient funds and In this paper we show that it is possible to deceive a termi-
nal, and by extension the acquirer, into accepting contactless sumably verified. This is known as the liability shift in the
transactions with a PAN and an AID that indicate different banking industry.
card brands. Concretely, we have identified a man-in-the- Finally, we analyze fixes that prevent both the card mixup
middle attack that tricks the terminal into completing a Visa and the PIN bypass attack. Namely, we extend our previous
transaction with a Mastercard card. formal models and provide computer-checked security proofs
Our attack, which we call a card brand mixup, has catas- for these fixes.
trophic consequences. In particular, it allows criminals to use
a victim’s Mastercard card to pay for expensive goods without
Organization. In Section 2 we provide technical back-
entering a PIN. The attack effectively turns the card into a
ground on our previous PIN bypass on Visa cards, which
Visa card and then applies our recent PIN bypass attack [6].
we leverage for our new attack, and the EMV contactless
In other words, the PIN can be bypassed for Mastercard cards
protocol. We then describe our card brand mixup attack and
too, which so far had been considered protected against unau-
the resulting PIN bypass in Section 3. We also report on our
thorized purchases for amounts that require the entry of the
proof-of-concept implementation and the results of our exper-
card owner’s secret PIN.
iments. In Section 4 we analyze and verify countermeasures
This new attack abuses two fundamental shortcomings of
that secure online-authorized transactions. In Section 5 we
the EMV contactless protocol: (1) the lack of authentication
elaborate on previous work that exposes and exploits flaws
of the card brand to the terminal, and (2) an attacker can
on the EMV standard and we draw conclusions in Section 6.
build all necessary responses specified by the Visa protocol
from the ones obtained from a non-Visa card, including the
cryptographic proofs needed for the card issuer to authorize Ethics and Disclosure. No merchant, bank, or any other
the transaction. entity was defrauded. To test our attack, we setup and used
We have built a proof-of-concept Android application and our own SumUp terminal and merchant account. Note that,
successfully used it to bypass PIN verification for transactions although the merchant infrastructure we used was our own, it
with Mastercard credit and debit cards, including two Maestro is a fully realistic and functional one. We did not tamper with
debit and two Mastercard credit cards, all issued by different the hardware or software in any way.
banks. One of these transactions was for over 400 USD. After a successful disclosure process with Mastercard, they
We have extended our formal model of the EMV protocol, confirmed that our attack is effective. Mastercard identified
first presented in [6]. Concretely, we generalize its specifica- all 9 transactions that were routed to their network when we
tion of the issuer and the terminal-issuer channel to model carried out our Mastercard-Visa mixup attack. Mastercard
communication between the terminal and the issuer, even has since implemented and rolled out defense mechanisms
when they do not agree on the brand of the payment card on their network and, in collaboration with Mastercard, we
used. Our extended model, available at [3] and specified in have conducted experiments where our attack failed with their
the Tamarin model checker [26, 28], is precise enough that mechanisms in place. Further details are given in Section 4.4.
its analysis uncovers the attack described here. We have also
used our extended model to construct security proofs for two
sets of fixes. The first set is the one we proposed in [6], which 2 Background
is specific to the Visa kernel. The second set of fixes, first
presented in this paper, prevents card brand mixups in general We first provide background on contactless payments and
and applies to all EMV kernels. common attacks against them. We briefly recall our previ-
ous work [6], which we build upon. Afterwards, we provide
Contributions. First, by carefully analyzing the EMV pro- technical details on the EMV contactless transaction.
tocol with a focus on the terminal-issuer interaction, we dis-
cover a novel attack that allows criminals to trick the terminal 2.1 Relay Attacks and PIN Bypass for Visa
into believing that the card being used is of a brand that it is
not. Surprisingly, this is possible even for transactions autho- Despite the undeniably smooth experience of a payment with
rized online by the card issuer, who clearly does know the the tap of a card, contactless payment technology has been
right card brand. exposed to numerous security issues. Payment terminals com-
Second, we demonstrate that this card brand mixup is not municate wirelessly with the cards, and so can attackers. In
just a mere disagreement between the card issuer and the particular, Near Field Communication (NFC), which is the
terminal, but that it has serious consequences. In particular, communication technology that contactless payments use, al-
the PIN does not protect Mastercard cardholders from lost lows any suitable NFC-enabled device to communicate with
or stolen cards being used in fraudulent purchases for large a contactless card and engage in fraudulent transactions.
amounts. Consequently, the consumer should not be liable While the range of an NFC signal is normally just a few
for fraudulent transactions in which the cardholder was pre- centimeters, it can be extended to a much larger range by
 selection process, where the terminal issues a SELECT com-
mand and the card submits the Application Identifiers (AIDs)
WiFi for the supported applications (a.k.a. kernels or protocols).
Based on the AIDs received, the terminal activates a kernel
for the transaction, which is one of:
NFC WiFi NFC

• Kernel 2 for Mastercard AIDs,

Figure 2: A relay attack on contactless payment. Devices • Kernel 3 for Visa AIDs,
from left to right: payment terminal, attacker’s first mobile
device, attacker’s second mobile device, and victim’s card. • Kernel 4 for American Express AIDs,
• Kernel 5 for JCB AIDs,
relay attacks [7, 8, 11, 19, 30]. A relay attacker uses two mo-
• Kernel 6 for Discover AIDs, and
bile devices, connected wirelessly, to make the victim’s card
engage in a transaction with a distant payment terminal. See • Kernel 7 for UnionPay AIDs.
Figure 2 for a graphical representation.
Relay attacks, however, do not appear lucrative for crimi- The most relevant kernel for our work is Mastercard’s, which
nals because they are presumably feasible only for purchases we outline in Figure 3 and is specified in the 590-page docu-
for low amounts (e.g., under 25 EUR in most European coun- ment [16].
tries), due to the need for the card’s PIN for transactions with
higher amounts. However, in our previous work, we discov- 2.2.2 Offline Data Authentication
ered a man-in-the-middle attack that allows criminals not
After a kernel has been activated and announced to the card
only to perform relay attacks but also to bypass the PIN for
via a second SELECT command, the card requests the Pro-
contactless transactions with Visa cards.1
cessing Data Object List (PDOL), which indicates some of
At a technical level, this attack consists simply in setting the the transaction-specific data objects needed by the card for
Card Transaction Qualifiers (CTQ) to the value 0x0280. The the protocol. These data objects include, but are not limited
CTQ is a data object transmitted from the card to the terminal to, the transaction amount, the terminal’s country code, and a
and instructs the latter which Cardholder Verification Method terminal-generated random number.
(CVM) must be used for the transaction. The CTQ value Using the GET PROCESSING OPTIONS command, the
0x0280 tells the terminal that PIN verification is not required terminal supplies the requested PDOL data to the card. The
and that the cardholder has been verified on the consumer’s latter responds with the Application Interchange Profile (AIP)
device (see [17], pp. 69–70). The flaw in the Visa protocol and the Application File Locator (AFL). The AIP informs
that leads to this attack is the lack of authentication of the the terminal of the card’s capabilities and the AFL is a data
CTQ data object. object that the terminal uses to request the card’s static data
This attack does not apply to the Mastercard protocol be- (also known as records) using the READ RECORD command.
cause, in contrast to the Visa protocol, the card’s (lack of) sup- These records include:
port for cardholder verification on the consumer’s device is
cryptographically protected against modification. A computer- • Primary Data such as the card number (called the Pri-
checked proof of this can be found at [4]. mary Account Number), the card’s expiration date, and
the list of the supported CVMs;
2.2 The EMV Contactless Protocol • PKI Data such as the card’s Public Key (PK) certificate,
EMV’s specification for contactless transactions comprises the card issuer’s PK certificate, and the PK index of the
over 1,200 pages of documentation. In this section we sum- Certificate Authority (CA);
marize this specification. We split our summary into the four • Processing and Risk Data such as the first and sec-
overlapping phases of a contactless transaction and briefly ond Card Risk Management Data Object Lists (CDOL1
indicate, where applicable, the underlying security shortcom- and CDOL2, respectively), which typically include the
ings that our attack exploits. PDOL and further transaction-specific data.

At this point, the terminal cryptographically authenticates

2.2.1 Application Selection
the card. This process is called Offline Data Authentication
A transaction is performed using one of the six EMV contact- (ODA) and uses one of the three methods:
less protocols. Every transaction starts with the application
1. Static Data Authentication (SDA): the card transmits
1 Demo at [Link] a signature by the card issuer on the card’s static data
 Issuer Terminal Card

s = f (mk, ATC) random UN s = f (mk, ATC)

random NC

SELECT, [Link].DDF01

AIDMastercard , AIDMaestro, . . .
Application Selection SELECT, AIDx

tags & lengths of PDOL

GET PROCESSING OPTIONS, PDOL

AIP, AFL

READ RECORD, AFL

PAN,expDate,...,certprivCA (I,pubI),
certprivI (PAN,pubC,CVM list,AIP),
tags & lengths of CDOLs,CVM list

Offline Data Authentication GENERATE AC, CDOL1

Transaction Authorization starts
X = (PDOL, CDOL1)
AC = MACs (X, AIP, ATC, IAD)
T = h(X, CID, ATC, AC, IAD)
SDAD = signprivC (NC, CID, AC, [T, ]UN)

PAN,AIP,X,ATC,IAD, CID, ATC, SDAD, IAD

AC [,aencpubI (PIN)]

Y = AC ⊕ p8(ARC)
ARPC = MAC′s (Y )
ARC, ARPC

Figure 3: Overview of the Mastercard contactless transaction using the most common card authentication method, called
Combined Dynamic Data Authentication (CDA). There are other two authentication methods, which we omit here for sim-
plicity. Notation: ⊕ is exclusive-OR; f is a key derivation function; (privC, pubC), (privI, pubI), and (privCA, pubCA) are the
private/public key pairs of the card, the issuer, and the Certificate Authority, respectively; certk (cont) is the PKI certificate on
cont signed with the private key k; signk (m) is the signature on m with the key k; aenck (m) is the asymmetric encryption of m
with the key k; MACk (m) and MAC0k (m) are cipher-based Message Authentication Codes (MAC) on m with the key k; pb (m)
is the right-padding of m with b zero bytes. Note that there is some overlap between the Offline Data Authentication and the
Transaction Authorization phases. This occurs when the terminal and the card agree on using the Combined Dynamic Data
Authentication (CDA) method. For the sake of simplicity, we have omitted the middle entities (acquirer and payment network)
that participate in the terminal-issuer exchanges before they reach their recipient.
 such as the Primary Account Number (PAN), the card’s Notably relevant for our previous PIN bypass attack, and
expiration date, and the AIP. This signature, called the therefore this new attack, is the Consumer Device CVM (CD-
Signed Static Authentication Data (SSAD), is generated CVM). With respect to how and whether the CDCVM is used,
and stored on the card during production. the kernels can be divided into two groups:
2. Dynamic Data Authentication (DDA): in this method The Visa group composed of the Visa, Discover, and Union-
the terminal sends the INTERNAL AUTHENTICATE Pay kernels, where the card’s support for the CDCVM is
command with the Dynamic Data Object List (DDOL) announced to the terminal through the cryptographically
as payload. The DDOL is a data object that must include unprotected CTQ or similar data object, depending on
the terminal’s fresh number, called the Unpredictable the specific kernel.
Number (UN). The card replies with the Signed Dynamic
Authentication Data (SDAD): a signature on its own The Mastercard group composed of the Mastercard, Amer-
fresh number NC and the DDOL. ican Express, and JCB kernels, where the card’s support
for the CDCVM is announced to the terminal through the
3. Combined Dynamic Data Authentication (CDA): this cryptographically protected AIP and possibly additional
method also involves the SDAD, but includes additional data objects, depending on the specific kernel.
transaction data in the signature such as the amount. No
Our previous PIN bypass attack targets the cards within
INTERNAL AUTHENTICATE command is used and
the Visa group, which is weaker than the Mastercard group
instead the SDAD is later supplied by the card, if re-
in terms of the protection it offers. While the CDCVM is not
quested by the terminal’s GENERATE AC command.
meant for physical cards, attackers can abuse it by tricking
This ODA method actually belongs, chronologically
the terminal into accepting this CVM for a purchase with a
speaking, to another phase of the transaction, called the
victim’s physical card. The key point here is that, whenever
Transaction Authorization, which we describe later in
an attacker convinces the terminal that the CDCVM was suc-
Section 2.2.4.
cessfully performed, the latter wrongfully assumes that the
The ODA method chosen is typically the last one (which is actual verification was delegated to an external device and
also the strongest one) in the above list that both the terminal thus does not ask for the PIN. This is the essence of the flaw
and the card support. The ODA methods that the card supports that our previous attack exploits.
are encoded within the AIP. Our new attack also exploits the Consumer Device CVM,
but in combination with a flaw on EMV’s application selec-
2.2.3 Cardholder Verification tion. This attack thereby targets the cards within the presum-
ably better protected Mastercard group.
The Cardholder Verification Methods (CVMs) are as follows:
1. Online PIN: the terminal sends to the card issuer the 2.2.4 Transaction Authorization
encryption of the PIN entered on the terminal’s pad for
verification. Transaction authorization is implemented by having the card
compute and transmit the Application Cryptogram (AC). This
2. Consumer Device CVM: the cardholder verification is is a MAC-based cryptographic proof of the transaction, com-
performed on the consumer’s device. This method is puted over the transaction details, the AIP, and the Application
intended primarily for use with mobile payment apps Transaction Counter (ATC, which is incremented on every
such as Google Pay and Apple Pay, where the cardholder transaction). Besides the AC and additional data that depends
is verified through biometrics such as fingerprint or face on the kernel, the card transmits:
recognition.
• the Cryptogram Information Data (CID), which encodes
3. Paper Signature: the cardholder signs (with a pen) the the type of authorization being requested;
purchase receipt and the cashier checks it against the
physical signature on the card’s backside. • the Application Transaction Counter (ATC);

If applicable, typically when the amount is above the CVM- • the Signed Dynamic Authentication Data (SDAD), if
required limit, the terminal verifies the cardholder by choosing CDA was requested in the command payload; and
one (or two) of the above three methods. The choice depends
• the Issuer Application Data (IAD), which contains pro-
on the card’s list of supported CVMs, if supplied by the card.
prietary application data that is transmitted to the issuer.
If this CVM list is not supplied (e.g., in Visa transactions),
then the terminal proposes online PIN verification, and this The computation by the card (and verification by the issuer)
proposal is encoded within the Terminal Transaction Quali- of the AC uses a session key s, which is derived from the ATC
fiers (TTQ) or a similar data object, depending on the kernel. and a symmetric key mk only known to the issuer and the
The TTQ is typically part of the PDOL. card. The terminal therefore cannot verify the AC.
 A transaction can be authorized offline by the terminal, 2. The attacker has the capabilities of an active (so-called
sent online for authorization by the issuer, or declined offline Dolev-Yao) attacker over the wireless channel between
by the card. The choice depends on factors including checks cards and terminals. Namely, the attacker can read, block,
made by both the terminal and the card on transaction details and inject messages on this channel.
such as the amount, the currency (transaction versus card’s),
the country (transaction versus issuer’s), and the limit number 3. The channel between the payment terminal and the bank-
of consecutive offline transactions. The most common type ing infrastructure is secure in that it satisfies authenticity
of transaction authorization is online by the issuer. and confidentiality.
For transactions performed with the kernels within the
This models is realistic in practice. The attacker may ac-
Visa group, the AC is sent within the card’s response
cess a victim’s card that is lost or stolen. Indeed, in practice
to the GET PROCESSING OPTIONS. Typically, no Of-
it may suffice simply to be physically close (within a few
fline Data Authentication process is performed and no
centimeters) to the victim’s card. Moreover, as we will see in
GENERATE AC command is used. For those kernels within
Section 3.3, using standard NFC-enabled smart phones one
the Mastercard group, the AC is transmitted in response to
can carry out active man-in-the-middle attacks on the wireless
the GENERATE AC command.
channel.
If the transaction is to be authorized online by the issuer,
then the AC is called the Authorization Request Cryptogram
(ARQC) and the CID equals 0x80. The actual authorization 3.2 Description of the Attack
follows from a request-response exchange between the termi-
As stated in [6, 21], the PIN verification cannot be bypassed
nal and the issuer. The terminal’s request carries the ARQC
for transactions where the payment terminal executes the
and the issuer’s response is encoded in the Authorization Re-
Mastercard kernel (recall Figure 3). According to this kernel’s
sponse Code (ARC). This exchange is not further specified
specification [16], the AIP (specifically bit 2 of byte 1) is the
by EMV.
only data object that indicates the card’s support for on-device
If the transaction is to be accepted offline by the terminal,
cardholder verification. Thus, modifying the AIP would lead
then the AC is called the Transaction Cryptogram (TC) and
to a declined transaction given that it is authenticated using
the CID equals 0x40 in this case. Also, the terminal is as-
the card’s PK certificate, the Application Cryptogram (AC),
sumed to have already validated the transaction in the Offline
and the Signed Dynamic Authentication Data (SDAD). We
Data Authentication phase. The transaction can be also de-
have validated this with several cards.
clined offline, in which case the AC is called the Application
Unlike the AIP, the card’s Application Identifiers (AIDs)
Authentication Cryptogram (AAC) and the CID equals 0x00.
are not protected. In fact, the AIDs are only used during
Note that the AIDs are not authenticated by the card to the the SELECT command exchanges. After these exchanges
terminal. That is, the terminal has no cryptographic proof that are completed, the terminal activates the corresponding ker-
the card supports the AIDs it advertised during the application nel based on the AIDs received from the card. For example,
selection phase. This turns out to be the new, fundamental if the preferred AID (or first, depending on the terminal’s
security shortcoming that our attack exploits. Also note that selection method) is AIDVisa = 0xA0000000031010, then
EMV does not specify any mechanisms to match up the card’s the terminal activates the Visa kernel. If the AID is instead
PAN with the advertised AIDs. AIDMastercard = 0xA0000000041010, then the terminal acti-
vates the Mastercard kernel.
Due to this lack of authentication of the AIDs, an attacker
3 PIN Bypass via Card Brand Mixup
can maliciously replace them and thereby activate a desired
We describe our attack in detail here. We start in Section 3.1 kernel on the terminal. This is the fundamental security short-
by describing the threat model considered for this attack. We coming that our attack exploits. An overview of the attack is
next give a step-by-step description in Section 3.2. After- displayed in Figure 4 and a step-by-step description follows.
wards, in Section 3.3 we outline the hardware and software
1. Activation of the Visa Kernel: The terminal first acti-
infrastructure we used in our proof-of-concept implementa-
vates the Visa kernel. For this, the attacker applies the
tion and present the results of our experiments.
trick just described, namely the replacement of the card’s
legitimate AIDs with AIDVisa .
3.1 Threat Model
2. Request Processing Options: After the AID is negotiated,
The threat model considered for this attack and for our formal the attacker receives from the card the request (i.e., tags
analysis described in Section 4 is as follows: and lengths) for the Processing Data Object List (PDOL).
The attacker forwards this request to the terminal with
1. The attacker has access to the victim’s card. the addition of the request for the Terminal Transaction
 Terminal Attacker Card

random UN s = f (mk, ATC), random NC

SELECT, [Link].DDF01 SELECT, [Link].DDF01

AIDVisa AIDMastercard , AIDMaestro, . . .

SELECT, AIDVisa SELECT, AIDMastercard

tags & lengths of PDOLVisa tags & lengths of PDOLMastercard

PDOLVisa =hTTQ,amount,country,TVR,
currency,date,type,UN,... i

GET PROCESSING OPTIONS, PDOLVisa

build PDOLMastercard from PDOLVisa

GET PROCESSING OPTIONS, PDOLMastercard

AIP, AFLMastercard

READ RECORD, AFLMastercard

PAN,expDate,...,certprivCA (I,pubI),
certprivI (PAN,pubC,CVM list,AIP),
tags & lengths of CDOLs,CVM list

build CDOL1 from PDOLVisa

GENERATE AC, CDOL1

X = (PDOLMastercard , CDOL1)
CID = 0x80
AC = MACs (X, AIP, ATC, IAD)
T = h(X, CID, ATC, AC, IAD)
SDAD = signprivC (NC, CID, AC, [T, ]UN)

CID, ATC, SDAD, IAD

extract AC from SDAD

CTQ = 0x0280
AFLVisa = 0x18010100

AIP, AFLVisa, IAD, AC, CID, ATC, CTQ

READ RECORD

PAN, expDate, AUC, issuerCountry

Figure 4: Overview of our PIN bypass attack for Mastercard, exploiting the card brand mixup. The attacker poses as (a) a card to
the payment terminal and runs a Visa session with it, and (b) a payment terminal to the card with which it runs a Mastercard
session. For simplicity, we have omitted the messages between the terminal and the issuer, which are the same as in Figure 3 but
without the PIN block.
 Qualifiers (TTQ) and all other processing data objects 4. PIN Bypass: At this point, our PIN bypass attack on Visa
specified by the Visa kernel. The attacker’s request also is applied. That is, the attacker injects a CTQ data object
includes the data objects referenced by the First Card valued 0x0280, which instructs the terminal that online
Risk Management Data Object List (CDOL1) specified PIN verification is not required and that the Consumer
by the Mastercard kernel, which usually are the Termi- Device CVM was performed (see [17], pp. 69–70).
nal Type (TT) and the Cardholder Verification Method Together with the CTQ, the attacker supplies the AIP, an
Results (CVMR). artificial AFL with value 0x18010100, the AC, the IAD,
and all other data objects specified by the Visa kernel.
3. Run the Mastercard Session: Once the attacker has re-
ceived the GET PROCESSING OPTIONS from the ter- 5. Transmit Records: In response to the terminal’s
minal, the attacker runs a Mastercard session with the READ RECORD command, which is 0x00B2011C00
card. The terminal is not involved during this step. The due to the artificial AFL, the attacker replies with the
sub-steps are as follows. PAN, the expiration date, the Application Usage Control
(AUC), and the issuer country.
(a) The attacker builds and sends to the card the
GET PROCESSING OPTIONS command along
with the card’s requested PDOL data, which is 3.3 Carrying out the Attack
filled up from the terminal’s command payload.
To demonstrate our PIN bypass attack, we developed a proof-
The card responds to the attacker’s command with
of-concept Android application, comprising roughly 3,700
the Application Interchange Profile (AIP) and the
lines of Java code. On the merchant side, we used the pay-
Application File Locator (AFL).
ment kit commercialized by SumUp: an EMV and PCI DSS
(b) The attacker proceeds to read the card’s records, (Payment Card Industry Data Security Standard) certified
using the received AFL. The relevant records col- company licensed under the UK’s Financial Conduct Author-
lected are the PAN, the card’s expiration date, the ity. The kit costs about 50 USD and includes a card reader,
issuer country code, the Application Usage Control, which works with both contact and contactless cards, and a
and the CDOL1 tags and lengths. back-end mobile application available for iOS and Android
(c) The attacker builds and sends to the card devices. The SumUp card reader is PCI PTS (Payment Card
the GENERATE AC command, whose payload Industry PIN Transaction Security) certified. Figure 5 dis-
is the CDOL1 data filled up with the PDOL plays the components of our testing environment.
data parsed from the payload of terminal’s Our attack is implemented using two Android phones, con-
GET PROCESSING OPTIONS command. The nected through a relay channel built using TCP/IP server-
CDOL1 typically is a superset of the PDOL. If client communication over WiFi. One phone runs our app
the card supports CDA (i.e., bit 1 of byte 1 of the in POS Emulator mode (Device 4 in Figure 5) and the other
AIP is set), then the command should request CDA. phone runs our app in Card Emulator mode (Device 3 in Fig-
Also, the bits 7 and 8 of the command’s reference ure 5). Both devices must support NFC and run Android 4.4
control parameter (i.e., byte 3) must be cleared and KitKat (API level 19) or later. Moreover, the Card Emulator
set, respectively. This tells the card that an ARQC device must support Android’s host-based card emulation [2]
is being requested (see [15], pp. 54–55). so that the phone can launch the NFC payment service imple-
mented by our app. The actual man-in-the-middle function-
(d) From the card’s response to the GENERATE AC ality runs on the POS Emulator device (although this choice
command, the attacker collects the CID, the ATC, is irrelevant) and the Card Emulator acts as the proxy for the
the IAD, and the AC or SDAD, depending on relay channel.
whether CDA was requested. If the SDAD is sent, Using our app, we successfully bypassed PIN entry for
then the attacker must extract the AC, using the transactions with four different cards: two Mastercard credit
card’s Public Key (PK) (see [14], pp. 68–69). cards and two Maestro debit cards. A video demonstration of
Using the received card’s records, the attacker re- the attack and other information can be found at [1].
trieves the card’s PK using the following steps The results of our experiments are summarized in Table 1.
(see [14], pp. 60–65): Some of these transactions were performed with the Google
i. retrieve the CA’s PK from the CA’s index, Pay and Apple Pay apps using non-Visa cards. Such trans-
actions do not require PIN verification and thus no bypass
ii. retrieve the issuer’s PK from the issuer’s PK is needed, yet they showcase unauthentic uses of the Visa
certificate, using the CA’s PK, and kernel.
iii. retrieve the card’s PK from the card’s PK cer- Critical here is that the transactions in Table 1 were all au-
tificate, using the issuer’s PK. thorized online by the issuer. Moreover, this was without any
 Amount Processed with Bypassed
Brand Card
(CHF) the Visa kernel PIN
Visa Credit 200 NA Yes
Visa Visa Debit 100 NA Yes
V Pay 100 NA Yes
Maestro(1) 400 Yes Yes
Maestro(1) on Google Pay 1 Yes NA
Maestro(1) on Apple Pay 1 Yes NA
Maestro(2) 200 Yes Yes
Mastercard
Mastercard Debit(3)(∗) 10 Yes NA
Mastercard Debit(3) on Google Pay 1 Yes NA
Mastercard Debit(3) on Apple Pay 1 Yes NA
Mastercard Credit(4) 100 Yes Yes
Mastercard Credit(5) 100 Yes Yes
Legend:
NA: not applicable (1) to (5): each of the five different physical cards we tested
(∗): card for which we unsuccessfully attempted our PIN bypass for a 100 CHF transaction but
the terminal requested to insert the card to complete the transaction using the contact chip instead

Table 1: Summary of the transactions during our experiments. All of these transactions were authorized online and were
subsequently debited from the cardholder’s account and credited to the merchant’s account. For some cards, we performed
multiple transactions and we show here the one with the highest value.

adversarial intervention beyond the terminal-card interaction which can be purchased for under 300 USD. This represents
and despite the different views between the terminal and the a one-time investment for the criminals, and might even be
issuer on the AID selected for the transaction. The EMV pro- unnecessary when they can use their own phones. In addi-
tocol does not unambiguously specify what transaction data tion, the use of this hardware is inconspicuous since only one
is sent to the issuer for authorization. Clearly, since our attack phone need be visible during payment and it easily escapes
is possible, the AID and any other kernel-identifying data is detection by store clerks since our app’s appearance is very
either not sent, or not checked by the issuer. We cannot how- similar to legitimate payment apps such as Google Pay and
ever confirm that this is the case for all EMV implementations Apple Pay.
in terminals. For our attack to work, clearly the authorization request
Our card brand mixup suggests that merchants (in particu- must reach the card issuer. For this, it is necessary that the
lar, their terminals) accepting Visa cards can also be fooled merchant’s acquirer routes the request to either:
into accepting other EMV card brands, like Mastercard, even
if they would not normally accept them. This could result in • a payment network that matches the real card brand,
violations of contracts, market regulations, sanctions, embar- regardless of what the terminal thinks the brand is, or
goes, and credit card fees. Note that our attack could even be
done in collusion with the merchant to evade taxes or fees. An- • a payment network that handles transactions with cards
other scenario where criminals might exploit our card brand of different brands, including Mastercard and Visa.
mixup attack is the following. They might perform a high- It is likely that the SumUp acquirer employs the first ap-
value transaction with their own Mastercard-branded card proach. The second approach is enforced by legal means in
turned into a Visa and then request reimbursement, claiming some countries, making the scope of our card brand mixup
a terminal malfunction or fraud based on the fact that they do attack very broad. For example, in the US, the 2010 federal
not own a Visa card. To support their claim, on the purchase law known as the Durbin Amendment [10] legislates that all
receipt both the ‘Visa’ label and the Visa AID will be printed, domestic debit transactions must be given the choice, if so
which looks suspicious under scrutiny. opted by the merchant, the cardholder, or the card (through
the AIDs), to be routed to a common payment network,
Usability and Scope. Our attack requires minimal hard- called the US Common Debit Network. This network for-
ware to carry out, namely two NFC-enabled Android phones, wards authorization requests to the card issuer, regardless of
 minals, including two by SIX.2 From our disclosure process
with Mastercard we learned that none of these transactions
were routed to the Mastercard network, and so the SIX ac-
quirer presumably routed the authorization requests to the
Visa payment network, which flagged the card as non-Visa
and declined the transaction.
Clearly the EMV standard should specify an unambiguous,
cryptographic mechanism to detect and avoid mismatches
between the AID and the PAN, in terms of the card brand they
advertise. In the next section we analyze countermeasures
that achieve this.

4 Countermeasures
This section discusses countermeasures to our card brand
mixup attack. After reviewing our previous EMV model and
Figure 5: Setup of the testing environment for our proof-of- our new extensions (Sections 4.1 and 4.2 respectively), we
concept implementation, displaying the following devices: present both formally-verified countermeasures at the kernel
(1) SumUp Plus Card Reader, (2) mobile phone running the level (Section 4.3) and countermeasures already implemented
SumUp app and connected over Bluetooth to the SumUp at the network level by Mastercard (Section 4.4).
reader, (3) Android phone running our app in Card Emulator
mode, (4) Android phone running our app in POS Emulator 4.1 Previous EMV Model
mode, and (5) contactless card. Note that the device (2) is not
part of the attacker’s equipment since in an actual store this To design and verify kernel-level countermeasures to our
device and (1) would be the payment terminal. In this scenario, attack, we extend our previous model [4] of the EMV con-
the devices (3) and (4) would be the attacker’s equipment and tactless protocol. We developed this model focusing on the
(5) would be the victim’s card. following three security properties:
1. The issuer accepts all transactions accepted by the ter-
minal.
the card brand. Thus, if the victim’s card is a Mastercard-
branded debit card issued in the US and the merchant is 2. All accepted transactions are authenticated to the ter-
also in the US, our attack should be effective by using the minal by the card and, if authorized online, the issuer.
Visa US Common Debit AID 0xA0000000980840 instead of
AIDVisa = 0xA0000000031010 during the application selec- 3. All accepted transactions are authenticated to the is-
tion phase. This replacement would also deceive the terminal suer by both the card and the terminal.
into running the flawed Visa kernel. The first property expresses a causality of accept and de-
Other countries like Australia and New Zealand are also cline events: whenever the terminal accepts a transaction, so
pushing for similar approaches for routing debit transactions will the issuer (or equivalently, the issuer will not decline
to local payment networks as opposed to global ones. The it). For the authentication properties, we use injective agree-
Electronic Funds Transfer at Point of Sale (EFTPOS) system ment [9, 25]. In short, an agreement property validates that
is an example of such an initiative in these countries. whenever the agent, whom the transaction must be authen-
ticated to, reaches a state where the transaction is accepted,
then that agent observes the same transaction details as the
Unsuccessful Attempts. We attempted to execute our at- authenticating agent does. The transaction details to agree on
tack to pay with a Mastercard card in a Discover and a Union- for the properties are: the PAN, the AIP, the CVM, the ATC,
Pay transaction, as these two kernels are similar to the Visa the AC data input (i.e., X in Figure 3), the AC itself, and the
kernel. We did not succeed in either case. In these tests, we IAD.
observed that the terminal did not pass the selection phase We specify a generic model of the EMV contactless proto-
and requested us to insert the card or to try with another card. col that allows for the analysis of transactions performed with
This suggests that the usage of cards of these brands over the Visa and Mastercard kernels. The remaining four kernels
the contactless interface might be restricted in Switzerland, can be modeled by one of these, which is their group repre-
where we carried out our experiments. sentative as per the two groups introduced in Section 2.2.3.
We have performed additional tests on other payment ter- 2 [Link]
 Parameter Possible values Comments mined by the kernel used by the terminal. We have extended
our previous model with a more general model of routing,
- Mastercard Brand of where the terminal routes the authorization to the payment
Brand
- Visa the card used network determined by the card’s PAN. The employed mod-
Strongest ODA - SDA Mastercard eling techniques are standard ones, but we generalized the
method supported - DDA cards formalization of our previous model to consider this PAN-
by the card - CDA only based routing choice.
In Table 3 we summarize the results of our analysis, con-
- DDA Visa cards
Processing mode ducted using our extended model. All target models have
- EMV only
56 Tamarin rules and about 800 lines of code on average.
Strongest - No PIN Mastercard Remarks 1 and 2 in the table indicate authentication issues,
CVM supported - Online PIN cards which were first identified by the original model (see [6],
by the card only Table 2, p. 11).
- Low Whether CVM Remarks 3 and 4 indicate the newly discovered lack of
Transaction value authentication of the AID and the CVM used in the EMV
- High is required
contactless transaction. This is the underlying flaw that leads
Table 2: Parameters that define target configurations. to our card brand mixup attack. For each of the affected target
models, our Tamarin analysis reveals an accepted transaction
where the following statements hold:
Our analysis methodology, which we used in both our pre-
• the card used was a Mastercard,
vious work and the current work, is structured by target con-
figurations. A target configuration is a choice of up to four • the terminal ran the transaction using the Visa kernel,
parameters (depending on the kernel) from Table 2. A target
model is derived from the EMV contactless protocol model • no cardholder verification was performed, and
and allows any execution of the latter while only assessing
the security of accepted transactions sharing the same target • if the transaction value was high, then the CDCVM was
configuration. successfully performed from the terminal’s perspective.
The use of multiple configurations enables one to focus We remark that our current findings do not contradict those
the security analysis on those transactions of interest, defined from our previous work. Our claim in [6] is that the Master-
by the corresponding choice of target configurations. For card protocol is secure, whereas in this paper we show that
example, one might be interested in whether authentication Mastercard cards are not secure. In fact, as we have explained,
to the terminal holds for high-value transactions performed our attack is possible precisely because one can use Master-
using the Mastercard kernel and cards supporting DDA as the card cards for transactions not performed with the Mastercard
Offline Data Authentication method and online PIN as the protocol!
Cardholder Verification Method. Further details can be found
at [4].
4.3 Verified Countermeasures
4.2 Extended Model with PAN-based Routing In [6], we proposed two fixes to the PIN bypass attack on
Visa. These fixes are:
Our previous model of the EMV contactless protocol speci-
fies the terminal-issuer channel in a way that these two par- 1. The terminal must always set the bit 1 of byte 1 of the
ties always agree on the kernel used for online-authorized Terminal Transaction Qualifiers (TTQ).
transactions. In other words, we assumed that the transaction 2. The terminal must always verify the Signed Dynamic
authorization request is routed to a payment network that only Authentication Data (SDAD).
processes cards of the brand determined by the kernel used (or
equivalently the AID chosen during the application selection The above fixes ensure that high-value transactions pro-
phase). For example, if the transaction was processed with cessed with the Visa kernel use Visa’s secure configuration
the Visa kernel, then the authorization request is routed to a (DDA on online authorizations), where the card is requested
network that handles Visa cards only. to supply the SDAD and the terminal verifies it. As can be
This modeling assumption means that Mastercard cards can observed in our results (Table 3, Line 4), we have verified that
only be used for transactions performed using the Mastercard this configuration, and by extension the two fixes listed above,
kernel. Clearly, our brand mixup attack demonstrates other- prevents one from turning a Mastercard card into a Visa
wise. That is, in some cases the authorization request reaches card. The fixes work because of the kernel-specific format
the card issuer, even when the card is not of the brand deter- of the data that cards sign to produce the SDAD. Namely,
 Properties
No. Target model
issuer accepts auth. to terminal auth. to issuer
1 Visa_EMV_Low_PaynetPAN X ×(1) ×(1)
2 Visa_EMV_High_PaynetPAN X ×(1) ×(1)
3 Visa_DDA_Low_PaynetPAN ×(2) ×(2) X
4 Visa_DDA_High_PaynetPAN X X X
5 Mastercard_SDA_OnlinePIN_Low_PaynetPAN ×(2) ×(2) ×(3)
6 Mastercard_SDA_OnlinePIN_High_PaynetPAN X X ×(3,4)
7 Mastercard_SDA_NoPIN_Low_PaynetPAN ×(2) ×(2) ×(3)
8 Mastercard_SDA_NoPIN_High_PaynetPAN – – –
9 Mastercard_DDA_OnlinePIN_Low_PaynetPAN ×(2) ×(2) ×(3)
10 Mastercard_DDA_OnlinePIN_High_PaynetPAN X X ×(3,4)
11 Mastercard_DDA_NoPIN_Low_PaynetPAN ×(2) ×(2) ×(3)
12 Mastercard_DDA_NoPIN_High_PaynetPAN – – –
13 Mastercard_CDA_OnlinePIN_Low_PaynetPAN X X ×(3)
14 Mastercard_CDA_OnlinePIN_High_PaynetPAN X X ×(3,4)
15 Mastercard_CDA_NoPIN_Low_PaynetPAN X X ×(3)
16 Mastercard_CDA_NoPIN_High_PaynetPAN – – –
Legend:
X: property verified ×: property falsified –: not applicable (1): disagrees with the card on the CVM
(2): disagrees with the card on the AC (3): disagrees with the terminal on the AID (4): disagrees with the card on the CVM

Table 3: Analysis results for the EMV contactless protocol where the authorization is routed to a payment network determined by
the brand indicated by the PAN. Each target model is named according to the corresponding target configuration.

the Visa protocol specifies that the input to the SDAD has pass attacks. Note that the second countermeasure will be
the header 0x95 for online authorizations (see [17], p. 128), costly as it requires reissuing cards.
whereas the Mastercard kernel specifies the usage of the 0x05
header (see [16], p. 310 and [14], p. 73). In other words, no
SDAD generated by a Mastercard card will pass the verifi-
4.4 Countermeasures by Mastercard
cation by a terminal running the Visa kernel for transactions We shared our countermeasures with Mastercard, as part of
requiring online authorization. the disclosure process, and learned from them the following:
Additionally, we propose the following novel EMV-wide
countermeasures that kernels can implement internally to 1. Mastercard acquirers are required to include the AID in
guarantee secure online-authorized transactions, without hav- the authorization data, allowing issuers to check the AID
ing to rely on Visa-specific countermeasures. against the PAN.

1. All transactions must have the card generate the SDAD 2. Mastercard has other data points in the authorization
and the terminal verify it. request that can be used to identify our attack.

2. The selected AID must be part of the input to the SDAD. As a result of the disclosure process and once Mastercard
learned that not all issuers check the AID or these other data
Our first countermeasure generalizes the two fixes we pro- points, they implemented these checks on their network. Our
posed in [6], listed earlier in this section. The second coun- interaction with Mastercard also provided us additional in-
termeasure defends precisely against the card brand mixup sights on how certain terminals, such as the ones from SIX,
attack that we have described in this paper. We have produced can detect a mismatching AID and PAN and thus decline the
machine-checked security proofs for these countermeasures, transaction from the start.
using our extended model. This means that they effectively With the mentioned checks in place, we again attempted
prevent the card brand mixup attack as well as both PIN by- our attack. This time it failed: the terminal requested the
insertion of the card into the terminal and the entry of a PIN. where we modified the IAC-Denial object were declined. We
Our experiments therefore provide evidence that these checks, exposed a similar PIN harvest attack in [6].
deployed now by Mastercard, prevent our Mastercard-Visa Another PIN-related issue for EMV was observed by Emms
mixup attack. et al. in [13]. The authors reported that some Visa contactless
cards issued in the UK do not request PIN verification for non-
GBP transactions. We note that this is unlikely to be exploited
5 Related Work with modern cards and terminals. The reasons are two-fold:
(1) the current Visa kernel establishes that if the terminal
In this section we review some of the related work on EMV requires cardholder verification for a given transaction, then
(in)security, focusing on other practical attacks against the the card must offer at least one method to do so, and (2) Emms
payment standard. As can be seen in our and others’ work, et al.’s observation seems to work only for transactions in
the EMV contactless protocol is a prime target for hackers, EMV’s magstripe mode, which is now deprecated.
given the ease of eavesdropping and modifying transaction Various relay and other NFC attacks have been presented in
data on the NFC channel. Widely available hardware such as hacking conferences, such as [21,24,29,31]. In particular, [29]
mobile phones, Arduino boards, and Raspberry Pi boards can presents a relay attack implementation that uses two Software
easily be used for these attacks. Defined Radio (SDR) boards, which offer a faster and more
Ten years ago, Murdoch et al. [27] reported the first PIN controlled relay channel than the ones implemented using
bypass attack against the EMV payment system.3 The authors mobile phones over WiFi, according to the authors. However,
demonstrated that, for transactions where the card verifies the the transmission speed of WiFi-based relay channels has not
PIN entered on the terminal’s PIN pad, a man-in-the-middle been an issue in any of our tests using our Android app.
can simply reply with the “PIN verified” response to any PIN Galloway and Yunusov [21] were the pioneers in bypassing
entered, right or wrong. The security flaw leading to this at- PIN verification for modern Visa contactless cards. Their man-
tack is the lack of authentication of the card’s response to in-the-middle attack, implemented using wired Raspberry Pi
the terminal’s PIN verification request, used in offline Card- boards, modifies both the Terminal Transaction Qualifiers
holder Verification Methods (CVMs). Our prior research [6] (TTQ) before delivering it to the card and the Card Trans-
showed that this flaw still exists in old cards that support action Qualifiers (CTQ) before transmitting it back to the
neither asymmetric cryptography nor online PIN verification. terminal. The authors did not however weaponize their attack
Ferradi et al. [18] described the forensic analysis of a series in a way that it could be inconspicuously used in real stores.
of credit card fraud events where criminals used 40 modified Galloway recently showed [20] that it is possible, still in
cards and carried out 7,000 fraudulent transactions, totaling 2020, to clone a card and use the clone for swiped transactions.
about 600,000 Euros. The technical flaw that was presumably The author shows that the cloning can be made effortlessly,
exploited by these criminals is that of [27]. using the MSR605 magnetic card reader/writer, which costs
Barisani et al. [5] presented a PIN harvest attack, also around 100 USD. This research also shows that the data used
against EMV contact cards. Their attack works by downgrad- to create the counterfeit magstripe cards can be read from the
ing the card’s list of supported CVMs to a Plaintext PIN-only EMV interfaces (both NFC and contact chip) with a skimmer
list. The authors showed that the protection against modifica- device. The data needed is part of the Track 1 and Track 2
tion that the Offline Data Authentication (ODA) offers to the Equivalent Data objects, provided by the card during an EMV
CVM list can be bypassed by setting the card-sourced Issuer session. Back in 2008, Drimer et al. [12] also demonstrated
Action Code (IAC)-Denial object to zero. This prevents the cloning from EMV chip data to magstripe; thus this problem
terminal from declining transactions with ODA failure. The has remained unfixed even after 12 years.
terminal’s selection of the CVM is determined by the card’s As explained throughout this paper, our card brand mixup
list of supported CVMs. The authors found out that, even attack builds on our previous work [6]. In a nutshell, there
if this list is authenticated to the terminal during the offline are three main differences between our previous work and
authentication of the card, the list can be downgraded to a this new work. First, the card brand mixup attack is com-
Plaintext PIN-only list. This is possible by setting the Issuer pletely novel and exposes a serious weakness in EMV that
Action Code (IAC)-Denial data to zero, which prevents the permits payments with Mastercard cards for fraudulent Visa
terminal from declining the transaction. transactions. Second, we have extended our previous model
EMV’s specification v4.3 [15] (p. 115) recommends using of the issuer and of the terminal-issuer channel to support
a non-zero Terminal Action Code (TAC)-Denial object, which the completion of online transactions where the terminal and
results in ODA-failing transactions being declined and thus issuer do not observe the same card brand. We have used our
prevents the PIN harvest of [5]. Indeed, during the (contact- extended model to verify our new fixes that prevent the card
less) tests we performed using our app, all the transactions brand mixup. Finally, concerning the implementation of our
attack, nearly 1,000 lines of Java code in our software instru-
3 BBC News coverage at [Link] ment the NFC message modifications specific to the attack as
well as the required cryptographic mechanisms such as the ATC Application Transaction Counter. 5, 8, 10
retrieval of PKs from PK certificates. Our PIN bypass attack
on Visa does not require any of these mechanisms. AUC Application Usage Control. 8

CA Certificate Authority. 3, 4, 8
6 Conclusions
CDA Combined Dynamic Data Authentication. 4, 5, 8, 11
We have identified a serious, easily exploitable vulnerabil-
ity in the EMV contactless protocol, namely the Application CDCVM Consumer Device CVM. 5, 8, 11
Identifiers (AIDs) are not authenticated to the payment ter-
CDOL Card Risk Management Data Object List. 3, 8
minal. The AIDs define what instance (a.k.a. kernel) of the
protocol must be activated for the transaction. As a result, CID Cryptogram Information Data. 5, 6, 8
an adversary can maliciously replace the legitimate AIDs to
deceive the terminal into activating a flawed kernel. CTQ Card Transaction Qualifiers. 3, 5, 8, 13
We have shown how to exploit this vulnerability using a CVM Cardholder Verification Method. 3, 5, 10–13
man-in-the-middle attack that tricks the terminal into trans-
acting with a Mastercard card, while believing it to be a Visa CVMR Cardholder Verification Method Results. 8
card. This card brand mixup, in combination with our recently
developed PIN bypass attack [6] on Visa, results in a novel, DDA Dynamic Data Authentication. 5, 11
critical attack where criminals can bypass the PIN for Master-
card cards. The cards of this brand were previously presumed DDOL Dynamic Data Object List. 5
protected by PIN. Shockingly, this is even possible for trans-
actions that are authorized online in which the terminal and IAC Issuer Action Code. 13
the card issuer do not agree on the payment card’s brand.
To carry out our exploit, we developed a proof-of-concept IAD Issuer Application Data. 5, 8, 10
Android application and successfully tested our attack on a
real-world payment terminal. For example, we bypassed the MAC Message Authentication Code. 1, 4, 5
PIN in a transaction for 400 CHF with a Maestro debit card.
We have also extended our formal model of EMV by mod- NFC Near Field Communication. 2, 3, 6, 8, 13
eling the terminal-issuer channel in a way that allows for
communication even when these agents disagree on the card ODA Offline Data Authentication. 3–6, 11, 13
brand. We used our extended model to formally verify that
the ready-to-deploy fixes applicable to the Visa kernel that PAN Primary Account Number. 1–3, 5, 6, 8, 10–12
we proposed in [6] are an effective countermeasure to our
Mastercard-Visa mixup attack. Additionally, we have speci- PDOL Processing Data Object List. 3, 5, 6, 8
fied and verified two new intra-kernel countermeasures that
PK Public Key. 3, 6, 8, 14
can be implemented on the Mastercard kernel without relying
on Visa’s defenses. Furthermore, Mastercard has implemented
an alternative defense mechanism at the network level, which RID Registered Application Provider Identifier. 1
we have experimentally confirmed as effective against our
attack. SDA Static Data Authentication. 3, 11
SDAD Signed Dynamic Authentication Data. 5, 6, 8, 11, 12
Acronyms Used
SDR Software Defined Radio. 13
AAC Application Authentication Cryptogram. 6
SSAD Signed Static Authentication Data. 5
AC Application Cryptogram. 5, 6, 8, 10, 12
TAC Terminal Action Code. 13
AFL Application File Locator. 3, 8
TC Transaction Cryptogram. 6
AID Application Identifier. 1–3, 6, 9–12, 14
TT Terminal Type. 8
AIP Application Interchange Profile. 3, 5, 6, 8, 10
TTQ Terminal Transaction Qualifiers. 5, 6, 8, 11, 13
ARC Authorization Response Code. 6
ARQC Authorization Request Cryptogram. 6, 8 UN Unpredictable Number. 5
References [12] Saar Drimer, Steven J. Murdoch, and Ross J. Anderson.
Thinking inside the box: System-level failures of tamper
[1] The EMV Standard: Break, Fix, Verify. https:// proofing. In 2008 IEEE Symposium on Security and
[Link]/. Accessed: February 2021. Privacy (S&P 2008), 18-21 May 2008, Oakland, Cali-
fornia, USA, pages 281–295. IEEE Computer Society,
[2] Host-based card emulation overview. https: 2008.
//[Link]/guide/topics/
connectivity/nfc/hce. Accessed: August 2020. [13] Martin Emms, Budi Arief, Leo Freitas, Joseph Hannon,
and Aad P. A. van Moorsel. Harvesting high value for-
[3] A model of EMV with PAN-based routing. https://
eign currency transactions from EMV contactless credit
[Link]/EMVrace/EMVerify-PAN-routing. Ac-
cards without the PIN. In Proceedings of the 2014
cessed: February 2021.
ACM SIGSAC Conference on Computer and Commu-
[4] A Tamarin model of EMV. [Link] nications Security, Scottsdale, AZ, USA, November 3-7,
EMVrace/EMVerify. Accessed: February 2021. 2014, pages 716–726, 2014.

[5] Andrea Barisani, Daniele Bianco, Adam Laurie, and Zac [14] EMVCo. EMV Integrated Circuit Card Spec-
Franken. Chip & PIN is definitely broken: Credit Card ifications for Payment Systems, Book 2, Se-
skimming and PIN harvesting in an EMV world. In curity and Key Management, Version 4.3.
Defcon, volume 19, 2011. [Link]
documents/EMV_v4.3_Book_2_Security_and_Key_
[6] David A. Basin, Ralf Sasse, and Jorge Toro-Pozo. The Management_20120607061923900.pdf, November
EMV standard: Break, Fix, Verify. In 42nd IEEE Sym- 2011.
posium on Security and Privacy (S&P 2021), 2021.
[15] EMVCo. EMV Integrated Circuit Card
[7] Thomas Bocek, Christian Killer, Christos Tsiaras, and Specifications for Payment Systems, Book
Burkhard Stiller. An NFC relay attack with off-the-shelf 3, Application Specification, Version 4.3.
hardware and software. In Rémi Badonnel, Robert Koch, [Link]
Aiko Pras, Martin Drasar, and Burkhard Stiller, editors, documents/EMV_v4.3_Book_3_Application_
Management and Security in the Age of Hyperconnec- Specification_20120607062110791.pdf, Novem-
tivity - 10th IFIP WG 6.6 International Conference on ber 2011.
Autonomous Infrastructure, Management, and Security,
AIMS 2016, Munich, Germany, June 20-23, 2016, Pro- [16] EMVCo. EMV Contactless Specifications for Payment
ceedings, volume 9701 of Lecture Notes in Computer Systems, Book C-2, Kernel 2 Specification, Version 2.9.
Science, pages 71–83. Springer, 2016. [Link]
documents/C-2-Kernel-2-V2.9-final_3.pdf,
[8] Tom Chothia, Flavio D. Garcia, Joeri de Ruiter, Jordi
March 2020.
van den Breekel, and Matthew Thompson. Relay cost
bounding for contactless EMV payments. In Financial
[17] EMVCo. EMV Contactless Specifications for Payment
Cryptography and Data Security - 19th International
Systems, Book C-3, Kernel 3 Specification, Version 2.9.
Conference, FC 2015, San Juan, Puerto Rico, January
[Link]
26-30, 2015, Revised Selected Papers, pages 189–206,
documents/[Link], March 2020.
2015.

[9] Cas Cremers and Sjouke Mauw. Operational Seman- [18] Houda Ferradi, Rémi Géraud, David Naccache, and As-
tics and Verification of Security Protocols. Information sia Tria. When organized crime applies academic re-
Security and Cryptography. Springer, 2012. sults: a forensic analysis of an in-card listening device.
J. Cryptographic Engineering, 6(1):49–59, 2016.
[10] Chris Dodd and Barney Frank. Dodd-Frank Wall Street
Reform and Consumer Protection Act. [Link] [19] Lishoy Francis, Gerhard P. Hancke, Keith Mayes, and
[Link]/app/details/PLAW-111publ203, Konstantinos Markantonakis. Practical relay attack on
July 2010. contactless transactions by using NFC mobile phones.
IACR Cryptology ePrint Archive, 2011:618, 2011.
[11] Saar Drimer and Steven J. Murdoch. Keep your enemies
close: Distance bounding against smartcard relay attacks. [20] Leigh-Anne Galloway. It only takes a minute to clone
In Proceedings of the 16th USENIX Security Symposium, a credit card, thanks to a 50-year-old problem. Link,
Boston, MA, USA, August 6-10, 2007, 2007. 2020.
[21] Leigh-Anne Galloway and Tim Yunusov. First contact: [27] Steven J. Murdoch, Saar Drimer, Ross J. Anderson, and
New vulnerabilities in contactless payments. In Black Mike Bond. Chip and PIN is broken. In 31st IEEE
Hat Europe 2019, 2019. Symposium on Security and Privacy, S&P 2010, 16-19
May 2010, Berleley/Oakland, California, USA, pages
[22] Mastercard Inc. Annual Report 2019. [Link] 433–446, 2010.
[Link]/479285134/files/doc_financials/
2019/ar/2019-Annual-Report-on-Form-10-K. [28] Benedikt Schmidt, Simon Meier, Cas J. F. Cremers, and
pdf, 2020. David A. Basin. Automated analysis of Diffie-Hellman
protocols and advanced security properties. In 25th
[23] Visa Inc. Annual Report 2019. [Link] IEEE Computer Security Foundations Symposium, CSF
com/307498497/files/doc_downloads/Visa-Inc. 2012, Cambridge, MA, USA, June 25-27, 2012, pages
-[Link], 2020. 78–94, 2012.
[24] Eddie Lee. NFC hacking: The easy way. In Defcon, [29] Haoqi Shan and Jian Yuan. Man in the NFC. In Defcon,
volume 20, pages 63–74, 2012. volume 25, 2017.
[25] Gavin Lowe. A hierarchy of authentication specifica- [30] Luigi Sportiello and Andrea Ciardulli. Long distance
tion. In 10th Computer Security Foundations Workshop relay attack. In Radio Frequency Identification - Se-
(CSFW ’97), June 10-12, 1997, Rockport, Massachusetts, curity and Privacy Issues 9th International Workshop,
USA, pages 31–44, 1997. RFIDsec 2013, Graz, Austria, July 9-11, 2013, Revised
[26] Simon Meier, Benedikt Schmidt, Cas Cremers, and Selected Papers, pages 69–85, 2013.
David A. Basin. The TAMARIN prover for the sym- [31] Jordi van den Breekel. Relaying EMV contactless trans-
bolic analysis of security protocols. In Computer Aided actions using off-the-shelf Android devices. In BlackHat
Verification - 25th International Conference, CAV 2013, Asia, Singapore, 2015.
Saint Petersburg, Russia, July 13-19, 2013. Proceedings,
pages 696–701, 2013.