Personalization of EMV specification microprocessor cards

General approach and industrial solution

this section deals with the issues of personalization primarily of microprocessor Bank cards of international payment systems, although the described approaches and software solutions can easily be extended (which we have already done in a number of cases) not only to cards of various local payment systems, but also to identification cards with a chip (for example, driver’s licenses, party tickets, insurance policies), SIM cards for mobile phones, transport and petrol cards, etc.

Background

Millions of microprocessor cards are issued by existing (and pre-existing) payment systems. And all these millions of cards were somehow personalized. However, the methods used until recently to personalize chip cards can not be called industrial. Very often, the number was simply put on the map, then the card is manually inserted by the operator into the reader or terminal, and all-personalization is complete (as one well-respected colleague said, “why do I need an embosser, I’d rather hire two dozen students, let them work at night, and not walk”). There was a paradox – “at the cutting edge” smart cards in the field of personalization in terms of the level of automation, performance, and use of advanced technologies were significantly inferior to traditional cards with a magnetic stripe (however, the issue of magnetic cards numbered not millions, but tens of billions of pieces on a global scale). After all, technologies for personalization of magnetic cards were developed thanks to such giants as visa and MasterCard, among others.
New times – new problems. Visa and MasterCard took their time with their decision. Nevertheless, international ISO standards were being developed-standards for cards with a microprocessor, specifications common to both payment systems-EMV standard specifications, and proprietary payment system specifications-flash Integro (visa) and M/chip (MasterCard). At the moment when it became clear that the transition of both payment systems to microprocessor cards is inevitable, the task arose: to make the personalization of cards with a microprocessor as universal and high-tech as the personalization of cards with a magnetic stripe. And this task turned out to be very, very difficult. In particular, if the “communication” with EMV cards and payment terminals is almost completely specified, there are still no complete strict requirements for how these cards should be personalized.

What exactly is it about

According to the payment systems themselves, em EMV migration is exactly personalization. And this complex issue, we think, requires quite detailed consideration. The personalization process involves:
actually a card with a chip;
personalization device;
data placed on the map;
software for managing the entire process.
Thus, first of all, you need to have an idea about different EMV cards, know how they differ from each other, how they are produced, when and where they are personalized.

You should also understand how to transform the familiar technology of personalization of Bank magnetic cards (including how to upgrade the existing personalization equipment), what data is placed on the card, how to prepare them, and how to personalize the cards in the most rational way.
At the same time, we must proceed from the fact that today we need to personalize some cards, and tomorrow others. Today’s circulation is limited to a few thousand cards, and tomorrow there will be hundreds of thousands of them, which will require the use of completely different hardware performance, so the software must have high adaptive qualities. In addition, it is desirable to have a tool that allows you to: check whether the cards are personalized correctly; make sure that the data recorded in the chip corresponds to the original ones; see how the card behaves in the dialog with the terminal device.

Functional and technological types of maps

Cards that meet the EMV specification differ from other microprocessor-based payment cards (such as e-wallets) in that they are strictly regulated in the sequence of joint operation with receiving devices (terminals). This sequence consists of the steps listed below (some steps may be omitted).

Select the application (Select Select). The terminal asks the map about which applications it supports (for example, local and feathery), and if there are matches with applications that the terminal itself supports, one of them is selected.
Request by the terminal for basic information about the application (get get processing option). The map provides basic information about the app (in particular, what functionality and data storage structure the selected app supports).
Read application data (read read write). Based on the information about the structure of data files obtained in the previous step, the terminal reads this data.

Data authentication (data Authentication) . In offline mode, the terminal checks whether the data read from the card is true and whether it was previously tampered with or illegally corrected. There are the following authentication methods: static (SDA), dynamic (DDA), and improvement of dynamic – combined (CHS), which is a clone.

The essence of the simplest static authentication is as follows. In the process of issuing cards, the issuing Bank creates a pair of asymmetric keys. The public key is sent to the certification center of this payment system, from where it is returned with a signed secret key of the system. The pair – the public key and its certificate-is uploaded to the map. At the same time, some of the data (unclassified, but most sensitive, according to the system and the Issuer) is signed with the issuing Bank’s secret key. The payment terminal, knowing the system’s public key and reading the Issuer’s public key and its certificate from the card, makes sure that this public key is genuine.

Knowing the Issuer’s public key and the certificate of signed data, you can make sure that they have not changed since the card was issued. Thus, the terminal checks the truth of the information it reads from the card twice in succession-first the truth of the Bank’s public key, then the truth of the data.

