3 min read

EMV Personalization cryptographic requirements 

EMV Personalization cryptographic requirements

EMV Personalization is a process used to get card data into cards, mobile phones, and wearables. The process includes a variety of complicated cryptographic tasks and activities, ranging from choosing proper cryptographic algorithms to authentication procedures. Ensuring all these steps are carried out accurately and securely is highly critical for card issuing and payments.

The Common Personalization Specifications (CPS) but also Global Platform or each of the Card scheme personalization requirements requires the establishment of secure channels and key exchanges in various ways and often the creation of key zones for transportation of the secrets to the integrated circuit chip (ICC). This article explains how these secrets are handled and the main principles of EMV personalization, particularly focusing on how secure channels are used.

Overview

There are several secrets that must be generated and protected during EMV personalization:

  1. The ‘offline’ PIN

  2. The private keys of the cards used for offline authentication (SDA, DDA, CDA)

  3. The secure channel keysets (Global Platform secure channel)

  4. Keys used for cryptograms computations and verifications (GENERATE AC)

All these secrets need to be both generated and transported securely to the ICC. In what follows we will detail what these secrets are and how they are generated and encrypted for EMV personalization.

Direct and indirect methods

An EMV personalization can be performed using two techniques: the direct and the indirect method. 

 EMV Key Management - explained

The simplest is the direct method, where the data preparation system is directly integrated with the coupler that will interface the ICC. In such a case there is no need for transport keys since there is only one zone separating the data preparation and the ICC.

The indirect method is more complex. It implies that the data preparation is separated from the personalization device and therefore there are two key zones. From the data preparation system to the personalization device (‘coupler’), transport keys must be used. In general, the keys are defined as follows:

  • DTK, the data transport key, used for genetic data

  • PTK, the PIN transport key, used for PINs

  • KTK, the Key transport key, used for keys

These transport keys must be unique each time. Each of these transport keys must be exchanged, either as split components or encrypted under a zone master key. It's worth noting that the payment scheme regulations for key distribution are very formal and detailed procedures extend all the way down to typing in individual key digits for import into an HSM

The secure channel protocol (Global Platform) used for EMV personalization

The notion of an EMV-compliant secure channel is fundamental when it comes to EMV personalization. These secure channels are generally implemented in such a way that they follow the Global Platform secure channels specifications ([2]). There are different types of such channels: SCP02, SCP03, SCP10, SCP11, SCP21, SCP22, SCP80, and SCP81. 

SCP02, using triple DES encryption is deprecated but still in use in various personalization centers because it had been historically the dominant algorithm for a long time while SCP03 and the other schemes, using AES encryption or Elliptic Curves are still being introduced at a slow pace. Such channels come with various security levels: data encryption, mac-based authentication, response-mac-encryptions, etc… and they are also available in different modes. 

These secure channels can use symmetric or asymmetric cryptography and key exchange protocols. In general, they are derived from a master key located inside an HSM during an initialization phase (pre-personalization). For example, SCP02, the simplest of all, uses a 3DES keyset based on 3 keys of 16 bytes each: the data encryption key, the mac key, and key-encryption-key. 

Once the initialization phase has been performed, the ICC personalization can start using the secure channel between the coupler and the ICC. The initialization phase must be mandatorily separated from the personalization phase, because of security considerations.

Representation of a typical EMV personalization 

In the following diagram, we represent the flow of a typical EMV personalization: Firstly the card (or secure element in a phone or wearable) is queried for its serial number, which allows to derive the cards' keys from a master key stored in an HSM. Once the keys are derived, they are transported to the ICC and stored there. This ends the initialization phase. The ICC is loaded with a specific, individual keyset.

During the personalization, data will be received from a database of encrypted secrets and from another database of plain text. The secret data will be securely decrypted by the HSM and the card will be required to provide its serial number, which allows the HSM to compute the card keyset and use that card keyset to open a secure channel with the card and send the data. The card will eventually verify and decrypt the data and write them on its EEPROM.

This is a very simplified version of an EMV personalization process, but EMV personalization centers usually do not disclose their methods and the exact algorithms that they use and therefore there is not a universal system that can be described.

diagram3.5


To summarize

We have seen how an EMV Personalization flow should behave and what type of data and secrets are to be considered. The EMV Personalization requirements provide a cryptographic standard for chip-based payments. These standards help to protect transaction data and keep payment information secure. It is important for merchant banks and card issuers to understand these specifications and ensure that their systems meet all of the necessary requirements. With proper implementation of the security guidelines, a more secure payment experience can be achieved. 

 

EMV Migration Support

 

References and Further Reading

  • [1] EMVco. Card Personalisation Specification Version 2.0, August 2021

  • [2] GlobalPlatform Technology. Card Specification. Version 2.3.1. Public Release, March 2018