New Vulnerabilities in Public Transport Schemes for Apple

Pay, Samsung Pay, GPay

Timur Yunusov, Artem Ivachev (Positive Technologies), Aleksei Stennikov (independent).

Version 3

November 2021

1 | Page
Contents

Introduction 3
Contactless payments overview 4
EMV Security features overview 5
How mobile wallets work 7
The overview of payment fraud possibilities 9
How the Public Transport Scheme works 10
Attacks 15
List of found and reported issues in the Public Transport Schemes 24
Affected regions 26
Statistics 27
Vulnerability disclosure timeline and results 29
References 31

2 | Page
Introduction
In recent years, there has been significant consumer demand for instant payments through their
mobile phones. Unfortunately, the security part of mobile NFC payments has been pushed to the
back of the queue. Before 2019, Apple Pay and Samsung Pay did not allow payments unless the
phone was unlocked by a fingerprint, Face ID or PIN.

With the surge of contactless payments using digital wallets in many regions [12], all vendors had
to adapt and provide more flexibility and make contactless payments easier.

Now, such payments exist, and they are named "public transport schemes". To understand the
market demand's powers – between 28th April and 25th May 2019, over 48.38 million train
journeys were paid for using contactless methods such as cards and mobile wallets in London
alone.

In 2018 the New York Metro passengers used contactless payments 3.37 billion times [9,10]

Worldwide public transport started adopting Apple Pay and GPay/Samsung Pay to serve its
customers' needs. One of the many benefits of using such transport schemes is that of usability.
Once you've enabled your card and added it to your wallet, you can enter the station, passing
through the gates without unlocking your phone.

The Transport Card is a regular Visa/MasterCard/AMEX card enrolled and marked as such in any
dedicated regions: Japan, UK, USA, China. Once you've enabled your Transport Card and added
it to your wallet, you can enter the station, passing through the gates without unlocking your
phone.

As a result of our extensive research, we have discovered vulnerabilities in Apple Pay, Samsung
Pay and GPay, that allow for the use of stolen mobile devices on which Public Transport Schemes
was activated. As such, we were able to make unlimited purchases on any terminals, not only
limited to public transport.

One of the new attacks against EMV that was discovered is the Cryptogram Confusion Attack. It
utilises different views on the cryptogram type from mobile wallets and cards from one side and
authorisation hosts from another.

This research will shed light on how wallets work and what could be done differently by card
providers and mobile wallets' vendors to better fight against the Lost & Stolen category of fraud
[13].

3 | Page
Contactless payments overview
When you look at the card payment technologies through their security prospects, they could be
ranged:

- Lower security: card-not-present, magstripe.

- Medium security: EMV, NFC, card-not-present with 3D-Secure.

- High security: Apple Pay, Samsung Pay, GPay in-app and NFC payments.

That's why in payment security research, mobile wallets are considered the most secure and,
therefore, potentially harder to identify vulnerabilities within them.

For contactless card payments below certain limits, no cardholder verification is required. It is
called the NoCVM limit or Tap&Go limit. For transactions above these limits, either PIN entry or
chip usage is required. Each country recommends these limits, but every merchant can set up
their limits in stores.

More information about Visa cards attacks against the NoCVM limit was explained in our previous
work [1]

4 | Page
EMV Security features overview
EMV (Europay, Mastercard, Visa) was proposed in the early 2000s to tackle the main issues of
magstripe and card-not-present transactions. Smartcards were introduced to provide more
security. These smartcards are utilising three major security features [1]:

- Cardholder verification

- Card authentication is also known as Offline Data Authentication

- Transaction authorisation

To better understand this research, we will walk through only one of these features – transaction
authorisation made via an online cryptogram (ARQC).

Suppose the POS's Risk Management' outcome is to conduct an online authorisation. In that case,
the POS terminal will request an online cryptogram from the EMV card or a mobile wallet via the
"Generate AC" command. At this point, the terminal knows all the fields that a particular card
requires to generate the cryptogram. Depending on the card brand and the cryptogram version,
these fields may vary, but the minimum viable fields are amount, currency, date, UN. A card or a
wallet also will conduct a Risk Management step and, if all conditions are satisfied, will present a
cryptogram back to the terminal. Additionally, it will give the terminal a cryptogram type field, ATC
(application transaction counter), and the CVR/IAD field that indicates the Risk Management step
outcome. All these fields are described in EMV specs and encoded in TLV (Tag-Length-Value)
format:

On the picture above, you can see these fields:

POS:

Requested cryptogram type – 0x80 (ARQC, no CDA required)

Amount – 1.00

Currency – GBP

5 | Page
 Date – 13/10/2021

UN - aabbccdd

Card:

Presented Cryptogram type (9f27 Tag) – 0x80 (ARQC)

Cryptogram value (9f26 Tag) – 0xaabbccddeeffaabb

ATC, Application Transaction Counter (9f36 Tag) – 0x0004

IAD (9f10 Tag) – 0x9f101a0215a50000420000000000000000000000ff00000000000000ff

Includes CVR:

[Card verification results] A50000420000

[Byte 1 Bit 8 = 1, Byte 1 Bit 7 = 0] Second Generate AC not requested

[Byte 1 Bit 6 = 1, Byte 1 Bit 5 = 0] ARQC Returned in First Generate AC

6 | Page
How mobile wallets work
Adding your card's information into a mobile wallet creates a "token" or a virtual card.

All cryptographic features for tokenised payments are made on the tokenisation service that the
mobile wallet's vendor outsources. In traditional card processing, the issuing bank is in charge of
these security features, usually made on HSM (Hardware Secure Module).