during the execution of dynamic authentication (DDA) and combined (CDA) Internal internal authentication generate application cryptogram generation. The essence of the algorithm used is that the card data, as well as the dynamic characteristics of the transaction (such as the indicator of the card’s transaction counter and a random number issued to the card by the terminal) are signed with a secret RSA key, individual for each card. In turn, the public key that is paired with this key is signed with the Issuer’s secret key (in the same way that the Issuer’s SDA public key is signed with the payment system’s secret key). The knowledge of the card’s public key confirmed by the trust center (in this case, the issuing Bank) is sufficient to make sure that the cryptogram is correct. Thus, in the DDA and CDA in comparison with the SDA, there is a third (additional stage). If the SDA first checks the validity of the Issuer’s public key, and then the validity of static data, then in these cases, after checking the validity of the Issuer’s public key, we make sure that the card’s public key is true, and then the static and dynamic data of the card and terminal.
Checking restrictions on card usage (processing restrictions). The terminal analyzes the information received earlier from the map and determines whether it can be served at this time, in this geographical location, at this point of sale (by type) , and so on.
Verification of the cardholder’s credentials (verification of the cardholder). Among the data read from the card, there are also parameters that determine how the verification of the person who presented the card is performed. In addition to the methods known for the magnetic card case, such as customer signature and online PIN verification, offline PIN verification is also used.

To ensure this procedure, it first checks whether the limit for failed input attempts has been exceeded, and then, if everything is in order, the PIN itself is entered (the check command). However, there are two input methods – plain and encrypted. In the second case, the pin is encrypted using the card’s public RSA key using a random number issued by the card and decrypted inside the card with a secret key. It is possible to use a key pair for the DDA, and it is also possible to have a separate pair for pin encryption.
It is clear that both the DVR and the encrypted PIN have the same requirements for the card, namely, support for RSA encryption. Thus, both of these functions are connected – if the card can’t support DVR, there is nothing to say about PIN encryption, etc.
Check the risks (the risk management of the terminal). The terminal checks whether the card is in the “black” list, whether the limit is exceeded, whether the amount exceeds the transaction limit for servicing the card in offline mode, whether it is required to send an online request, and so on.
Making a decision on further actions by the terminal (analysis of terminal actions). Based on the operations described earlier (data authentication, verification of usage restrictions, offline PIN verification, risk verification), the terminal makes a decision on how to proceed with the transaction. There are three options: reject the transaction, send the transaction for online authorization, and accept offline authorization. The terminal offers the map (generate application cryptogram generation-AC) to calculate the 3DES cryptogram of the transmitted request. In accordance with the listed solutions, there are also three types of cryptograms – the application authentication cryptogram (AAC), the authorization request cryptogram (ARQC), and the transaction certificate (TC).

Authorization of the card in online mode (Online Processing). If the terminal and the card decide to send an online request to the Issuer, the terminal transmits the ARQC cryptogram and the card data and transactions used to receive it via communication lines. The host system of the issuing Bank verifies the correctness of the cryptogram (using the unique SDES key of the card), makes a decision on this transaction, and sends a response with an Authorization Response Cryptogram (ARPC) using the same card key. If the host system supports changing data on the card using scripts, the corresponding script is sent in the response.

If the card supports Issuer authentication, the terminal receives authorization data and sends it to the card using the External Authentication command. The card calculates the ARPC value and compares it with the one received from the terminal. If everything fits, it means that the answer came from the Issuer. If authentication failed, the following transactions will be sent online until the ARPC comparison is successful. The Issuer can set a parameter on the card that rejects the transaction if authentication fails.

Changing the settings, card (Issuer-to-Card Script Processing). The Issuer can change the card parameters used when working offline, as well as the PIN code and the number of attempts to present it, block or unblock the application, and block the card by sending special scripts in the authorization response. Scripts are signed using a special sdes key of the card, and the new PIN value is encrypted with the same key.

Completion of the process. Based on the information received from the Issuer, the transaction is either accepted or rejected. Accordingly, the vehicle or AAS cryptograms are formed.
There is a fairly wide range of certified cards on the market that meet the specifications of EMV and international payment systems. Let’s try to classify these offers. Let’s pay attention to the fact that if the behavior of the card “in battle” (when working with the terminal) is sufficiently described, then the questions (and commands) concerning card personalization are left to the chip developers and the cards themselves.

There are two types of cards – cards with “closed” operating systems (so – called proprietary or native cards) and cards with open operating systems.

