First Contact: Attacks on Google Pay, Samsung Pay, and Apple Pay

Background

The evolution of the EMV standard was as follows. At first, there were chip-based smart cards. Then these cards had been equipped with antennas and transformed into contactless cards inheriting almost all EMV functions. But this was not enough for card brands, and in 2011, the first contactless payment function over NFC was added to Google Wallet.

Google used the Host-Card Emulator (HCE) approach: unlike a smart card, the end device doesn’t contain all the private and symmetric encryption keys but downloads from time to time Single-Use Keys (SUK) for each subsequent operation. In accordance with this approach, phones with Google Pay won’t allow you to make more than twenty transactions without an Internet connection. In 2012, Samsung and Apple introduced their wallets that employ the Secure Element technology. Overall, Secure Element is a physically and logically secure chip that guarantees protection against interception, reading and rewriting of secret keys. This chip is used to create 3DES EMV cryptograms and sign data using asymmetric RSA, similar to smart cards.

Earlier, Sławomir Jasek has demonstrated that Google Pay could be transferred from one device to another one. Furthermore, it was possible to receive SUK keys from Google servers, not to the original device. Peter Fillmore has examined in detail the Apple Pay device. In 2017, your humble servant has shown how to replay the Apple Pay online cryptograms at the Black Hat USA conference.

Two years ago, I started researching the security of NFC payments on mobile wallets. At that time, Google Pay was the only wallet making it possible to pay using a device with a locked screen. I quickly found a way to deliver an attack that I had previously used against contactless Visa cards to bypass NoCVM or Tap & Go limits. All I had to do was activate the screen on a locked phone. If the phone is in the owner’s pocket, this can be done by sending a command over Bluetooth or Android Beam.
In late 2019, Samsung and Apple introduced support for ‘transit schemes’ in major metropolitan areas: New York, Tokyo, and London. Transit schemes are a little bit more complicated than traditional in-store NFC payments. In many public transit systems, the fare depends on the trip distance, and the final amount is calculated based on the subway entry point and exit point. Therefore, it would be incorrect to charge the standard amount when a card or wallet is ‘tapped’ for the first time. Next, even though turnstiles are connected to the Internet, they don’t request an immediate transaction authorization since it takes a long time. Instead, the authorization is taking place with a delay. Hence the most modern offline authentication CDA scheme is mandatory for transit schemes to prevent fraud. CDA operation principles were described in detail in the article First contact: An introduction to credit card security.

Lat problem with Apple or Samsung digital wallets was that you must unlock the phone every time you approach a subway turnstile. Very inconvenient, isn’t it? That is why bot vendors made it possible to pay transit fares without unlocking the phone.

Tokenization

Mobile wallets are possible because of the tokenization technology: when a card is added to the mobile wallet, the card details are sent to the international payment system that verifies all the details and creates a ‘virtual card’. Such a card can operate only over NFC and only on the device the card was added to. But that’s in theory.

Digital wallets have an important advantage over card payments: the use of tokens is limited. If a token is compromised, attackers cannot use the stolen virtual card data to create a magnetic stripe clone or pay with such a virtual card on the Internet. That is why banks, card brands, and major e-wallet manufacturers (Apple, Google, Samsung, Huawei, etc.) unanimously claim that mobile wallets are 100% secure.

But when a token replaces a card, the issuing bank is largely excluded from transaction authorization and risk management operations. Of course, it receives information about the merchant location and type and transaction amount and date. However, all cryptographic functions and analysis of EMV fields are transferred to the tokenizer (Visa VTS or MasterCard MDES). The code that is executed in the mobile wallet is also written, audited, and certified by one of the international payment systems. In other words, Apple or Samsung seemingly have nothing to do with their payment systems: they act as a facade, while Visa or MasterCard do all the work for them. As a result, it becomes more difficult for the issuing bank to detect fraudulent transactions due to a lack of data.

Therefore, transactions involving digital wallets almost never become occasionally blocked by antifraud systems (unlike those involving bank cards). That is one of the main problems: entities responsible for the payment process are hidden inside this process, while external entities (i.e. issuing bank, merchant, and mobile wallet) have limited decision-making powers.

Attacking Samsung Pay

Samsung has chosen an easy way to allow payments on transport. NFC antenna is enabled on the locked phone when a transit card is activated. All checks performed to distinguish between a supermarket payment terminal and a subway terminal occur during the EMV/NFC Risk Management phase.

