Security measures in the EMV Contactless Specification

Prologue

Readers should be familiar with contactless payments. Some cryptography basics are also required:

  • Symmetric & Asymmetric cryptography
  • Public and private key concepts
  • Certificates and signatures
  • Diffie-Hellman key exchange
  • Common forms of attacks

Disclaimer

This blog post is not intended to promote contactless payments. By all means, you should disable contactless and online payments (or erase your CVV code on the back) to mitigate theft risks.

Introduction

Contactless indicator Contactless symbol

The above marks might look familiar. The indicator (resp symbol) is present on contactless capable payment cards (resp terminals). These marks represent compliance with the EMV contactless communication specification1.

But the EMV contactless specification expands far beyond a communication protocol. It features many other sections, down from recommendations about the specific cryptography algorithms and key sizes up to the entire payment scheme structure.

In this article I will explain how some of these measures prevent your card from getting cloned or tracked by a third party.

Payment scheme

Actors

We will consider the following actors involved in a transaction:

  • Certification Authority: it is the payment scheme (eg: Visa), referred to as CA
  • Issuer bank: The payer’s bank
  • Acquirer bank: The payee’s/business’s bank
  • EMV Card: the payer
  • Terminal: the payee

Certificate chain

Both banks have been approved by the CA. They own a set of key pairs and certificates signed by the CA.

The EMV Card has a key pair and certificate signed by the issuer bank. It is bound to a Primary Account Number, a usually 16 digits number. This PAN identifies the issuing bank and the cardholder’s account.

The terminal has been approved by the acquirer bank and is directly connected to it.

Transaction steps

The communication between the terminal and the card is kept in the field as briefly as possible. Most verification operations are performed after removing the card and can be asynchronous. The actual communication flow would be very confusing and complex.

We will consider the most common conditions on the transaction:

  • No additional user input is requested (eg: PIN, 2FA)
  • The terminal requires online confirmation
  • The card is genuine and both banks confirm the transaction

In this case, security is provided by:

  • Card authentication
  • Transaction authorization

Step by step transaction

Let’s say nothing goes wrong and the steps are as follows:

  1. The card is physically brought within powering range of the terminal. The terminal’s field powers on the chip 2
  2. The card and the terminal perform a handshake to encrypt their communication. From that point forward, all sensitive data are encrypted with the established session key.
  3. The terminal requests various data from the card, including its public key along with its chain of certificate for authentication
  4. The terminal sends the transaction information and requests a signature from the card
  5. The communication stops and the terminal displays “Remove card” The card is removed and the following steps happen online
  6. The terminal sends all applicable transaction data to the acquirer bank
  7. The acquirer contacts the issuer for authorization.
  8. The acquirer sends confirmation that the transaction has been approved to the terminal.

Transaction flow

All the attacks we will consider are on the card. They can happen between steps 1 and 5.

Attacking the card

Attacks possible on the physical layer

The physical communication protocol is described in ISO/IEC 14443 1-4, the same standard as for most NFC devices.

This standard requires the devices to be less than 10cm apart for the field to be powerful enough for a passive device. However, depending on the ambient noise, the signal could be decoded from up to 3 meters away 3. So eavesdropping could be possible from a reasonable distance.

Besides eavesdropping, we could also consider these attacks:

  • Physical cloning
  • MITM
  • Replay
  • Relay

Physical cloning

Let’s make the assumption that an attacker was able to physically clone your card. His clone has all of your card’s sensitive data, including private key.

Even then, both of you could not use a card bound to the same account in parallel. As soon as both cards complete a transaction, the issuing bank would be able to tell.

Cloned card

The reason for this lies in the transaction payload signed by the card. Before signing it, the card adds some of its own data, including a form of transaction counter. The cloned card could perform as many transactions as the bank’s security would allow until the genuine card performs a transaction with a stale counter. Which would not be not much with most modern banks, and maximum 50€ in France.

MITM Attacks

MITM Scenario

With a faraday4 cage/shield isolating the terminal and malicious devices, we could perform a MITM attack. The attacker would perform the handshake with both devices and be able to read and modify all communications.

However, the card performs the handshake with its certified key pair, which the attacker does not have. As a result, the terminal fails to authenticate the handshake key provided by the attacker. The transaction is cancelled.

In the case of contactless payment, the security provided is limited because the card is a passive device.

Eavesdropping: tracking

Handshake diagram

After the handshake, the attacker cannot figure out any of the encrypted data. But we’ve just said that the card performs the handshake with its unique key pair. As a result, he could be able to track where and when each card is used by logging all the public keys he catches.

This is why researchers from EMVCo came up with a new handshake protocol: Blinded Diffie-Hellman5. Instead of using the plain public key, the card first derives a new public key from it with a random factor. Once the shared secret is established, it can provide the reader with its actual public key and blinding factor for authentication.

The attacker would be unable to determine the public key from the derived key, the same way he would be unable to determine a private key from any public key.

Replay attack

Replay scenario

Assuming an attacker does not own an approved payment terminal, but wants to get some transaction data signed by a card for later use.

We could imagine an attack where:

  1. The attacker interacts with a terminal to retrieve some transaction data, but cancels the transaction
  2. Acts as a terminal in the vicinity of the target and get it to sign the transaction data acquired
  3. Replays the target’s responses to the terminal for the same transaction

This attack is prevented by the reader including an unpredictable number in the transaction data6.

Relay attacks

Finally, we can consider a relay attack, where an attacker acts as a proxy between an unsuspecting cardholder and a genuine point of sale. The scenario would be very similar to the presented MITM attack, except the cardholder would not even be making a transaction. It could happen anywhere in a public space.

Relay scenario

The only way to prevent such an attack would be to allocate a restricting time window for the reader to transmit to the card. Relayed transactions have been performed on EMV cards with transaction times of up to 52 seconds.

The EMV Specification Book A v2.11 specifies a maximum reader transmission time of 100ms7.

While the latest specification prevents such attacks, cards might not implement it yet. Which is why you should either store your credit card in a faraday cage or disable contactless payments.

Conclusion

The EMV specification takes transaction security very far to prevent widespread and automated attacks. It is not reasonable to attack contactless payments without compromising a POS. The main risks are outside the scope of the EMV specification: theft and social engineering attacks. The only way to protect yourself against them is by using as many authentication factors as possible and keep them secret. Contactless payments offering you none that you can protect, it’s the most vulnerable method and that is why its usage is restricted8.

Sources

  1. The EMV contactless specification is one of many developed by EMVCo. You can find it here. EMVCo is an organization that develops and maintains technical specifications to facilitate worldwide interoperability of secure payments. In case you were wondering, EMV stands for Europay, Mastercard and Visa, its founders. ↩︎

  2. The card is a passive device: it does not have its own power supply. An energizing field is produced by the terminal to power it up. ↩︎

  3. This paper presents its experimental results in Table 1. The author managed to eavesdrop on both channels from a 3m distance. ↩︎

  4. See wikipedia. ↩︎

  5. Blinded Diffie-Hellman by Duncan Garrett and Michael Ward. Non-free book here Mentioned in EMV Contactless Book E: BDH Key Agreement. ↩︎

  6. See EMV Contactless Book E: Recommended Application Cryptogram Input Data. ↩︎

  7. See EMV Contactless Book A: Reader Tariff. The card must be present in the field for a maximum of 500ms, including maximum 100ms for the readers transmissions and 400ms for card transmissions. ↩︎

  8. Contactless transactions are limited to 50€/transaction and have ceiling limits specific to each bank. ↩︎