EMV Contactless is one of the widely used payment mechanisms all around the world. Despite being claimed secure by the card issuers and payment service providers, they do not come without security vulnerabilities. In this report, I talk about two attacks carried out by researchers in which they successfully exploit vulnerabilities in EMV Contactless. The first one is a spoofing attack in Mastercard by inducing failure in card authentication and bypassing integrity checks (2. Basin et al., 2023). Once this integrity check is bypassed, the CVM methods of the victim are downgraded or no CVM is required altogether, allowing the attacker to use the victim's card. Second attack is bypassing the limits in contactless payment mechanism by exploiting the vulnerability that the Card Transaction Qualifier data is not integrity protected (5. Galloway and Yunusov). The report also includes the recommended measures to prevent these attacks. The project work is a literature review of mainly these two research works.

Introduction

The EMV (Europay, MasterCard and Visa) protocol is the standard protocol used by more than 9 billion devices worldwide to make payments . This protocol is implemented by six card service providers in the world.

Contactless payment system is a form of payment done with credit cards, debit cards, or mobile phones using radio-frequency identification (RFID) or near field communication (NFC). The card just needs to be placed close to the terminal and the transaction occurs without any physical contact. Almost all the credit cards and debit cards in practice have the NFC functionality, which can be used for contactless payments. Contactless payment option is available in almost all of the terminals in practice. There is a limit to the amount of money for a transaction via contactless which might vary depending on the geography.

Although the card issuer and the payment service providers claim that EMV Contactless protocol is safe, there are vulnerabilities in the Contactless payment mechanism since it involves many stakeholders and has to support multiple legacy technologies. In this report, I am going to talk about two attacks successfully carried out in breaking EMV contactless payment. These attacks were carried out for research purposes by researchers.

• Spoofing attack by inducing authentication failures to bypass PIN verification for high-value Mastercard transactions.
• Exceeding EMV Contactless payment limits on Visa cards by man in the middle attack.

EMV Protocol Overview

For a transaction to occur, there are four stakeholders involved. First the card itself, second the terminal of a merchant, third the card issuer (banks) and the cardholder. In terms of a security point of view, it is important to establish trust between all these stakeholders mentioned. First the card has to be authenticated, i.e. it has to be a valid EMV card issued by an issuer. The data inside the card should be legitimate. Also, the terminal has to be trusted by the card as well. There is also the cardholder who needs to prove they are the right owner of the card. For making a transaction to take place successfully and securely, it is important to establish this trust.

The card and the terminal communicate with each other in commands and responses. The commands are sent by the terminal, processed inside the card and the terminal receives responses. The card stores different data ordered in a tree structure file called Data Object List (DOL). The terminal can issue commands to ask for these specific files and read the content inside the files.