So, I quickly added a Visa card to my Samsung phone and made it a transit card. Then I armed myself with a Proxmark3 and went to the subway to record transaction data and compare requests from subway terminals with requests from ‘regular’ payment terminals.

The main commands, in this case, are the terminal’s request to generate a cryptogram (Generate AC) and the wallet’s response:

For terminals that authorize payments online, Visa contactless cards don’t require offline authentication. But it’s mandatory on transport, so the phone checks if the CDA scheme is required. Also, the phone checks the amount: if it’s not equal to 0.00, then the transaction won’t go through. But the phone doesn’t check the merchant name or the Merchant Category Code (MCC).

If the payment is made using a ‘regular’ terminal, then the offline authentication won’t be required, and the amount will be different from 0.00. In this case, the phone will return the following response:

I decided not to despair, added a MasterCard card, returned to the subway, and performed the same operations:

For MasterCard cards, offline data authentication is mandatory in almost all countries, and every contactless card support it. If the authentication is failed, the terminal must abort such a transaction. Therefore, the phone checks two fields: the amount and the MCC code.

If the payment is made using a ‘regular’ terminal, again, the amount will be different from 0.00, and the terminal code won’t belong to the “Transit” category. In this case, the phone will return the following response:

This seems more interesting. To remind: a cryptogram is a 3DES HMAC generated based on some fields provided by the terminal in the Generate AC request and values contained in the card (e.g. ATC). My first guess was: what if the keys and calculation algorithm for the AAC cryptogram are exactly the same as for ARQC? After all, the transaction counter increases every time by 1, even if the AAC cryptogram is returned. If I change the 9f27 field to 0x80, the cryptogram will be accepted by the terminal and sent to the MasterCard tokenization host for authorization. And if this host doesn’t check flags in the CVR field that still indicates that the cryptogram type is different, the transaction will be approved.

Sounds like a plan, but I had a problem: the modification of any fields during the communication between the terminal and the wallet will be detected in the CDA offline authentication. So, I used a technique recently discovered by Swiss researchers. They found out that mandatory offline authentication could be bypassed by pretending to be a Visa card and used this technique to bypass the PIN.

The first attack plan is ready:

1. I take the man-in-the-middle device to modify the data between the phone and the terminal;
2. I perform a Card Brand Mixup attack: a MasterCard card pretends to be a Visa card (to find out how to do this, check the study entitled “Card Brand Mixup Attack” (PDF)); and 
3. At the final stage, I deliver the Cryptogram Confusion attack: when the wallet returns an 0x00 cryptogram (AAC), I change the field value from 9f27 to 0x80 (ARQC). I was pleasantly surprised that the Cryptogram Confusion attack was successful and the MasterCard MDES approved the transaction. Below is a video of this attack.

Is it possible to make payments using Visa and other cards (e.g. American Express) if the phone is locked? I couldn’t find any other way to get a cryptogram but to make an authorization request for the amount of 0.00. So, I decided to use the Transaction Stream Manipulation attack. During this attack, the data is substituted not between the terminal and the card or wallet but between the terminal and the acquiring bank: in the ISO8583 Authorization Request. In this case, the attacker has more possibilities to manipulate the fields. For instance, the “amount” field appears in this request twice: first time in the [55] field (where all the EMV fields are present) and the second time in the [04] field (where the actual withdrawn amount is specified).

In this case, attacks on other cards, including Visa, look as follows:

1. You request a cryptogram for 0.00 in the same way as a subway terminal requests it; and 
2. You generate an ISO8583 request, where you indicate the correct fields (amount = 0.00, cryptogram, etc.); but in the [04] field, you indicate the amount you want to withdraw from the card.

Even though the wallet with the Visa card transmits information that the phone wasn’t unlocked, Visa Tokenization Service approves this transaction.

Attacking Apple Pay

At some point, Apple Inc. announced that locked-screen payments had been implemented in its phones months ahead of its competitors. However, for a long time, I couldn’t check their security. The main problem was that Apple phones activate the NFC field in some mysterious way. And ‘regular’ terminals or contactless readers could not initiate the payment. I continued researching on the Internet how Apple VAS (Value Additional Services) operates and tried, with the help of colleagues, to reverse Apple Pay binaries (I took their names from Peter Fillmore’s presentation). Proxmark3 didn’t record any additional data during my subway experiments, which left me confused.

