Modern EMV and NFC cardholder verification issues
The Cryptogram Confusion Attack

Introduction

On the 15th of October, the UK will be increasing Tap & Go limits from £45 to £100 but what does that mean?

It means that UK cardholders can pay for goods up to £100 in stores using contactless cards without providing any cardholder verification such as PIN or signature. In addition, you’d be able to do it five times in a row before most banks ask you to insert a card using the chip.

Ok, but what does that REALLY mean?

This means that the government and banking industry are sure that lost and stolen fraud has decreased enough so that limits can be increased without significant fraud losses. The most popular type of contactless fraud is when someone finds or steals a contactless card and uses it in store. Now each contactless operation is limited to £45 and it will increase to £100, does that mean that overall losses associated with evil-minded “entrepreneurs” will increase twice as well?

We will try not to speculate on this topic quite yet. Especially when a lot of people are polarising the “cash or card” question: when one group is avoiding cash and coins by any means, another group is more concerned about privacy issues related to a “cashless only” future.

Instead of taking anybody’s side in this controversial topic, we will remind you how easy it is to pay using blocked cards and how easy it would be to bypass these “imaginary” £100 “Tap & Go” limits for fraudsters. Let us show you how many misconfigurations still present are in modern Visa and MasterCard cards.

Attacks

We will walk through two attacks. First, we show how hackers could pay with Visa cards even after exceeding the PIN tries on the card, typically set to three. In the second attack, we show how it’s possible to bypass the limit of three attempts to guess a correct 4-digit PIN code number and conduct an attack that tries all possible PIN code digits.

Why do we discuss these attacks together? Both attacks utilise flaws in EMV specification and EMV implementations in different banks. Both attacks also require the Man-in-The-Middle technique to manipulate different fields during the communication between the card and the terminal. For the NFC MiTM attack, you can use two PN532 NFC readers or two Android-based phones equipped with NFC readers. Intercepting and changing the EMV data is a bit more tricky. The main problem here is latency and delays that can cause the termination of communications. For our demonstration, we will use the project of a pioneer of EMV attacks – Omar Choudary from the University of Cambridge.

Attack 1. The Cryptogram Confusion Attack or how to pay with locked cards.

Almost every Visa and MasterCard card can verify PIN codes themselves, this is called “Offline PIN Verification”. For most cards, if the cardholder enters the PIN incorrectly three times, it will restrict the card functionality. After that, the card informs the bank and POS terminals about the incorrectly entered PINs. Sometimes that limits the NFC interface, as the card should verify the next transaction only using an online PIN that the issuing bank will check online, and the NFC interface does not have this feature.

We have had this experience ourselves. Having exceeded the number of PIN tries, we were unable to pay using NFC or chip, and couldn’t reset the PIN tries counter at an ATM. With that background, how could someone bypass this deadlock?

Look at the NFC communication between the card and the reader:

T->C
00a404000e325041592e5359532e444446303100
C->T
6f41840e325041592e5359532e4444463031a52fbf0c2c612a4f07a000000003
1010500a566973612044656269748701019f0a080001050100000000bf6304df2001809000
T->C
00a4040007a000000003101000
C->T
6f6c8407a0000000031010a561500a566973612044656269748701019f38189f
66049f02069f03069f1a0295055f2a029a039c019f37045f2d08656e65736672
64659f1101019f120f566973612044656269742043617264bf0c139f5a053108
2608269f0a0800010501000000006283

The last card’s response indicates that the card is invalid for NFC operations, as 6283 APDU response stands for “Selected file invalidated”. But if we will change the 6283 to 9000 ,response that everything is ok, that is what will happen next:

T->C
00a404000e325041592e5359532e444446303100
C->T
6f41840e325041592e5359532e4444463031a52fbf0c2c612a4f07a000000003
1010500a566973612044656269748701019f0a080001050100000000bf6304df2001809000
T->C
00a4040007a000000003101000
C->T
6f6c8407a0000000031010a561500a566973612044656269748701019f38189f
66049f02069f03069f1a0295055f2a029a039c019f37045f2d08656e65736672
64659f1101019f120f566973612044656269742043617264bf0c139f5a053108
2608269f0a0800010501000000009000
T->C (Terminal sends a Generate AC request, asking the card to provide a cryptogram)
80a8000023832136a04000000000000100000000000000082600000000000826211008000cf8dc7400
C->T (Card responds not with an online cryptogram, but with a decline cryptogram 9f270100)
774082020000940808010100100102009f100706011203800000570e43499210
50119006d2206221862f5f3401009f2608b65f41f7509ea1449f2701009f360200a39000

