6 min read

The Challenges and advantages of EMV Tokenization

Picture of Martin Rupp (guest) Martin Rupp (guest) : 18. July 2019

EMV CSG Tokenization
The Challenges and advantages of EMV Tokenization

EMV is short for EUROPAY-VISA-MASTERCARD. This term is used to refer to standards that have been designed to improve the security of credit and debit card transactions by using chip technology for payment cards.

In addition to EMV standards, some countries use additional security features like “Chip and Pin” in the United Kingdom or “SECCOS” in Germany with their payment cards and systems. 

Tokenization is the practice of substituting dummy information (aka token) in place of sensitive information (like payment card information).

Here are some quick facts about Tokenization:

  1. Tokens are created, stored, mapped and unmapped inside a secure system named a Token Vault;
  2. The process of detokenization maps the token back to the information it is protecting
  3. Companies providing Tokenization and Detokenization services are usually referred to as Token Service Providers.

Tokenization looks like a simple process. However, it can have deep implications in terms of security and especially its use with EMV. This article will describe these challenges. 

Tokenization in EMV is fully explained by the “EMV® Payment Tokenisation Specification,” which is freely available on the EMVCO website.

Tokenization and EMV card preparation

In a typical EMV personalization scheme, EMV data is prepared from personalization files (EMV personalization data, where all parameters have been given in advance depending on the bank issuer), and from keys that have been generated by a complex system (key ceremony), involving the exchange of the card manufacturer keys and the bank issuer keys.

A “standard” EMV personalization is explained in the “CPS” (Card Personalization Specification) standard. It contains a certain number of tags that must follow a specific logic scheme. 

Payment card data is stored at an EMV personalization center, which is usually an extremely secure building. The data is ciphered within personalization machines and cards are printed using huge card printers that are equipped with smartcard couplers. The data is then deciphered and stored in the card’s embedded chip. 

The chip of a typical EMV credit card contains public information that anyone can read without special authentication. For example, programs like CardPeek are able to read such information.

Here is an example of the information that can be retrieved:

Tokenization-Info

As you can see, the CVM (Card Verification Method) is publicly available. Security specialists acknowledge that this should be treated as a security issue because it has allowed fake cards (card transplants) using EMV to perform fraudulent offline transactions. 

EMV tokenization is a vast and ongoing program. According to the terms of the Consortium: “EMVCo recognizes that what is being progressed today [the token technology] is comparable to how the industry came together to develop and implement the required infrastructure for magnetic stripe, chip-based and NFC payments on a global scale.” [1]

We could see only tokens stored in the chip of the credit card itself in the near future. These tokens would replace the personalization tag and the information within the tokens would be useless to attackers. This would not exactly change the EMV standards but would also force payment transactions to be online so that the tokens could be un-mapped and verified. During card preparation, the data would be sent to the token vault and the tokens would be substituted to the real information.

Offline transactions within the era of mobile payments would then belong to the past.

Apple Pay, a rival of EMV, is already using tokenization to store credit card data inside chips. When a credit card is added, this is not a PAN that is added. Instead, it is the DAN, an Apple Pay token that represents the PAN.

Tokenization of EMV Transactions

The PCI Council once remarked: “in EMV environments, the PAN [primary account number] is not kept confidential at any point in the transaction” [2]. The largest credit card data breaches in the U.S were found at the merchant or processor (host) level in a non-EMV controlled environment.

Of course, it is possible to create a point-to-point (PTP) encryption between the card and the processor for the entire transaction. However, this comes at a cost and is a valid reason why tokenization would be more preferable to use.

The PCI council criticizes the lack of encryption in EMV transactions and state: “Native EMV transaction data requires protection beyond what is inherently provided by EMV itself.” As an answer to that problem, EMV introduced the EMV® Payment Token.

The EMV transaction, in a tokenized environment, uses a new element, the EMV® Payment Account Reference (PAR) that links the PAN and the transaction. On its own, a PAR cannot be used to charge a card; therefore, making it useless to an attacker.

A single PAN can be linked via the PAR to multiple devices. If a device gets compromised, the corresponding token will be de-registered without impacting the other devices.

The EMV tokens used must:

  • Pass validation rules of a PAN, while reinforcing interoperability
  • Be a 13 to 19-digit number that conforms to the account number rules of an ISO message (‘like-to-like’ formatting)
  • Not conflict or collide with an actual card issuer assigned PAN
  • Be mapped and associated in the token vault with an existing PAN by the entity that generates it before issuing it to the requestor