For future references, the Visa tokenisation service is called VTS (Visa Token Service), the
MasterCard service is called MDES (Mastercard Digital Enablement Service).

The issuing bank gets only the original card information with an amount and merchant details for
their decision-making process from these services. Sometimes banks could request additional
EMV information, such as what type of offline authentication was made.

There are two mobile wallet schemes: Secure Element and HCE (Host-Card Emulator).

Secure Element uses a separate chip to make all cryptographic functions on the phone, replacing
the card's Java Applet. It's almost impossible to compromise a separated chip and keep the device
intact.

The HCE scheme loads temporary keys from the cloud onto the device every 10-20 transactions
and represents a risk-based approach. As a result, even if encryption keys are compromised, they
will be valid only for a few transactions.

Both Apple Pay and Samsung Pay use Secure Element. GPay uses HCE.

A new group of CVM limits was introduced for mobile wallets – CDCVM [11]. CDCVM replaces a
PIN entry for the chip or contactless transactions. That's why most merchants will not have any
limits for mobile wallet payments. And even if these limits are set up in some merchants, in our
previous work, we have shown that they are much higher than standard NoCVM limits: £5,500 or
$10,000 [1]

It is vital to stipulate that having no access to payment details, Apple, Google, and Samsung have
no responsibility for secure storage or transmission of such information.

On the one hand, it's very convenient, as you don't need to deal with any additional PCI (Payment
Card Industry) certification and implement extra security measures. On the other hand, in case of
any fraud, these mobile brands would blame the issuing bank, merchant, or token service that
approved suspicious payments. The argument for mobile wallet's brands would be that they don't
store or transfer and can't even monitor information about cards, merchants or cardholders, but
only serve as payment devices.

In the end, "the most secure payment method" serves not mobile users but large corporations
mitigating their risks.

7 | Page
https://en.wikipedia.org/wiki/Tokenization_(data_security)

8 | Page
The overview of payment fraud possibilities
EMV cards are well-protected against cloning. However, there have been many other fraud
cases related to chip cards affecting the security of EMV/NFC over the last decade. These
cases are not as vast as card-not-present or magstripe fraud because of the impossibility of
scaling such attacks. Most of the fraud affects Lost & Stolen cards and targets cardholder
verification features [4, 5, 6, 7].

And much more academic research was done in this area [1, 2, 8].

EMV was never made to be "absolutely secure". It was designed to be "secure enough" to
counteract mass schemes of card-not-present and magstripe fraud. So why can't the
payment industry come with an "absolutely secure" payment scheme? It's a balance
between reliability and security. The industry prefers to choose less secure methods, which
decrease potential false positives almost to 0. This concept is made of back-compatibility
and legacy features, which all put the security of the EMV scheme at risk. The risk-based
model-driven payment industry can accept fraud' false-positive rates as long as they cost the
players less than X. But individually, every of these fraud cases could have devastating
consequences for either a bank or a cardholder.

Since mobile wallets have become a commodity, fraudsters have started targeting them as
well. Most popular types of fraud include adding stolen cards for paying from them without
limits and leaving less information for tracking fraudsters [14], and using in-app payment
scams [15].

Lost & Stolen fraud numbers stabilised just below 100 million pounds only in the UK in the
last three years. And only in 2020, these numbers have dropped 20% [13]. Even though
thousands of cases that lead to hundreds of millions being stolen sounds like a lot.

9 | Page
How the Public Transport Scheme works
The customer makes a fixed payment at the entrance to the transport and again at the exit.
For example, it is 0.00 at London TfL, but it may vary in different regions and transport
systems based on our analysis. Then the payment provider calculates the actual cost based
on the route and charges the card. Public Transport Schemes terminals don't request an
immediate online authorisation to speed up the ticketing process. They conduct Offline Data
Authentication instead, and if the bank declines the card, it goes onto the "stop-list" to
prevent further usage until fees are paid.

NB: For the purpose of a more straightforward narrative, we put the analysis and attacks
against Samsung Pay first, as it took much longer to reconstruct Apple Pay's proprietary
activation mechanism. As a result of this, we discovered Samsung Pay vulnerabilities earlier.

Reversing Samsung Pay

To reverse the Samsung Pay scheme and implement the attacks from the next section, we
used two PN532 NFC readers for the Man-in-The-Middle attack, allowing us to modify the
EMV fields from the phone to the reader and back. We have a public GitHub repo containing
the NFC MiTM code working with these readers, the whole RaspberryPi image, and the
connection scheme. Check out more at https://github.com/a66at/NFCMiTM

After a few tests using different card brands, we reversed the basic concept of the Samsung
Pay Public Transport Scheme.

When you set up a default card for transport usage, the phone always allows payments from
this card. If the payment amount is 0.00 and the Offline Data Authentication is used, these
payments are accepted by a locked phone. Otherwise, it will ask you to unlock and enter a
PIN. MasterCard also requires the terminal to have a particular merchant category (MCC).

10 | Page
Generate AC:
80ae90004100000000000000000000000008260000000000082621031000862d342922000
000000000000000003f00024111000000000000000000000000000000000000000000

Payment for: £0.00

MCC: 4111 (Transport)

Response:

77 81 B6 9F 27 01 80 9F <- Cryptogram type: 0x80 (ARQC)

36 02 00 1C 9F 10 1B <- ATC: 0x001c

1A 92 11 03 A0 00 02 01 10 21 03 07 04 43 39 21