As a rule, operating systems (masks) for native cards are developed by smart card manufacturers themselves, primarily such large ones as Gemlpus, Axalto, Oberthur, and G&D. In these cards, an application is a two-level data structure (similar to a personal computer-files inside a directory). According to their functionality, these cards can be divided into cards with a single EMV application (VSDC or M/Chip Lite) and multifunctional cards. The advantage of the first is relative cheapness, and the second is the ability to use additional applications. In the simplest case, it can be a loyalty application – an application that encourages customers to serve in a particular retail network by awarding bonus points (bonuses), the value of which usually depends on the purchase amount. In addition, it is possible to create additional local EMV applications, similar to the applications of payment systems (however, there may be a problem of resolving such a decision with the international payment system itself). Finally, a number of cards can be used to build various wallet schemes, including well-known in Russia systems of pre-authorized debit or “petrol” systems such as e-wallet, as well as various identification systems (pension Fund, medical insurance, logical access to corporate networks, physical access, etc.). in the vast majority of chips of these cards do not have a cryptoprocessor and do not support dynamic authentication and encrypted PIN (although there are exceptions).
cards with open operating systems include Java cards (or similar cards that meet the Global Platform specifications) and cards with the Multos operating system. Applications on these cards are programs (applets) that provide a particular functionality. When you activate the applet, you can write and store data. Multos cards implement the M/Chip Select application owned by MasterCard. cards support DDA.

Global Platform cards can be either DDA-enabled or encrypted pin-enabled (i.e.,with a cryptoprocessor), or they can be supported by AES. As a rule, only the VSDC applet for issuing Visa cards exists for these cards. However, some card manufacturers also have applets for MasterCard (M/Chip Lite – SDA cards). Among the certified Global Platform cards with DDA support (card manufacturers – owners of operating systems-Oberthur, G&D and Gemplus), it is worth noting jcopxo cards (x = 2, 3), the owner of which is Visa itself, which transfers the right to make cards for a sufficiently large number of productions and regulates the final price. Global Platform cards are also interesting in terms of personalization. For these cards, there are strict recommendations on the personalization mechanism and the structure of the personalization file (the Common Personalization specification).

It should be noted that following this specification is convenient and appropriate for personalization of any cards.
cards with open operating systems are multifunctional and are intended mainly for multifunctional systems. These cards are more expensive than cards with a closed operating system. Some of them are able to safely support the so-called post-issue, when the app is not only activated and/or personalized, but also created after personalization of the card.

Life cycle cards

Before the card gets a “start in life” and is issued to the owner, it goes through three stages in succession:
chip manufacturing;
card production;
personalization of the card.
At the stage of manufacturing a chip with a microprocessor, the following main actions are performed:
burning (hard-coding) in the ROM of the operating system chip’s microprocessor (mask);
generating the number of the microprocessor and writing it to the chip;
generating the secret key K (1C) (diversification from the parent key M (1C) by number
chip) for the microprocessor and its storage in the chip;
the key TO (1C) is used to close access to the card, as well as to transfer a secret
information on the card at the stage of its manufacture; the parent key is passed to the card manufacturer.
At the stage of manufacturing the card itself, after implanting the chip in the plastic base, the following procedures are performed:
the card factory confirms that it knows the key TO (1C). the standard authentication procedure is used, namely, a pseudo-random number received from the card by the pre-personalization device is encrypted and returned to the card for verification;
the card is initialized (in EEPROM, the file system is initiated partially at the top level or completely, including card applications).
a unique serial number of the card is generated and recorded on the chip;
the secret key of the CBS is generated (diversification from the parent key of the CMC by the serial number of the card) and loaded into the chip (sometimes in encrypted form using the key TO (1C) or similar);
the CBS key is used to close access to the card during transportation, as well as when transferring secret information to the card at the stage of its personalization;
the parent key is passed to the card personalizer.

It should be noted that the General scheme of production of cards with a microprocessor is shown above
taking into account the division of responsibility for security. In particular, in the described sequence, there is one transport key for the chip and the smart card itself. In fact, there may be several such keys: one for authentication of the card and device, the second for encryption when loading secret parameters (the same keys), and the third for forming a cryptographic signature when executing particularly important commands (for example, when creating the card file structure).
Certain features are available for cards with open and closed operating systems (for example, for the former, the card manufacturer ensures that the corresponding certified applets of international payment systems are loaded into the ROM).
Finally, the process of creating an application (implementing the required file structure) can occur both during card production (pre-personalization with subsequent data loading) and at the stage of personalization itself.
Directly personalization of the card: the card personalizer confirms knowledge of the CBS key;
the card is personalized (a file system is created in EEPROM, data is recorded, and secret data is recorded using the CBS key).

Preparing data

It is generally accepted to divide the entire process of personalization of smart cards of international payment systems into two stages: data preparation and personalization itself, which includes both chip personalization and traditional personalization of conventional magnetic cards.

The main task of the first stage is to generate a data file that is passed to the personalization machine, whether it is an embosser or a conveyor device for subsequent card release.

The customer database is a set of data related to customers: their first and last names (Cardholder Name), card expiration dates (Application Effective and Application Expiration Date), number or PAN (Primary Account Number), and so on. All this data is usually available in the back office system of the Issuer of traditional magnetic stripe cards.
Risk procedures – in this context, a set of parameters that determine organizational decisions that are made by the Issuer and relate to the security of the system and the level of service provided to the client. This refers to authentication methods (static, dynamic, and a set of authentication data), the ability to authenticate offline, the number of attempts to enter a pin, limits for offline transactions, and so on. However, different clients may be served differently, and the risk parameters of their cards may differ accordingly.