After finishing my tests with Samsung Pay, I still didn’t know what to do with Apple Pay and was close to despair. The only terminal I could use at that time was the subway turnstile terminal. So, I hatched the following plan: if I manage to record the transaction cryptogram in the subway, but the transaction itself doesn’t go through, then I will return home and try to insert the cryptogram into the Transaction Stream (as was done in the Samsung + Visa variant). After several attempts, I replicated the same attack against the Apple + MasterCard combination.

Finally, one smart engineer advised me not to use Proxmark3 but to take “something more reliable”, e.g. HydraNFC. I followed this advice and quickly noticed ‘something’ in the traffic: 15 bytes that were sent prior to the first commands. At that time, I couldn’t believe that mere 15 bytes could unlock NFC on an iPhone since I had read a lot about PKI used by Apple in VAS in respective patents. But that was true: just 15 bytes – and the phone reads data over NFC even from discharged devices.

A MasterCard set as a transit card in Apple Pay generates a cryptogram as follows:

Unlike Samsung, Apple returns an online cryptogram even if the amount is not equal to 0.00. Apple engineers claim that they use this feature or intend to use it in the future (i.e. it’s not a bug).

However, when the MCC code is modified during the MiTM attack, the transaction will be rejected due to the CDA authentication failure. After June 2021, MasterCard has fixed the vulnerability making the Card Brand Mixup Attack possible, so you won’t be able to pay with such a card at any terminal you want. But I still was able to deliver Transaction Stream Manipulation attacks.

What about Visa cards? You can use a locked iPhone to pay with them in any supermarket in the world; all you have to do is substitute a few bytes when the terminal and the phone are exchanging information. Perhaps, you have already read about this: researchers from the Universities of Birmingham and Surrey discovered this vulnerability independently from me around the same time. It still exists, even though Visa only needs to add one small check to its tokenization service to fix it.

Attacking Google Pay

We already showed in 2019 how to make payments in excess of NoCVM limits using a Google Pay wallet on a locked phone with Visa cards: all you have to do is change the bit in the TTQ field indicating that the cardholder verification is required. But during that research, we could not bypass restrictions on MasterCard cards, so I decided to try again. I used an old attack described by Michael Roland in 2013: Pre-play and Downgrade (in the previous article, I mistakenly wrote that this attack was invented by Peter Fillmore in 2014, but I was wrong).

It was a mystery to me why the M-STRIPE mode is still supported by Google Pay wallets for all MasterCard cards. I decided to explore it a little deeper: examine the maximum entropy, protection against ATC jumps, and other security mechanisms.

My findings were as follows.

1. The maximum entropy for the cards is 1000 or 10,000. No other settings were found. To remind: 1000 requests are required to completely clone a card or wallet with an entropy of 1000, and it takes about a minute. After that, the attacker doesn’t need the original phone: purchases can be made using the cloned information. The number of transactions depends on other enabled security features.
2. NoCVM restrictions on a locked phone can be bypassed by replacing one bit in the request from the terminal; this allows to make payments over 50 USD. Some terminals, however, have a separate configuration that specifies the maximum payment amount in the M-STRIPE legacy mode.
3. Unlike regular cards where the ATC counter operates sequentially (0001, 0002, etc.), MasterCard has implemented the so-called Cryp toATC for mobile wallets. When you intercept commands, they look like random values consisting of 2 bytes: A56D, F1A1 etc. During the detokenization process, MasterCard converts these values into consecutive numbers. However, my transactions weren’t blocked even if the jumps between pre-recorded values were more than 30-50-100 transactions.

Pursuant to the new PSD2 requirements in Europe, Android limited the number of transactions on a locked phone to five (currently, it’s three or zero, depending on the country). This made me think: if MasterCard and Google don’t validate ATC jumps after recording only five transactions, what is the probability of replicating one of them successfully?

Let’s use the Bernoulli distribution formula.

If entropy is equal to 1000 and you make 50 attempts to pay in a supermarket, the probability of getting a random number from five recorded numbers is 14%. For 100 attempts, it’s 26%. It’s much worse if the criminals have access to the Transaction Stream. In that case, each recorded transaction can be monetized because the attacker can create an authorization request and specify in it both a random number and CVC3/ATC values.

Furthermore, if the attacker who has only a token (i.e. 16 digits of a virtual card and its expiry date) and has access to the Transaction Stream could also commit fraud as there is no protection against enumeration of ATC/CVC3 pairs. A maximum of 65,535 attempts would be required to create and successfully authorize a fraudulent transaction.