03 12 04 43 38 98 7B 39 91 01 00 9F 4B 81 80 3B

EF 2B 15 29 88 B5 DB 6B E6 56 EC DD 8A EE 11 F7

82 AB DF 24 E6 49 30 F6 79 1F DB 20 FE A6 99 0B

15 E7 D3 35 B4 B2 C6 A3 7C 45 77 0F ED 7F 56 D0

F6 7A C5 6A FD C8 F5 25 6D 17 2C 4E 3E F3 61 C6

E6 5E 2D 18 1E D7 CF 6E 49 58 C2 51 5D 3F E1 03

69 B4 65 3B 48 27 94 67 5A 03 C3 FE C9 3D 12 25

AF 69 DB 9D 06 B4 C6 0E E6 AA 79 20 BE 66 3D B8

11 | Page
7D 36 BF AC 1D 66 27 05 EF 32 53 E7 A4 AD 4F

9F 26 08 AA AA BB BB CC CC DD DD <- Cryptogram: 0xAAAABBBBCCCCDDDD (inside

of the SDAD)

The spreadsheet below indicates what fields each card brand checks on Samsung Pay and
what is the outcome of each configuration:

Visa MC AMEX
Amount=0,
Conditions of the Amount=0, MCC=Transport (e.g. 4111)
Transport Cards ODA is required Mode is M/CHIP Amount=0
Outcome if
conditions 6985 Conditions of 6985 Conditions of use
are not satisfied use not satisfied AAC cryptogram not satisfied

Reversing Apple Pay

When Apple announced that Public Transport Schemes could be used without unlocking
your phone, we knew we had to see this!

Equipped with the Proxmark3, we went to TfL fare gates that support Apple Pay. We made a
few transactions, came back home and were confused a bit. While there was nothing
suspicious in the traffic – all usual transactions' data, we kept failing to pay with the locked
phone on regular readers. So how did it work then?

At first, we thought that the proprietary technology stack called Enhanced Contactless
Polling (ECP) and Value Added Services (VAS) with public key exchanging mechanism was
the answer. However, several unsuccessful attempts later using other readers to sniff –
HydraNFC – by trial and error, we eventually saw a real something – a magic string that
activates NFC on iPhone.

When the NFC field is active, the transaction goes as usual as long as the Offline Data
Authentication has been chosen. iPhone does not even check the amount nor MCC fields for
risk management and decision making. How this approach weakens the payment process,
we present later in the attack's description.

12 | Page
This spreadsheet indicates what fields what card brand checks on Apple Pay and what is the
outcome of each configuration:

Visa MC
Conditions of the MCC=Transport (e.g. 4111)*,
CDA is required
Transport Cards CDA is required
Outcome if
conditions 6986 Command not allowed AAC cryptogram
are not satisfied
*For some issuers, MCC is also a part of the cryptogram

Reversing GPay

GPay requires the phone to have an active screen to make payments below NoCVM limits.
That's why it smoothly works in public transport as long as the customer activates the screen
before using the Public Transport Scheme.

GPay doesn't have a dedicated Transport Card, and phone owners can use any as the
Transport Card instead.

We used the same set-up for the Man-in-The-Middle attack for GPay with two PN532
readers.

13 | Page
14 | Page
Attacks
1.1 Cryptogram Confusion against Samsung Pay MasterCard Transport
Card
During the Public Transport Scheme if the MasterCard card presents the amount that is
higher than 0.00 or the MCC is out of white-list related to public transport such as 4111
(https://www.mastercard.us/content/dam/mccom/en-us/documents/rules/quick-reference-boo
klet-merchant-edition.pdf) the phone will answer with the AAC, a decline cryptogram:

Generate AC:
80ae80004100000000010000000000000008260000000000082621031000862d342922000
000000000000000003f00021234000000000000000000000000000000000000000000

Payment for: £1.00

MCC: 1234

Response:

77 6d 9f 26 08 da aa bb 74 51 05 ea fd 94 04 10 <- Cryptogram: 0xdaaabb745105eafd

02 04 00 82 02 20 40 9f 36 02 00 1d 9f 6c 02 00 <- ATC: 0x001d

00 9f 27 01 00 9f 6e 04 23 8c 00 00 9f 10 20 1a <- Cryptogram type: 0x00 (AAC, decline)

02 15 a5 00 00 00 00 00 00 00 00 00 01 15 72 00 <- CVR, indicating a cryptogram type

AAC

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 57 <- and that the phone was not unlocked

13 42 44 95 66 11 51 30 61 d2 31 22 01 00 00 00

00 00 00 0f 5f 34 01 00 9f 7c 04 00 00 00 00

And will show the correspondend message:

15 | Page
ATC had a consecutive value from the previous valid transaction, and the only difference
from the working cryptogram was a cryptogram type (0x00 AAC instead of 0x80 ARQC).
After looking at this, we asked ourselves – what if all that mobile wallet does, is change the
cryptogram type field, and the algorithm for constructing an AAC cryptogram is exactly the
same as for an ARQC cryptogram. Then all we would need is to change back the
cryptogram type from 00 to 80.

And it worked – the cryptogram was successfully accepted by the iZettle terminal that we
used for these tests, and the payment went through. It was possible despite the CVR field
that still indicates to the authorisation host (in this case - MDES) that the cryptogram type
was a decline AAC cryptogram. The only problem in the actual terminals was that
MasterCard mandates to conduct CDA authentication schemes for all their contactless cards
and wallets in every region [17]. That means that the terminal will catch tampered
Cryptogram Type field and will reject the transaction.