With the growing popularity of mobile payments, tokenization is becoming the key to higher security. There are many scenarios and real cases where sniffing devices can be or have been planted within the transaction chain. More stories continue to emerge in the news about massive data breaches involving data from millions of compromised bank accounts because of the absence of token technology. 

For instance, the restaurant group Earl Enterprises confirmed that over two million credit cards were compromised between May 2018 and March 2019 in a breach involving their restaurants, including Earl of Sandwich, Planet Hollywood, and Chicken Guy. Later on, it was found that the stolen data was being sold on the dark web.

Stolen credit card data can be used for CNP fraud, creating cloned cards with only magstripe or even EMV card transplants. EMV is now following the path that Apple Pay and other mobile wallet payment systems started: Simply, put...do not expose the PAN! 

A Move Toward Full Tokenization in EMV?

As we mentioned earlier, it would be beneficial to tokenize everything, not just the PAN. And this seems to be what the EMV consortium is moving toward.

During a contact EMV transaction, the terminal will look at a folder named 1PAY.SYS.DDF01 in the credit card chip and read the PSE (Payment System Environment). This contains a list of available payment applications and their capacities. The payment application is registered via its AID (Application Identifier), which is a hexadecimal value.

The terminal will then select the AID that it needs, for example, a Mastercard debit (A0000000041010), issue a few commands and a “Get Processing Options” command.

The Get Processing Options command reveals:

  • The capacity of the card
  • How it can interact with the terminal to get mutual verification
  • How it will process risks and so on.

You will probably be surprised to hear that in the EMV, which is supposed to be so secure, all that information is public. It does not require any private keys or password to be accessed either. Therefore, any smartcard reader equipped with free software can read this information as we explained earlier.

It is a proven fact that attackers can use this information to create all sorts of cards, including card transplants or hybrids, that contain modified payment applications that give the wrong value to the terminal. This forces, for example, SDA authentication instead of a DDA or CDA authentication. SDA authentication can be broken. In some countries and banks where EMV implementation has been done in a sloppy way, some transactions will be fraudulently authorized! It could be then beneficial to substitute tokens to the PSE, the AIDs, the card verification values and so on.

The idea is to replace all the card data with dummy tokens that would make no sense to anyone without accessing the vault. This technique is already used by HCE (Host Card Emulation) and cloud tokenization technologies.

The entire EMV transaction would then look like a puzzle with pieces of information making no sense unless they are un-mapped in the vault. This is not encryption because there is no need for a key. The key is simply needed to access the secure vault. Combining tokenization and encryption and keeping the actual cryptogram generation in EMV would provide much higher security. 

If you think this is paranoia, read the following example of an actual case of hacking against EMV.

Behind the Scene: A Concrete Case Where EMV Tokenization Makes Sense

You might think tokenization is not needed at all because you believe EMV transactions are very secure. But before you dismiss tokenization, read on. You may change your mind after reading this true story.

The following example is real and should concern everyone anyone involved with credit card processing.

A prestigious chain of deluxe shops located in the United Kingdom was hacked a few years ago. The shops had been equipped with a system where the EMV Chip-and-PIN transaction data was uploaded to some auxiliary control servers that maintained the credit card terminals for all the shops. These servers were outside the EMV environment. A criminal group of hackers located in Romania silently managed to take control of these servers. 

The information stolen was encrypted. Indeed, the software was:

  • Deciphering the card data
  • Putting the value in a variable
  • Re-ciphering the data
  • Deleting the temporary variable

The problem was that the hackers could still scan the memory to intercept the temporary variable containing the PAN and other bank data. Therefore, the credit card data of all the customers of these prestigious shops was leaked. And with the system being EMV+PCI-DSS, it was stolen without anyone noticing it. This breach continued for years and it is not exactly known how much data was stolen (intercepted).

EMV was initially created in 1993 because similar criminal groups were counterfeiting the magnetic stripe of the credit cards. EMV tokenization will rise because of stories like this, where merchants develop insecure information systems around the EMV payment environment. Of course, if these were PAR EMV tokens uploaded to the auxiliary servers of the shops, the Romanian gang would have been unable to gain access to the data.

Nowadays, there are many similar stories coming to light about sniffing devices planted in all sorts of devices and credit card data being leaked when making payments in restaurants and hotels. While these breaches are not occurring everywhere, it is occurring enough to be concerned.

EMV Tokenization Can Be the Answer

In a payment environment with multiple actors, a proliferation of internet devices, and mobile payments, EMV tokenization appears to be the mandatory solution needed to prevent massive credit card leaks.

Download white paper

References