After that fix we see that the card responds not with an online ARQC cryptogram, but with a decline AAC cryptogram. You can read more about different EMV cryptograms here: https://www.emvco.com/wp-content/uploads/2017/05/A_Guide_to_EMV_Chip_Technology_v2.0_20141120122132753.pdf.

This is also indicated in the 9f10 field that should be processed by the issuer:

[9F10 (issuer application data)] 06011203800000
  [Card verification results] 03800000
        [Byte 2 Bit 6 = 0, Byte 2 Bit 5 = 0] AAC Returned in GPO/first GENERATE AC

However, the card still responds with the consecutive ATC. What if the algorithm for generating the AAC cryptogram is exactly the same as for the ARQC cryptogram? The only way to distinguish these two cryptograms for the issuing bank would be to check a CVR field and ensure that the cryptogram type is correct. Not a big fan of theories, we got straight into tests. We changed the cryptogram type from 9f270100 to 9f270180, the online ARQC cryptogram, and voila!

This tampering is only possible with Visa cards, as MasterCard mandates the CDA Offline Data Authentication scheme for all of their contactless cards. And this will prevent hackers from tampering with any data. Next, it became obvious that many banks (around 30% based on our current score) do not check the cryptogram type in the IAD/CVR field. Hackers would not be able to tamper that field simply because it is important enough to be a part of the payment cryptogram, and its tampering will cause a cryptogram’s rejection.

Attack 2. PIN codes brute-force

Let's talk about how banks reset the PIN tries counter on your card. You may need to choose the “PIN reset” option in the ATM, or your card may allow you to reset the PINin online or mobile banking, but most banks reset PIN tries automatically. Another critical requirement – the PIN should be authorised online. That is why in their PIN reset instructions, many banks suggest using ATMs as they always check PINs online. With the payment terminals on the other side, it’s impossible to tell whether it will verify the card’s  PIN online or not. If the issuing bank should reset the PIN counter back to three or five tries and the PIN code is checked using the HSM in real-time, the issuer will send an “Issuer script”. This is an encrypted code to carry out some actions on the card, such as resetting the PIN counter. During the EMV authorisation, your card waits for the response, dipped in the reader. That is when the payment terminal passes the Issuer script from the bank to the card. If the script is executed and successful, the card also will indicate this in further transactions so the issuer will confirm that card has received and interpreted the script.

Another interesting case was brought to our attention when we tested cards’ behaviour after entering three wrong PINs. This particular card’s issuer sent the Issuer Script even if the issuing bank rejected the transaction due to entering a wrong online PIN. That quickly ended in a feasible attacking scenario:

1.     Checking PIN offline, entering consecutive PINs from the list of 0000-9999 combinations.

2.     If the PINs were all wrong, the PIN tries counter will be set to 0.

3.     Now, we can check the next PIN online or simply use Chip & Signature verification scheme. This will cause an Issuer’s bank to send the “PIN Tries Reset Issuing Script”. And we can continue again from the first step. 

Conclusions

We have shown how easy would be for hackers to make payments even without worrying about contactless limits. For example, hackers could pay using a chip or NFC even if the card’s PIN tries are exceeded or they could bruteforce PINs offline without sending too many requests to the bank.

EMV issues have concerned security researchers for about 20 years. Visa and MasterCard even migrated some legacy issues like AAC cryptogram confusion in the most modern forms of payments such as Apple Pay, Samsung Pay and GPay mobile wallets. But big businesses like Visa and MasterCard are not in any rush to fix these flaws. 

In the end, let me quote an expert in the "cash vs card" area: "The public has only one option in situations when payment giants fail to act - stop using the service"