And here newly released "Card Brand Mixup Attack" from the ETH University [2] comes to
help. This attack makes the terminal think that the card or wallet is Visa-branded. Therefore
no CDA is required (Visa does not mandate CDA because they assume that CDA
unnecessarily slows down the transaction's duration). For Visa cards, merchants can decide
themselves whether terminals need to carry out the offline authentication or not, and for
most online terminals, they don't. That additional step allows hackers to use stolen Samsung
Pay devices to make payments almost at every shop in the world.

In physical MasterCard, Visa or AMEX cards, the Cryptogram Confusion attack sometimes
also could be applied for making transactions on locked cards. We had shown these
examples in another publication [18].

16 | Page
For GPay, when specific payment requirements are not satisfied, the phone generates an
AAC with ATC=0x0001. Hackers can't use such a pair to authorise the transaction with an
AAC cryptogram.

Attack steps (Image:

https://drive.google.com/file/d/1lWn25JHEWjzXeQVTuJOmvJpNds-Y_5Jt/view):

1. We use a Man-in-the-Middle attack (MiTM) to change data between the locked phone and
the terminal. When the payment data is passed to the phone, it looks and makes decisions
based on the amount. If the amount is not 0.00, the phone generates an AAC (transaction
decline) cryptogram for MasterCard cards and sends an iterative correct ATC (transaction
counter). We found that for Samsung Pay MasterCard tokenisation service (MDES)
accepts an AAC cryptogram as a regular ARQC (online cryptogram), even though MDES
could see in the CVR/IAD field (tag 9f10) that it is a decline cryptogram. It means that
hackers can use the AAC/ATC pair to authorise the transaction for an amount greater than
zero on any terminal.

2. Next, we need to bypass Offline Data Authentication (ODA), mandatory for MasterCard
contactless cards and wallets. It can be done using the "Card Brand Mixup Attack".
Bypassing the ODA will allow the transaction to pass through the terminal and be accepted
by the issuing bank.

We could replace the Merchant Category (MCC) field with anything because it is checked
only on the terminal. It is not checked at the MasterCard token service (MDES), which
processes mobile wallet's NFC transactions.

We recorded an example of such an attack for future evidence:

https://drive.google.com/file/d/1GLMePGdvA3c5xBBRWP0XMKI6hTTsUeEz/view?usp=shari
ng. In this video, you can see that even the phone thinks that the payment was declined, and
it didn't go through. But the payment happens, and the online terminal (iZettle) charges £1 to

17 | Page
the phone's owner and the Samsung Pay tokeniser sees the transaction as legit. You could
also notice that the reader thinks it was a Visa card/wallet, but it was a MasterCard wallet
that pretended to be a Visa wallet. It is the "Card brand mixup attack" in a nutshell.

1.2 Apple Pay Visa Transport Card

Apple Pay does not check if the amount is higher than 0.00. It only checks MCC for
MasterCard cards and ODA both for Visa and MC. By the time of these checks, MasterCard
had blocked the possibility of the "Card Brand Mixup Attack", so we decided to focus mainly
on Visa cards.

It is a well-known fact that Visa makes CDA not mandatory to decrease the time of
card-terminal interaction. Because regular payments terminals all across the globe do not
have mandatory requirements to conduct CDA authentication, the attack is as easy as apple
pie.

Attack steps (Image:

https://drive.google.com/file/d/1lWn25JHEWjzXeQVTuJOmvJpNds-Y_5Jt/view):

1. Hackers need to activate the NFC field using "magic string":

Sent: 6a 02 c8 01 00 03 00 02 79 00 00 00 00 c2 d8 (magic string)
Sent: 52 (7 bits)
Sent: 93 20
Sent: 93 70 00 00 00 00 00 9c d9

Close connection

Sent: 6a 02 c8 01 00 03 00 02 79 00 00 00 00 c2 d8 (magic string)

Sent: 52 (7 bits)
Received bits: 04 00
Sent: 93 20
Received bits: 08 36 06 fc c4
Sent: 93 70 08 36 06 fc c4 8d 07
Received bits: 20 fc 70
Sent: 02 00 a4 04 00 0e 32 50 41 59 2e 53 59 53 2e 44 44 46 30 31 00 e0 42 (now we can
send APDU requests)

Tag info:
UID : 083606fc
ATQA : 0004
SAK : 20

2. Hackers use a Man-in-the-Middle attack (MiTM) to change data between the locked
phone and the terminal. When the terminal sends a Generate AC command to the iPhone
with a Visa card, the phone makes decisions based only on the ODA flag that we are
changing.

3. Even if the amount is more than 0.00, the Apple Visa card will generate the ARQC
cryptogram. Because ODA is NOT mandatory for Visa cards in regular payment terminals,
we can drop this field, and Visa VTS will accept the fraudulent transaction.

18 | Page
We recorded an example of such an attack for future evidence:

https://drive.google.com/file/d/1tDeUsk5LXyhz3Gbw9DvtQhzkdQCTj4iI/view. This time, we

make a £1 payment on the locked iPhone with the Visa Transport Card.

The latest versions of iPhones also allow making payments even on uncharged phones -
https://drive.google.com/file/d/1XPoBKitMOaRGy5ojZk9Bj_Tli_elkbUm/view.

1.3 Samsung Pay Visa

The main difference between these two card brands for the Samsung Pay implementation is
that the Visa card does not return the AAC cryptogram if the amount field is not 0.00. Instead
of that, the device answers with 0x6985 (Conditions of use not satisfied).

Unfortunately, we were not able to bypass this step. However, we decided not to give up and
applied another type of attack.

For this attack, we will need to use direct access to the transaction stream. For this purpose,
we had to use one of our compromised and modified POS terminals.

Using a modified POS is common, and many fraudsters used them for attacking cards:
https://krebsonsecurity.com/2014/10/replay-attacks-spoof-chip-card-charges/. In the last few
years, we've demonstrated how to accomplish this step [3].

When a card payment is made, the POS terminal sends a specially crafted packet that
passes to the acquiring bank, and then via the payment network, arrives at the issuing bank.

In this packet, there're two places where the amount is presented:

● Amount, Transaction (Field 55). This field represented the amount shown on the POS
terminal during the payment and was signed by the online ARQC cryptogram.

● Amount, Cardholder billing (Field 04). This field represents the amount that the
merchant actually charged. It's a typical situation when the shown price is different from the

19 | Page
charged one. You can think of additional taxes, tips in restaurants and many other cases
where this scenario can be applied legitimately.

To apply the attack, we need to make some additional changes:

1. We initiate the payment for £1.00 using the modified POS.

2. Using a MiTM attack, we change the amount field in the Generate AC command from 1.00
to 0.00. It is the only known way to generate any cryptogram for the Visa or AMEX Transport
Card on the locked Samsung Pay device. But now, our cryptogram will be valid only for 0.00
amount.

3. Finally, we need to change the Amount field back so the Samsung Pay tokeniser will
check the cryptogram correctly and accept the payment. For this, we're changing the
"Amount, Transaction" field to 0.00 (9f02 EMV Tag), leaving the "Amount, Cardholder billing"
field with a 1.00 value. That will cause a £1.00 charge even the cryptogram has been used
to sign only the 0.00 transaction.

1.5 Samsung Pay AMEX, Apple Pay MasterCard (only for some cards),
Samsung Pay MasterCard (after latest updates)
The previously described scenario could be applied when the wallet requires the amount
field to be equal to 0 or the MCC code from the Transport category but don't check them
later during the transaction authorisation.

Let's look at the fraudulent scenario for Samsung Pay MasterCard Transport Card after the
Card Brand Mixup Attack was eliminated and after MasterCard has implemented some
changes to block the Cryptogram Confusion attacks:

1. We initiate the payment for £1.00 using the modified POS.

2. Using a MiTM attack, we change the amount field in the Generate AC command from 1.00
to 0.00. We should also change the MCC to 4111 (Transport), so the Samsung Pay
MasterCard token would generate the ARQC cryptogram.

3. Now, the Offline Data Authentication CDA step would lead to the transaction being
declined. That is why we used a modified POS or a POS that would allow us to modify
transaction stream fields directly.

3. We are changing the Amount field (9f02 EMV Tag) back to 0.00. In the CVR field wallet
indicates to MDES that the phone was locked. Because the MCC code is not from the
Transport category, MDES should decline these transactions. However, these transactions
are still approved.

The example of requested information from the locked Samsung Pay phone:

Request:
0000: 00 a4 04 00 0e 32 50 41 59 2e 53 59 53 2e 44 44
0010: 46 30 31 00

20 | Page
Response:
0000: 6f 23 84 0e 32 50 41 59 2e 53 59 53 2e 44 44 46
0010: 30 31 a5 11 bf 0c 0e 61 0c 4f 07 a0 00 00 00 04
0020: 10 10 87 01 01 90 00

Request:
0000: 00 a4 04 00 07 a0 00 00 00 04 10 10 00

Response:
0000: 6f 3e 84 07 a0 00 00 00 04 10 10 a5 33 50 10 44
0010: 45 42 49 54 20 4d 41 53 54 45 52 43 41 52 44 87
0020: 01 01 5f 2d 02 65 6e 9f 38 09 9f 1d 08 9f 1a 02
0030: 9f 35 01 bf 0c 0a 9f 6e 07 08 26 00 00 32 31 00
0040: 90 00

Request:
0000: 80 a8 00 00 0d 83 0b 2c b8 00 00 00 00 00 00 08
0010: 26 22 00

Response:
0000: 77 0e 82 02 1b 80 94 08 08 01 01 00 10 01 03 01
0010: 90 00

Request:
0000: 00 b2 01 14 00

Response:
0000: 70 81 c6 57 13 51 68 56 17 15 35 56 97 d2 41 22
0010: 01 00 00 00 00 00 00 0f 5a 08 51 68 56 17 15 35
0020: 56 97 9f 24 1d 35 30 30 31 32 4c 4c 46 49 30 37
0030: 51 53 52 51 48 41 4a 35 54 51 53 48 4c 43 4b 4e
***

Request:
0000: 80 ae 80 00 41 00 00 00 00 00 00 00 00 00 00 00
0010: 00 08 26 00 20 00 80 00 08 26 21 11 06 00 b0 c3
0020: 43 ff 22 00 00 00 00 00 00 00 00 00 00 3f 00 02
0030: 41 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040: 00 00 00 00 00 00 00

Response:
0000: 77 37 9f 27 01 80 9f 36 02 00 16 9f 26 08 0A ED
0010: 27 2F 2D 07 6B F2 9f 10 1a 02 15 A0 00 00 62 00
0020: 00 00 00 00 00 00 00 00 00 00 FF 00 00 00 00 00
0030: 00 00 FF df 4b 03 00 01 00 90 00

21 | Page
The example of ISO 8583 Field 55 (ICC related data) of the same fraudulent transaction:

5f2a02082682021b8050104445424954204d4153544552434152449f1c0831323334353637
389f0607a00000000410105f3401008407a00000000410109a032111069c01009f020600000
00000009f03060000000000009f090200019f101a0215a00000620000000000000000000000
ff00000000000000ff9f1a0208269f1e0831313037363538339f26080aed272f2d076bf29f2701
809f3303e028c89f3501229f360200169f37043c8ecc639f4104000056649f6604328040009f6
e0708260000323100df280100df30020201dfae0218ec7c5db7a59d27218df0d27f6319e61d9
9717d7a8bea945edfae030affff9802a40f9c0003fcdfae5713516856ffffff5697d2412201fffffffffffff
f5a08516856ffffff56975f280208265f24032412318407a0000000041010950500200080019f3
4033F0002

22 | Page
1.6 GPay Visa
Two years ago, we demonstrated an attack that allows making high-limit payments from
GPay Visa wallet without unlocking the phone [1]. At the time of that research, GPay was the
only technology used for the Public Transport Scheme in the UK because it didn't require
unlocking the phone for payments below certain limits. After that, Apple Pay and Samsung
Pay Public Transport Schemes have emerged in the UK, allowing us to test them.

We've got confirmation from Android Security Team that they're planning to do something
with this vulnerability. Still, the only thing that it's feasible to do without completely changing
the proprietary Visa algorithms is to disallow payments on the phone with the screen
activated by any external means – phone call, incoming notification, etc. Neither Visa nor
Google has confirmed their changes in the protocol itself.

To recap the attack steps against GPay Visa cards:

1. We activate the screen of the stolen phone. That allows making payments below NoCVM
limits.

2. We want to make higher payments up to $10,000. We use the MiTM attack to change the
TTQ field, byte 2, bit 7 to "0" to indicate that NoCVM is required for the payment.

These steps will allow making high-value payments in every terminal in the world against
Visa cards enrolled in GPay.

For making this research complete, we had to check two other payment brands: MC and
AMEX.

1.7 GPay MasterCard

First of all, researchers from ETH confirmed the possibility of making the "Card Brand Mixup
Attack" against GPay. We have found another way of making this attack possible.

All MasterCard cards enrolled in GPay have a weak M-STRIPE legacy mode enabled. This
mode has well-known vulnerabilities described in the paper "Cloning Credit Cards: A
combined pre-play and downgrade attack on EMV Contactless" [4]. This attack allows
creating a valid clone of the MasterCard card or wallet that has M-STRIPE enabled mode.

Whilst the wallet could control the maximum amount of possible transactions. We didn't meet
any cards that had more than 10,000. It means that only up to 10,000 requests should be
initiated with the GPay wallet to create a fully functional card clone. No further interaction
with the original wallet is required after that.

Banks and tokenisation services should monitor the ATC counter to spot unusual jumps in
ATC values of consecutive transactions to counteract the risk of cards/wallets cloning:

Issues that we discovered:

23 | Page
1. Due to outdated security in M-STRIPE, it's possible to convince a locked GPay phone that
NoCVM has been required, as well as it happens in the "3.1 GPay Visa" attack.

2. M-STRIPE CVC3 values can be recorded from the locked GPay phone to create a wallet's
functional clone.

3. Mobile wallets use CryptoATC as opposed to ATC for each consecutive transaction.
These values are decrypted back to regular transaction counters to track the sequence.
These values should be monitored against ATC jumping, but we had never met a situation
when we were blocked due to ATC being out of order.

Each enrolled card varies with the maximum UN length as well as physical cards. Therefore
the wallet cloning time from the stolen device can range from 1 to 5 minutes.

GPay accounts from the EU region have more strict rules about payments on locked phones
due to PSD2 regulation. New rules
https://support.google.com/pay/answer/7644132?co=GENIE.Platform%3DAndroid&hl=en
say that "You can only make a limited amount of locked transactions before your phone will
ask you to unlock it". There's no such limit in other regions, such as the USA, as many
purchases can be made using the described techniques.

Let us show the viability of such an attack even within the EU region:

1. A hacker could steal only five transactions with random ATCs. After that, GPay phone
would require to be unlocked.
2. If MDES does not check the consistency of CryptoATC/ATC values and the highest
entropy of M/STRIPE mode for the wallet's UN is 1,000, the chance of one accepted
transaction after 20 payments attempts is 10%. The same chance after 50 attempts
is 23% (Bernoulli Trials and Binomial Distribution Probability).

1.8 GPay AMEX

For making purchases over NoCVM limits, the modified POS will be required:

1. We initiate the payment for £1.00 using the modified POS.

2. Using a MiTM attack, we change the CVM requirement bit to 0 in the Generate AC
command.

3. We modify the transaction stream to change the CVM requirement bit to 0 so the
cryptogram checking process will pass in the GPay tokeniser.

24 | Page
List of found and reported vulnerabilities in Apple Pay, Samsung Pay,
GPay

1. AAC/ARQC cryptogram confusion

Affected card brands: Visa/MasterCard/AMEX

Affected mobile wallets: Samsung Pay, Apple Pay, GPay

Threat model: fraudulent payments can be made in any POS

When an AAC cryptogram is requested, it can be substituted and presented to the tokeniser
as an ARQC cryptogram. Moreover, when mobile phone declines the transaction due to risk
management, some mobile wallets provide the AAC cryptogram and ATC, which can be
used to authorise transactions. That means that stolen UN/cryptogram/ATC pair can be used
for making purchases.

Status: partially fixed (explained in the "Vulnerability disclosure” section).

2. Apple Pay authentication and fields validation issues

Affected card brands: Visa/MasterCard/AMEX

Affected mobile wallets: Apple Pay

Threat model: fraudulent payments can be made in any POS

Apple allows payments using Transport Card for amount>0.00, without implementing proper
authentication to ensure that only dedicated transport terminals were used for paying on
locked or uncharged iPhones.

Status: stated as intended behaviour by Apple

3. Lack of Amount/CVMResults fields checking for Public Transport

Schemes
Affected card brands: Visa/MasterCard/AMEX

Affected mobile wallets: Samsung Pay, Apple Pay, GPay

Threat model: fraudulent payments can be made in only compromised POS terminals,
except pair Visa/Apple Pay that could be used in any POS

Mobile wallets allow to charge one amount within the Public Transport Scheme' cryptogram
and charge a different amount using any payment terminal in the end. This is due to EMV
standards and is a requirement for modern payments when the price shown on the terminal
is different from the actual amount that's being charged.

Mobile wallet passes the information about the type of cardholder verification (whether it was
made on the locked phone or a fingerprint/PIN were presented, and the cardholder unlocked

25 | Page
the phone). Along with the Amount and MCC, the tokenisation service could appropriately
decide to reject or approve transactions.

Status: not fixed

4. Card Brand Mixup Attack

Affected card brands: MasterCard

Affected mobile wallets: Samsung Pay, GPay

Threat model: fraudulent payments can be made in any POS

A MasterCard's mandatory CDA authentication scheme can be bypassed using the "Brand
Mixup Attack". It allows an attacker to bypass amount, MCC, CVMResults fields and
successfully make payments in any POS terminal.

Status: fixed

5. Lack of integrity checks of the MCC field

Affected card brands: Visa/MasterCard/AMEX

Affected mobile wallets: Samsung Pay, Apple Pay (some regions), GPay

Threat model: fraudulent payments can be made in any POS

EMV used as a predecessor of mobile wallets does not require putting some mandatory
fields as a cryptogram input. These fields are crucial for risk management steps, and their
tampering can bypass payment restrictions.

Alternatively, mobile wallets should send the information about the type of cardholder
verification (whether it was made on the locked phone or a fingerprint/PIN were presented,
and the cardholder unlocked the phone). Along with the Amount and MCC, the tokenisation
service could appropriately decide to reject or approve transactions.

Status: not fixed

6. GPay payments above NoCVM limits

Affected card brands: Visa/MasterCard

Affected mobile wallets: GPay

Threat model: fraudulent payments can be made in any POS

EMV standards which are used as a predecessor of mobile wallets, do not put some
mandatory fields as a cryptogram input. These fields are crucial for risk management steps,
and their tampering can bypass payment restrictions.

Status: stated as intended behaviour by Android Security Team

7. GPay CryptoATC out of order payments

Affected card brands: MasterCard

Affected mobile wallets: GPay

26 | Page
Threat model: fraudulent payments can be made in any POS

During the transaction authorisation, MDES does not decline payments with ATC out of
order. That makes attacks possible even inside the EU region where hackers are limited to
only five transactions. Even five stolen transactions give a probability of 10-20% success
rate.

Status: stated as intended behaviour by Android Security Team

27 | Page
Affected regions
Affected Samsung Pay and Apple Pay phones should be registered to countries where the
Public Transport Schemes are available, such as Japan, the UK, USA, and China. However,
the cards can also be from any other region. Stolen phones can also be used in any region.

GPay accounts from the EU region have more strict rules about locked phones due to PSD2
regulation. New rules [16] say that "You can only make a limited amount of locked
transactions before your phone will ask you to unlock it". If the EU GPay phone has been
stolen, hackers will require a modified POS. There's no such limit in other regions, such as
the USA, as many purchases can be made using the described techniques.

28 | Page
Statistics
Samsung
Tested Vulnerable Exploitation requirements
Pay
2 cards were prone to attacks in any terminal,
MasterCard 8 4
2 require modified/compromised terminals

Visa 2 2 require modified/compromised terminals

AMEX 1 1 require modified/compromised terminals

We checked eight different Samsung Pay enrolled MasterCard cards. 4 of them allowed for
making fraudulent payments in arbitrary terminals (iZettle, PayPal, SumUp). The maximum
tested amount is £101.

We checked different regions and noticed that none of MasterCard cards from Russian
region were affected by the Cryptogram Confusion attack.

Apple Pay Tested Vulnerable Exploitation requirements

require modified/compromised
MasterCard 4 2
terminals*

Visa 7 7 Any terminals

We checked 4 different Apple Pay enrolled MasterCard cards. 2 of them allowed for making
fraudulent payments in the modified terminals. The transaction stream modifications are
required due to the "Card Brand Mixup Attack" being resolved. On the other hand, every
Visa card was affected by our findings

The maximum tested amount is £101.

GPay Tested Vulnerable Exploitation requirements

MasterCard 2 2 Special configuration of terminals
Visa 7 7 Any terminals
require modified/compromised
AMEX 1 1
terminals

Visa MC AMEX
Apple Pay any terminals modified terminals N/A
Samsung Pay modified terminals modified terminals* modified terminals
GPay any terminals special configuration modified terminals
*Since the Mixup attack possibility was closed

29 | Page
NB: Using a compromised, untraceable POS is common, and many fraudsters use
compromised terminals for card attacks:
https://krebsonsecurity.com/2014/10/replay-attacks-spoof-chip-card-charges/. We've
demonstrated how to accomplish this in the last few years
https://i.blackhat.com/eu-20/Thursday/eu-20-Stennikov-POSWorld-Should-You-Be-Afraid-Of-
Hand-Ons-Payment-Devices-wp.pdf. It's even easier because, in case of fraud investigation,
mobile wallet brands could act as an obstacle. Instead of helping with tracking fraudsters
down, we had got a few examples when one vendor was choosing to say, "we don't have
any data to help the investigation".

30 | Page
Vulnerability disclosure timeline and results

01/2021 – Android Security Team has been informed about M/STRIPE mode ATC out order
issues.

All reported vulnerabilities were marked as "intended behaviour". No further communication

from Android Security Team has followed.

03/2021 – Apple is informed about the Cryptogram Confusion attacks

In August 2021, Apple had confirmed that they would make no changes. However, they
asked if they could "share your research with the Mastercard security team".

03/2021 – Samsung Security Team is informed about all issues in Visa/MC/AMEX Transport
Cards

In April 2021, Samsung had confirmed that they would make no changes. However, they
asked for our "permission to share your contact information to VISA". Such permission was
granted. We also stipulated that MasterCard should be informed about the vulnerabilities
ASAP. No further communication from Visa/MasterCard has followed.

In November, I got an update from Samsung Team stating that even some changes
regarding Samsung Pay for Visa and MasterCard were made, they should not affect our
findings.

03/2021 – MasterCard is informed about the Cryptogram Confusion attack against Samsung
Pay

Despite a few more attempts to send the whitepaper to various MasterCard staff and
the confirmation from the Apple team that the report was passed to MasterCard, we
have never heard anything from MasterCard. However, a few changes were silently
done between March 2021 and November 2021:

● MasterCard had fixed the "Card Brand Mixup Attack".

● MasterCard pushed updates to Samsung Pay that changed the way how
ATC/AAC pair is presented. Before changes, each new request that
ended up with the AAC cryptogram got a subsequent ATC counter, e.g.
we could make three requests on a locked Samsung Pay phone, and a
MasterCard token would provide ATC= 0x0001, 0x0002, 0x0003, etc.
After the update, Samsung Pay freezes the ATC counter on the value
equal to the previous ARQC/ATC counter+1. For example, ff a customer
would unlock the phone and make a payment with ATC=0x0001, and
after that, a hacker would try to make three payments on the locked
phone, each time he would get ATC=0x0002.
● MasterCard started declining AAC cryptograms generated by Samsung
Pay and Apple Pay. That does not stop hackers from making
transactions using modified POS, as MasterCard still does not check
the CVMResults field, indicating that the phone was locked. Matching
this field with the MCC code allows declining inappropriate

31 | Page
 transactions. Also, MasterCard still accepts AAC cryptograms
presented by GPay.

No direct nor indirect communication were made with us by MasterCard

04/2021 – Visa is informed about the Cryptogram Confusion attack against mobile wallets

06/2021 – Apple is informed about all other vulnerabilities in Visa/MC Transport Cards

In August 2021 Apple had confirmed that they would make no changes.

10/2021 – MasterCard is additionally informed about vulnerabilities via the Bugcrowd portal

MasterCard is still investigating this report.

32 | Page
References
[1] https://drive.google.com/file/d/1KMvrdTgpw22Hvdgy4D_-ks_fW3WDEwT7/view

[2] https://jorgetp.github.io/assets/files/papers/USENIX21.pdf

[3]
https://i.blackhat.com/eu-20/Thursday/eu-20-Stennikov-POSWorld-Should-You-Be-Afraid-Of-
Hand-Ons-Payment-Devices-wp.pdf

[4]
https://www.theglobeandmail.com/globe-investor/personal-finance/customer-sues-cibc-over-
purchase-of-81276-car/article583383/

[5] https://eprint.iacr.org/2015/963.pdf

[6]
https://frankonfraud.com/fraud-trends/attack-the-weakest-link-fraudsters-break-emv-by-focus
ing-on-magnetic-stripe/

[7] https://murdoch.is/papers/ieeesp15beprepared.pdf

[8] https://murdoch.is/papers/oakland10chipbroken-poster.pdf

[9]
https://www.statista.com/statistics/749189/london-transport-journeys-contactless-payment-re
venue/

[10] https://www.snl.com/articles/400398395.png

[11] https://support.apple.com/en-us/HT202527

[12]
https://www.finextra.com/newsarticle/38081/digital-wallets-poised-to-overtake-contactless-ca
rds-as-instore-payment-of-choice-in-australia

[13]
https://www.ukfinance.org.uk/system/files/Fraud%20The%20Facts%202021-%20FINAL.pdf
Page 26-27

[14]
https://www.forbes.com/sites/thomasbrewster/2019/03/27/millions-are-being-lost-to-apple-pa
y-fraudwill-apple-card-come-to-the-rescue/

[15]
https://appsexposed.home.blog/2019/08/02/app-store-a-safe-haven-for-scammers-500-apps
-exposed/

[16] https://support.google.com/pay/answer/7644132

[17]
https://www.aibms.com/wp-content/uploads/2014/12/EU-Ops-1410003-CDA-Requirement-o
n-EMV-Cards-Issued-in-the-Europe-Region.pdf

33 | Page
[18] https://www.paymentvillage.org/blog/modern-emv-and-nfc-cardholder-verification-issues

[19]
https://www.surrey.ac.uk/news/visa-and-apple-pay-vulnerabilities-leaves-iphone-users-open-
payment-fraud

34 | Page