The key management system is responsible for cryptographic procedures that are performed during card personalization. This includes a list of necessary keys and their application areas, methods for generating them, generating them directly, and placing them on the card.

To understand the process of preparing data, and then the process of loading data into the chip, it is necessary to consider in detail the functions performed by the main participants in the entire process.
In this diagram, in the order of events:
the card manufacturer creates CMC-master keys for accessing the cards during the personalization process and sends it via secret channels to the issuing Bank, as well as to the personalizer. The methods for generating the key and transmitting it can be different. In the future, the card manufacturer closes access to them using the CBS keys, which are derived from the CMC. The card’s serial number is used to generate the CBS, which makes each key unique for each card. The personalizer that receives the CMC from the Issuer will “open” the cards using the CBS keys, which will be formed according to the same algorithm used by the manufacturer. The encryption algorithms used in these procedures, as in most of the others described below, are symmetric, usually based on DES and 3DES (usually just one of these two). Of course, if we are not talking about public cryptography used for generating and verifying certificates;
the card manufacturer selects them, closes access to them with CBS keys, and sends them to the personalizer;
the issuing Bank’s back office system generates data for transmitting it to the data preparation complex (DPS). Some of this data is secret (this includes the PIN, of course, and may also include other values, depending on the decisions of the Bank itself). Secret data is encrypted using the KEK1 key (Key Exchange Key 1), which, in turn, is transmitted to the KPD via some secret channel. Among the data transmitted by the Issuer to the KPD, there are also those that will be contained on the surface of the card (in printed or embossed form), as well as on the magnetic stripe;
KPD generates a pair of asymmetric Issuer keys and passes the public keys to the payment system certification authority to create certificates. The certification authority signs the Issuer’s public key with its secret key and creates certificates that will confirm the authenticity of the card Issuer before the terminal during the authentication process. In addition to the Issuer’s public keys, other data is involved in creating certificates (such as the Issuer Identification Number, Certificate Expiration Date, Certificate Serial Number, and Hash Algorithm Indicator). Note that, since the process of obtaining certificates is quite lengthy, it can be carried out in advance, even before the production of blank cards. The generated certificate is forwarded to the KPI;
The KPI uses the Issuer’s secret keys for each card to sign data included in the list of static authentication data (these include: Application Effective Date, Application Expiration Date, Application Usage Control, Application Primary Account Number (PAN), and so on).
if dynamic authentication is supported, each card creates its own pair of asymmetric keys, the public key of the card is signed with the Issuer’s secret key (similar to the procedure described above), and the secret key is uploaded to the card to participate in the authentication process later.

In addition to creating asymmetric Issuer and card keys, standard KPI functions include generating 3DES Issuer master keys and the card keys generated by them. These keys include:
a) authorization keys used for generating and verifying cryptograms; b) keys that sign scripts that change card parameters; C) keys that encrypt new pin values.
In addition to generating all the necessary secret values, the efficiency fully generates a file with

EMV data for a personalized device. Secret data, including those that were encrypted with the KEK1 key, is re-encrypted with a key (a set of keys) KEK2. The resulting file is sent to the personalizer. The key KEK2 is also sent there via a secret channel;

on personalized equipment, cards that are closed by the CBS and data that is encrypted by KEK2 “meet”. Inside the protected cryptographic device used at this stage, data is decrypted using the received KEK2. Similarly, from the key received from the Issuer of the CMC, the CBS keys are formed, with which the cards are “opened”
data for the chip is re-encrypted. External and electrical personalization occurs. It is worth noting that in the above scheme, as is often the case, some of the participants may represent the same legal entity. The standard situation is when the personalization equipment and data preparation complex belong to the Issuer and are located on the Bank’s territory. At the same time, technologically, they are all different participants in the process.

So, data preparation is a key stage of smart card personalization, both literally and figuratively. The hardware and software complex, which includes the cryptographic device, is responsible for its implementation. Let’s take a closer look at its possible (and often required) functionality. At the first stage, the KPI receives data for issuing cards with a magnetic stripe, including information about card owners. In addition, the payment system certification authority (Visa, MasterCard) receives the issuing Bank’s public key certificate signed with the payment system’s public key. Before creating an SDA, the necessary application and Issuer parameters are also added to the certificate. The SDA digital signature is calculated using the Issuer’s public key. Further, by diversifying the Issuer’s symmetric master key (a set of keys) Efficiency generates symmetric keys of the card. Then, if a DDA scheme is provided, asymmetric card keys are generated and a public key certificate is calculated (for each card). After adding card-specific parameters, as well as risk parameters set by the Issuer, the data is formatted and ready for personalization on the device.