Below, I have tried to give a general overview of how a transaction occurs. This is based on the EMV in a nutshell paper (6. van den Breekel et al. #11).

1. Application Selection

The EMV card supports multiple card service providers (like VISA, MasterCard, etc.) and each provider has their own variation of payment mechanism (also called kernels). Thus, the card and terminal agree on what kernel the terminal will use for the payment in the beginning.

• Terminal issues a command to the card.
• Card responds back with supported applications identified by their AIDs (Application Identifiers).
• Then the terminal selects one of the AID and activates the kernel to be used for the payment.

Figure 1: Initialization phase

2. Synchronization

Once the kernel is selected and activated, the terminal knows exactly where to look in the card (which files) to get the required data for the transaction to succeed. Also, the terminal learns the data elements required by the issuer and sends it to the card. The card’s response includes a list of input data fields that the card expects as input from the terminal with the GET PROCESSING OPTIONS command. These data fields are called Processing Options Data Object List (PDOL) and it constitutes information like terminal type, currency code, transaction amount etc.

The card’s response to the GET PROCESSING OPTIONS is the AIP (Application Interchange Profile) and AFL (Application File Locator). AIP indicates the card’s available functionality and AFL identifies the files and records in the card to be used for the transaction. Now the terminal knows the card’s capabilities and location where the files are recorded, it issues READ RECORD command to the card. The card responds back with PAN (Personal Account Number), CVM List, CDOL (Card Risk Management Data Object Lists), PKI related information (Card’s and Issuer’s PK Certificate), CA Public Key Index.

TTQ and CTQ

When the kernel is selected for VISA cards in Contactless, the card communicates to the terminal the parameters it needs to perform the transaction. Included are TTQ, transaction amount, UN, currency code and country code (“Acquiring: EMV Transaction Flow. Part 4: PDOL and Contactless Cards, Characteristic Features of qVSDC and qUICS”). Then the terminal replies back that information to the card. TTQ is a collection of indicators that the terminal has set to show the terminal’s capabilities, requirements and preferences to the card (“3. Breakthrough Payment Technologies”). It has bits like contactless MSD supported, EMV contact chip supported, offline only reader, online pin supported and so on.

Similarly, the card also sends the terminal its capabilities called Card Transaction Qualifiers (CTQ) after receiving TTQ. The CTQ in the card is set at the time of its issuance and determines what actions will take place at the point of sale when a transaction takes place. The CTQ includes information like is online pin required, is signature required, whether CDCVM has been completed and so on (“3. Breakthrough Payment Technologies”). CTQ is important for our second attack in exceeding the contactless payment limits.

Figure 2: Synchronization phase

3. Cardholder verification

In this stage, the terminal verifies if the person is a valid owner of the card. This is done on the basis of the CVM (Cardholder Verification Method) selected earlier in the synchronization phase. Depending upon different payment service providers and CVM supported by the card it can be one of the following methods.

1. Online PIN: The cardholder has to enter a PIN on the terminal pad for verification and the issuer checks the validity of the PIN.

2. On-device CVM: This form of CVM (also called CDCVM) is particularly used in mobile payment apps like ApplePay, GooglePay, SamsungPay etc. which provides fingerprint reader or face recognition options.

3. Paper signature: This is one of the old mechanisms of verification in which the cardholder has to sign in the purchase receipt and the cashier confirms the signature against the signature on the back of the card.

Once the CVM is carried out, the results are stored in TVR (Terminal Verification Results) which shall be used by the terminal in its risk analysis phase. The TVR is a collection of indicators that the terminal will set to show what incidents have occurred whilst processing the current transaction (e.g. card has expired, cardholder verification has failed, or online floor limits have been exceeded).

4. Card Authentication and Risk Analysis

These operations in the transaction occur together, hence they are described together as well.

In the AIP (Application Interchange Profile), the card tells the terminal which methods of authentication it supports. In both of the attacks under study of this project we have Combined Dynamic Data Authentication (CDA). In CDA, the static data of the card is authenticated using the public key of the card and the transaction data is also included in the hash verification. Also, it ensures that the transaction happening is from the authenticated card itself, which avoids any kind of race attacks.

The terminal calculates the bCDA value which indicates whether CDA is to be performed or not. If the bCDA value is False, then card authentication will not generate the signature for the card data and transaction details. It uses several parameters to compute bCDA but the important ones are as follows:

b_CDA = AIP AND valid(CA pk index) AND …

Cryptogram he terminal then sends a GENERATE_AC command to the card to compute the cryptogram with arguments which specify which cryptogram to use, whether to use CDA or not and few other data as specified by CDOL (2. Basin et al. #6).

The issuer and the card share a secret session key MK which is used to generate a session key S. The authentication occurs as:

• Extract the transaction relevant data elements from PDOL and CDOL1 and concatenate the resulting elements together as X.
• Compute the Application Cryptogram AC = MACS(X||AIP||ATC||IAD), where MAC is a block-cipher-based CBC-MAC using the key S.

Additionally, if CDA is used, the card also returns signature over response using its private key privC so that the terminal can check the authenticity of the complete message.

The cryptogram generation for CDA occurs as follows:

• Create a random nonce NC

• Concatenate the data elements PDOL, CDOL1, Cryptogram Information Data (CID), Application Transaction Counter (ATC), and Issuer Application Data (IAD) and hash them (using SHA-1) to build the Transaction Data Hash Code:

  TDHC = h(PDOL||CDOL1||CID||ATC||IAD).

• The TDHC is then further combined with the Application Cryptogram (AC, described later), the CID, and the nonce NC to build

  Y = AC||CID||NC||TDHC.

• Finally, Y is concatenated with the hash of the concatenation of Y and the terminal’s Unpredictable Number (UN), and then signed with the ICC’s private key to produce the Signed Dynamic Authentication Data(SDAD):

  SDAD = sign_privC(Y ||h(Y ||UN)).

  This signature protects the integrity of the transaction specific data and static data elements.

Figure 3: Card Authentication and Risk Analysis phase

Risk Analysis

In this section, the terminal verifies the certificates of the card, verifies the signature received and makes a decision whether to accept the transaction offline or request for online authorization or decline the transaction. The risk analysis takes in a lot of parameters during the risk analysis. For our attacks it is important to know the terminal factors in TVR, IAC-Denial, TAC-Denial bits in one of the parts of risk analysis. IAC (Issuer Action Code) and TAC (Terminal Action Code) are sets of action codes in the card and terminals respectively. Each of the bits in these codes have respective functions and based on how they are set, the card and terminal take action during the risk analysis phase.

The terminal performs risk analysis using the information provided in the TTQ and CTQ. It decides which steps to take next. If the terminal determines that the transaction does not need a Cardholder Verification Method (CVM), then it sends all information to the acquirer, card networks, issuer and awaits the response.

Limits in EMV Contactless Transactions

For contactless, up to a certain threshold CVM is not required. The risk of fraud is offset by the limits and the TTQ. Contactless transactions are managed by three limits on the terminal. These are the Reader Contactless Floor Limit, the Reader Contactless Transaction Limit, and the Reader CVM Required Limit. In turn, the Reader Contactless Transaction Limit is separated into two parts: the Reader Contactless Transaction Limit without Consumer Device Cardholder Verification Method (CDCVM) and the Reader Contactless Transaction Limit with CDCVM.

EMV cards have limits in NFC Contactless transactions. These limits vary based on card service providers and geographical locations. The following table shows the limits in England. We can see, for devices with CDCVM the limit is very high, 5500 pounds, which is for mobile payment systems like Apple Pay, Google Pay, etc. And for normal EMV physical card NFC payment (No CDCVM) it is just 30 pounds.

Table 1: EMV Contactless limits in UK. Source: (5. Galloway and Yunusov #10)

The full form of CDCVM is Consumer Device Cardholder Verification Method. In CDCVM, the cardholder verification is carried out in the consumer's device itself. For example, users can verify their identity in their phone with passcode, fingerprint or face id in payment systems like ApplePay, GooglePay etc. In these verification methods users don’t have to verify their identity in the terminal device.

Disclaimer: The report here is a case study in Embedded system security class during my Masters degree in Cybersecurity at ULB, Brussels. You can read the whole report here.

References

1. “Acquiring: EMV Transaction Flow. Part 4: PDOL and Contactless Cards, Characteristic Features of qVSDC and qUICS.” MST Company, 22 November 2020, https://mstcompany.net/blog/acquiring-emv-transaction-flow-part-4-pdol-and-contactless-cards-characteristic-features-of-qvsdc-and-quics.
2. Basin, David, et al. “Inducing Authentication Failures to Bypass Credit Card PINs.” USENIX Security Symposium, vol. 32, 2023. EMV Race, https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/information-security-group-dam/research/publications/pub2023/mastercard-usenix23.pdf.
3. “Breakthrough Payment Technologies.” EFTlab - 3. Breakthrough Payment Technologies, 7 October 2022, https://www.eftlab.com/post/the-use-of-ctqs-and-ttqs-in-nfc-transactions.
4. “EMV Glossary.” Payment Logistics, https://paymentlogistics.com/emv-glossary. Accessed 22 December 2023.
5. Galloway, Leigh-Anne, and Tim Yunusov. “First Contact: New vulnerabilities in Contactless Payments.” blackhat.com, 2019. blackhat.com, https://i.blackhat.com/eu-19/Wednesday/eu-19-5. Galloway-First-Contact-Vulnerabilities-In-Contactless-Payments-wp.pdf.
6. van den Breekel, Jordi, et al. “EMV in a nutshell.” 2016. Radboud Universitet, http://www.cs.ru.nl/~erikpoll/publications/EMVtechreport.pdf.
7. Hamill, Jasper. “Hackers can bypass £30 contactless payment limit and steal your money | Metro News.” Metro UK, 30 July 2019, https://metro.co.uk/2019/07/30/way-bypassing-30-contactless-payment-limit-10488754/. Accessed 23 January 2024.
8. Brewster, Thomas. “Exclusive: Hack Breaks Your Visa Card's Contactless Limit For Big Frauds.” Forbes, 29 July 2019, https://www.forbes.com/sites/thomasbrewster/2019/07/29/exclusive-hackers-can-break-your-credit-cards-30-contactless-limit/. Accessed 23 January 2024.
9. “'Contactless' fraud cases double in 10 months | The Independent.” The Independent, 11 January 2019, https://www.independent.co.uk/money/spend-save/contactless-card-fraud-increase-money-security-bank-account-a8722361.html. Accessed 23 January 2024.