So, the scammers just have to be persistent (i.e. tap the card in a supermarket 50-100 times, waiting for a successful attempt or send authorization requests to the MasterCard MDES tokenization servers). Too bad, but ultimately they are guaranteed success.

We even recorded a video and explained in detail how the attack works.

Conclusions

I have identified several ways to attack stolen digital wallets – proved that the device can be used for payments without unlocking. I also found a new interesting attack on the EMV protocol: Cryptogram Confusion. It can be used to attack not only mobile wallets but also chip-based/contactless cards.

I managed to make a few payments using cloned Google Pay transactions with a linked MasterCard card despite the limit of five attempts.

But when I contacted mobile vendors and international payment systems, the results were pretty disappointing:

1. Google was notified about these security holes in February 2021. They responded that they know the problems and intend to prohibit locked-screen payments. After February 2021, this was implemented by introducing a separate option in the NFC settings. Also, the developers have reduced the number of transactions with a locked phone in all regions. The rest of the vulnerabilities were ignored.
2. Apple, Samsung, and MasterCard were notified in the spring of 2021. Apple responded that 15 bytes used to activate NFC provide enough protection for users. All mobile vendors said they had no right to change the wallet code and asked permission to share my findings with the payment brands. I gladly granted the requested permissions, and since then, my LinkedIn page was repeatedly visited by big bosses from all international payment systems – but no one ever contacted me.

Last summer, MasterCard not only fixed the vulnerability exploited in the Card Brand Mixup Attack discovered by the Swiss researchers but also closed the security hole, making it possible to perform the Cryptogram Confusion trick. I discovered this by accident in October 2021 whilst preparing a presentation. In addition, MasterCard has added the MCC field to the cryptogram in some regions. That makes MCC spoofing impossible even during a Transaction Stream Manipulation attack. The ATC/AAC presentation method in locked Samsung phones has changed, which indicates a patch. I was able to identify the patch version from Samsung (update MPBP 1.2.2 of May 27, 2021).

Visa doesn’t care much about the unfixed possibility of making payments on stolen and discharged Apple phones, nor does it care about Transaction Stream Manipulation risks. They believe in machine learning and risk-based models and focus on business development and other exciting opportunities rather than on client security.

I have only read official answers from Visa and MasterCard in the article that Thomas Brewster had written about these attacks.

The following attacks still can be performed:

1. Visa transit card + Apple Pay: unlimited payments on a locked or stolen device even if the battery is flat. It’s also possible to make payments using Visa + Google Pay wallets; nothing has changed since 2019;
2. MasterCard + Google Pay: transactions can be cloned if the stolen information is sufficient to make a certain number of payments; and 
3. Other [card + wallet] variants: attacks are possible only if you’re able to manipulate the data in the Transaction Stream.

To protect against payment fraud involving locked phones, the best solution is to check the merchant category and amount against the CVR values:

• user paid 100 USD, the phone was unlocked, the merchant is a supermarket – no problem;
• authorization for 0.00 or withdrawal of a large amount, the phone isn’t unlocked, the merchant is public transit – no problem either; or 
• authorization for 0.00, withdrawal of a large amount, the phone isn’t unlocked, the merchant is a supermarket – this is suspicious, and such transactions should be rejected.

What should issuing banks do? I’ve heard several times that the issuing bank can request additional information for tokenized transactions for the decision-making, including EMV fields that normally remain inside the tokenization service. I can’t comment on how difficult this procedure is and how much it costs, as all Visa and MasterCard services are subscription- or fee-based.

What should clients do? Imagine that you are the owner of a mobile wallet; you lost your phone and didn’t block the default or transit card. After some time, attackers withdrew 1,000 USD from your account using one of the above techniques. What’s next?

1. You call the bank and ask them to block the card and start the investigation.
2. After some time, the issuing bank tells you that it has no information that the transaction was fraudulent. Perhaps you have disclosed the PIN from your phone?
3. Your attempts to contact mobile vendors (Apple, Samsung, or Google) are fruitless: they claim that payments are possible only for limited merchant categories and in limited amounts. Perhaps you have disclosed the PIN?

So, what can you do in such a situation? Stop using insecure products!

In the past year, I managed to confirm my hypothesis: developers of mobile wallets pretend that they have created “the most secure forms of payment” by taking away from issuing banks decision-making powers in terms of wallet issuance and transaction authorization. Concurrently, they deny any responsibility in case of fraud (or even a possibility of fraud), shifting the blame onto global payment systems.