EMV Card Personalization Specification

The card’s life cycle (Card Production Life Cycle, or CPLC for short) consists of five main phases.
At various stages of the card’s lifecycle, the chip manufacturer, the card supplier, the card Issuer, and finally the card holder work with the card. However, the distribution of actions performed with the card at different stages of the cycle depends significantly on whether the card is static or supports an open operating system, such as Java Card, whether executable application modules/applets are loaded into ROM or EEPR0M, and so on.
Each phase of the lifecycle uses a specific functionality specific to this phase of the card operating system. For example, you can’t select an application during the chip manufacturing or pre-personalization phase. Dividing the card into phases allows you to control the security of the card at different stages of its existence and ensures the distribution of responsibility among all participants in creating/using the card.
During the construction phase, the manufacturer of the chip places (burns) in ROM operating system card (hard – coding) and possibly executable modules or applets (Java card) some apps, and downloads to the card key Manufacturing Key used to control access to the card during the phase of prepersonalization card. The Manufacturing Key is unique for each card and is derived from the card provider’s key, which is passed in a secure manner to the chip manufacturer. As a diversification mode, the chip Serial number is used to output the card key. The key is stored in an elementary file, usually created by the card operating system during the first power supply to the card (this file is created before initializing the card file structure, in particular, before the MF root directory appears). The card’s operating system contains the manufacturer’s ID, the chip’s serial number, the type of chip components used, the chip type, the operating system ID, the chip’s release date, and so on. At the end of the production phase, the card chip is ready to be pasted into the plastic case.
During the pre-personalization phase, the chip is placed at the disposal of the card vendor, who inserts the chip into the plastic card case and initializes the card’s file structure in EEPR0M memory. In particular, the root file of the MF system is created, elementary files for storing personalization keys used to control access to the card during the card personalization phase, as well as to ensure the integrity and confidentiality of data uploaded to the card.
During the pre-personalization stage, directories and elementary files may be created to store application data downloaded during the chip manufacturing stage, and executable modules of some applications stored in EEPR0M memory and related data may be loaded.
To get access to the card, the card provider authenticates the card by signing a random number received from the card using the manufacturing Key secret key. This ensures that the security of the card is monitored, including at the stage of transporting the chip from its manufacturer to the card supplier.

To increase security, the card’s physical memory access commands are usually deactivated at the pre – authorization stage. From now on, working with memory is only possible using logical addressing under the control of the card’s memory read / write control program.
The card provider writes its part of the information related to the CPLC in the EEPR0M memory. This information may include the ID of the card provider, the date the card was created, the date it was pre-personalized, the brand of equipment used to create the card, and so on.
After completing the pre-personalization phase, the card is placed in the personalization phase under the control of the card Issuer. During the personalization phase, the contents of files and application data are recorded on the card, including the cardholder’s identification data, PIN code, and so on. Activation of the personalization phase occurs only after authentication by the card of its Issuer. To ensure the integrity and confidentiality of data uploaded to the card, the corresponding card keys stored on it during the pre-personalization phase are used.
The card Issuer records the part of the CPLC information related to it in the EEPR0M memory: the Issuer’s ID, the date of personalization, and the type of hardware used for personalization. After that, the card enters the use phase. While in this phase, it is passed to its holder and applied by the latter until the card is blocked (the card application) or expires.
In accordance with the VIS 1.4.x specifications, the CPLC data object (Tag ‘9F7F’) is mandatory and has a data field length of 42 bytes. The terminal can get a CPLC object using the GET DATA command.
The concept of life cycle takes on a special meaning for cards that support the Global Platform operating platform. The life cycle of such cards begins when the card becomes compatible with the Global Platform (the corresponding software was downloaded to the card during its manufacture), and continues until the card is withdrawn from circulation.
For cards that support the Global Platform standard, applets can be loaded into EEPR0M memory during use use of the card. To do this, the card must be in the “Protected” state of its lifecycle (the most “popular” state of the Global Platform card). In this state, the card has the necessary set of keys that the card Manager application uses to establish a secure connection with a program that is external to the card. This set of keys, as well as the key used by the Issuer to sign the applet, are passed to the card during the first phase of the Global Platform lifecycle.
During the “Protected” phase, the card is also personalized. First, the card and the external program are mutually authenticated, and then a secure connection is established to transfer personalization data from the external program to the card.

Card personalization
The issue of standardization of the IPC personalization process was open until June 2003, when the EMV Card Personalization Specification appeared. Until that time, card issuers, depending on the choice of a specific chip used for issuing IPC, had to purchase/develop a special program for their personalization machine that implements the Protocol of the machine working with the chip based on personalization commands supported by the microprocessor of the selected chip.
With the advent of the EMV Card Personalization Specification, the card personalization procedures and commands, as well as the interfaces between the personalization data center and the personalization machine, the personalization machine, and the card, have been largely standardized.
Standardizing the card personalization process does not, of course, mean that all IPC vendors support the EMV Card Personalization Specification for all their products. At the time of writing, these specifications were mostly supported in cards using the multi-layer Global Platform/Java Card. This is understandable, since in terms of the interface between the personalization machine and the card, the specifications only define the procedure for mutual authentication of the card and the program for personalization equipment, as well as the secure transmission of card personalization data. However, it is assumed that the creation of files and records in which the transmitted data will be stored on the card remains outside the standard and again depends on the selected card chip. Because the Java Card environment has commands for downloading and installing executable application modules, creating / deleting files, creating records, etc., and because Java Card is an open standard, the EMV Card Personalization Specification is ideal for Global Platform/Java Card cards.
The process of preparing personalization data is performed in the back-office system of the Issuer or third-party personalization Bureau. This process can use data stored on various Bank hosts. Its purpose is to prepare data that should be placed in the IPC.
Some of the data being prepared may be shared by a certain set of cards. Some data changes from card to card. Some of the data can be transmitted to the card in plain text. At the same time, there is data (keys, PIN codes) that must be encrypted during the entire personalization process.
The prepared data is transmitted in a specific format to the personalization machine, which acts according to the instructions defined for it. To implement the EMV Card Personalization Specification standard, the personalization machine must support it.
The personalization machine must have access to the HSM cryptographic processor (Hardware Security Module) to support secure interfaces with the personalization data center and card. To protect data, these interfaces use data encryption and generation / verification of MAC codes (Message Authentication Code), which ensure the integrity of the transmitted information and authentication of its source.
The personalization machine passes the data prepared for it to the card for storing it in EEPR0M memory. To do this, the card must support commands and interpret the data received from the personalization machine. In other words, the card operating system must also support the EMV Card Personalization Specification standard.
An important part of the EMV Card Personalization Specification is the uniform format of data that is distributed between the personalization data center, the personalization machine, and the card. Several physical modules of the personalization machine take part in the card personalization process (for example, modules for embossment, magnetic stripe encoding, and entering data to the microprocessor), each of which requires its own set of data. The data assigned to a specific personalization machine module is defined in the General personalization data set by the Module Identifier Code (MIC) of that module.
There is a MIC identifier that defines the microprocessor personalization module. The value of this MIC is set in advance by agreement between the data center and the personalization machine. Figure 5.1 shows the General data structure for card personalization. The module with the MIC2 code is responsible for personalization of the microprocessor.
The IPC can be multi-layered, and the EMV Card Personalization Specification provides for the ability to personalize multiple card applications at once. Data structure for each card application
Data for the personalization machine contains information about the AID application ID, the ID of the transport key used to transfer confidential data from the personalization data center to the personalization machine, and so on.
The data that should be stored (logged) on the personalization machine is a duplicate of some (or all) data sent to the microprocessor. This data is determined by the Issuer and used for various purposes. Only the numbers of personalized cards can be legalized, or all the data used for card personalization can be legalized if this data is prepared by a third-party personalization Bureau.
Finally, the data to transmit to the microprocessor consists of several data groups (Data Grouping), each of which is defined by the Data Grouping Identifier (DGI). The structure of data groups is a key element of the card personalization process. In General, each data group must correspond to an entry in the application’s linear file.
Here are the requirements and instructions that should be used when creating data groups (DGS):
Any data transmitted by the IPC must belong to one of the DGS.
For ease of managing the personalization process, the information contained in the DG is usually stored in a single line file entry (for an example of exceptions, see paragraphs 7 and 8 of the requirements). On the contrary, each entry in a linear file must contain information from a single DG.

When defining the DGI for [D, we recommend using the name of the SFI linear file and the number of the record corresponding to this (D).
DES keys must be passed to a DG containing only DES keys.
There are advantages to placing either fixed-length data elements or variable-length data elements in a single DG.
It is recommended that the data size in a single DG should not exceed 237 bytes.
Often data elements used only by the application (not read by the terminal) are not stored in linear files. It is recommended to place such data in separate DGS containing only such data elements.
If the FCI Template of an application contains data that requires personalization, then such data is placed in a separate [D] (separate DGS are created for the FCI Template of different applications).
Value ‘ 9F66the ‘ h of the DGI ID is reserved for transmitting the Card Production Life Cycle (CPLC) data element to the card.
DGI values from ‘ 7FF0’h to 7FFE’h is reserved for DGS containing data not used in the EMV application.
The number of DGS should be minimized to improve the performance of the card personalization complex.
If the DG data must be encrypted and the group data elements are DES keys or PIN blocks, then data encryption is performed without adding service characters (padding). In other cases, additional bytes ’80’h and subsequent bytes ’00’h are used. The number of bytes ‘ 00’h varies from 0 to 7 and is determined by the fact that the number of bytes of encrypted DG data must be a multiple of 8.
The key Check Value for any DES key is the result of applying the 3DES algorithm in ERU mode to a sequence consisting of 8 bytes of the type ‘ 00’h.
It is recommended that the data preparation system generate a PIN block in accordance with ISO 9564-1 (format 1). If necessary, the card application must reformat the PIN block to the format it uses.
The first two or three bytes of each line file entry consist of Tag ‘ 70 ‘ and the length field of the record data.

Data placed in a DGI with the DGI ID, the leftmost byte of which is ’80’h or ‘8F’h, must always be encrypted. At the same time, encrypted data can also be stored in other DGS.

Data Group Identifier (DGI) Tag Data Element Length of Data Element
1 2 3 4
‘0101’
’57’ Track 2 Equivalent Data 16
‘5F28’ Issuer Country Code 2
‘5F20’ Cardholder Name 26
‘9F0B’ Cardholder Name Extended 30
Total Record Length 87
’0201′
‘8 F’ Certificate Authority Public Key Index 1
’90’ Issuer Public Key (IPK) Certificate 144
’92’ IPK Remainder 36
Total Record Length 188
’0202′
‘9F32’ IPK Exponent 1
‘9F2E’ ICC PIN Encipherment 1
’9F47’ ICC Public Key Exponent 1
’93’ Signed Static Application Data 144
Total Record Length 159
‘0203’
‘9F46’ ICC Public Key Certificate 144
‘9F48’ ICC Public Key Remainder 42
Total Record Length 193

‘0204’
‘9F2D1 ICC PIN Encipherment Public Key Certificate 144
‘9F2F ICC PIN Encipherment Public Key Remainder 42
Total Record Length 193
‘0301’
‘5F25’ Application Effective Date 3
‘5F24’ Application Expiration Date 3
‘9F07’ Application Usage Control 2
‘5A Application Primary Account Number (PAN) 12
‘5F34’ Application PAN Sequence Number 2
‘8E’ Cardholder Verification Method (CVM) List 18 1
‘9F0D’ Issuer Action Code (IAC) Default 5
‘9F0E’ IAC Denial 5
‘9F0F IAC Online 5
‘8C CD0L1 33
‘8D’ CD0L2 12
Total Record Length 132
‘0203’
‘9F4A’ SDA Tag List 1
‘9F49’ DD0L 4
‘9F44’ Application Currency Exponent 1
‘9F42’ Application Currency Code 2
‘5F30’ Service Code 2
‘9F08’ Application Version Number 2
Total Record Length 3°

Card personalization uses keys that are not related to the card keys used during card transactions. The personalization key management system is as follows. At the pre-personalization stage, performed by the IPC provider before the personalization process begins, the card is loaded with CT, kmas, and CT keys, which are output from the CMC key. The CMC key is the Issuer’s 16-byte key that it passed to the card provider.
The KMS key has a KMCID, which can be generated using the card Issuer’s ID (including the card’s BIN value). Each key corresponds to a 10-byte KEYDATA parameter

KEYDATA structure
Size field, bytes
Key ID 6
Chip Serial Number 4

The QL key is output using the CMS key and the KEYDATA parameter using the following formula:
K[NC = DES3(KMC)[Z ll’FO’H’Or] || DES3(KMC)[Z TS’OGTS’OG],
where Z is the six smallest bytes of the KEYDATA element.
The CT key is used to generate the skuenc session key used for generating/verifying the card cryptogram and the personalization machine cryptogram, as well as for encrypting the STORE DATA command data field in SHS mode, if required by the security level set in the EXTERNAL AUTHENTICATE command.
The kmas key is output using the KMS key and the KEYDATA parameter using the following formula:
KMAS = DES3(KMC)[Z ll’FO’11’02’] || DES3(KMC)[Z ||’0G||’ 02’].
The kmas key is used to generate the skumac session key used for calculating / verifying Message Authentication
Code (MAC) for the EXTERNAL AUTHENTICATE command (always) and STORE DATA commands (if required by the security level set in the EXTERNAL AUTHENTICATE command). The MAC value used to ensure the integrity of the personalization team’s data is called C-MAC.
The CT key is output using the CMS key and the KEYDATA parameter using the following formula:
Ksh = DES3(KMC) [Z11 TO’ 11 ’03’ ] 11 DES3(KMC) [Z \ \ ‘OF’ | | ’03’] •
The KDEK key is used to generate the skudek session key, which is used for encrypting/decrypting secret data transmitted in the STORE DATA command in ERU mode.
The session keys SKUENC, SKUMAC and SKUDEK are calculated using the corresponding card keys and the Triple DES algorithm applied in the SHS encryption mode to the data.
Data for output of session keys
Key card Session
the key is Encrypted in the mode of SHS data
‘0182’| |SC| I’OOOOOOOOOOOOOOOOOOOOOOOO’
‘OlOl’l |SC| I’OOOOOOOOOOOOOOOOOOOOOOOO’
*mg ‘0181’||SC| I ‘OOOOOOOOOOOOOOOOOOOOOOOO’

SC (Sequence Counter) indicates the value of the card counter returned to the personalization machine in response to the EXTERNAL AUTHENTICATE command.
A card that meets the EMV Card Personalization Specification must support the following set of commands:
SELECT;
INITIALIZE UPDATE;
EXTERNAL AUTHENTICATE;
STORE DATA.
The stream of commands that the personalization machine exchanges with the card during the personalization process
After cold initialization of the card performed by the personalization machine (Reset signal transmission), the card responds with a string of ATR bits (Answer To Reset) that defines the Protocol and speed of data exchange between the card and the personalization machine. Next, the personalization machine sends the SELECT command to the card, specifying the name of the AID application to be personalized (this means that the FCI Template for this application has already been created (perhaps not completely) at the pre-personalization stage of the card). The SELECT command has a standard structure.
Then the personalization machine sends the initialize UPDATE command to the card
Structure of the response block to the INITIALIZE UPDATE command
The card cryptogram is calculated in accordance with the MAC calculation Algorithm 1 described in ISO 9707-1 clause 3.11.3 and applied to the 16-byte rjem ||SC|| Rmo sequence. The personalization machine checks the cryptogram by recalculating the MAC value on the RmM ||SC|| Rcm data. If the cryptograms match, the card authentication is considered successful. Otherwise, authentication is considered failed and the card personalization process is completed.
After receiving a response to the INITIALIZE UPDATE command the personalization machine generates the EXTERNAL AUTHENTICATE command

Code Value Size, bytes
CLA ’80’ 1
INS ’50’ 1
P1 ’00’ 1
P2 ’00’ 1
Lc ’08’ 1
Data Random number 8
Le ’00’ 1

Structure of the INITIALIZE UPDATE command
Response block field Size, bytes
KEYDATA 10
Version number of the MS 1 key
Protocol ID (ALGSCP= ’02’) 1
card counter (SC) 2
Random number of the card /?Shoo! 6
The card cryptogram 8
SW1SW2 2

Structure of the EXTERNAL AUTHENTICATE command
Code Value Size, bytes
CLA ’84’ 1
INS ’82’ 1
P1 Security Level (see table 5.7) 1
P2 ’00’ 1
Lc ’10’ 1
Data cryptogram of the personalization machine 8
S-MAS 8

The personalization machine cryptogram is calculated according to the MAC calculation Algorithm 1 described in ISO 9707-1 clause 3.11.3 and applied to the 16-byte SC 11 Rurd 11 Rtcrm sequence. The card must check the cryptogram by recalculating the MAC value on the SC || Rmo || Rterm data. If the cryptograms match, the authentication of the personalization machine is considered successful. Otherwise, authentication is considered failed and the application personalization process ends.
The C-MAC value is calculated in accordance with the MAC calculation Algorithm 3 described in ISO 9707-1 clause 3.11.3 and applied to a sequence that includes a modified command header and the EMV Card Personalization Specification data field. THE scumac session key is used to calculate the C-MAS.
Parameter P1 that defines the Security Level for the card personalization session.
If the security level is MAC-compliant, the C-MAC value is calculated for all STORE DATA commands in this personalization session. The C-MAC value is calculated in accordance with the MAC calculation Algorithm 3 described in ISO 9707-1 clause 3.11.3 and applied to a sequence that includes a modified command header and the EMV Card Personalization Specification data field. THE scumac session key is used to calculate the C-MAS.
If the security level corresponds to Encryption and MAC, then for all STORE DATA commands in this personalization session, the command data field is encrypted using the SCUENC session key and the Triple DES algorithm used in SHS mode. In addition, the C-MAS value is calculated for all commands using the scum session key.
If the security level corresponds to the Absence of encryption and MAC, the data encryption and data integrity command is not used.
The most common command in the card personalization session is the STORE DATA command

Defining the security level for the card personalization session

B8 B7 BB B5 B4 BZ B2 s Value
0 0 0 0 0 1 1 Encryption and MAC
0 0 0 0 0 0 0 1 MAC
0 0 0 0 0 0 0 0 no encryption and MAC

Structure of the STORE DATA command

Code Value Size, bytes
CLA ’80’ or ‘ 84 ‘ 1
INS ‘E2’ 1
P1 see table 5.9 1
P2 Sequence Number 1
Lc Input string containing data groups 1-3
Data cryptogram of the personalization machine 8
C-MAS if CLA= ’84’ 8

Note that the input line of the command contains a set of several DGS. Each DG is passed using the STORE DATA command. However, a single STORE DATA command can be used to transfer multiple DGS to the card.
The ENC field for data coming from the personalization data center specifies the DGI values of the DGS whose data must be encrypted before it is sent to the card, as well as the IDs of the transport keys used to encrypt this data when it is sent from the data center to the personalization machine. The data specified in the ENC field must be decrypted in the personalization machine on the corresponding transport key and then encrypted on the SCUDEK session key. The triple DES algorithm in ERU mode is used for encryption of DG data. However, if a security level corresponding to Encryption and MAC is used for this session, then after some data is closed on the SCUDEI key (r), the entire STORE DATA field will be closed on the SCUENC key.
Parameter P1 of the STORE DATA command
Structure of parameter P1 of the STORE DATA command

B8 B7 B6 B5 B4 BZ B2 B1 Value
X Indicator of the last STORE DATA command
1 last STORE command
DATA
0 not the last STORE DATA command
X x encryption Indicators
1 1 All DGS are encrypted
0 0 DGS are not encrypted
0 1 Some DGS are encrypted
1 0 Reserved for use
X X X X x Reserved for use

If the personalization machine needs to specify that the DG is the last one for the selected application, this DG is assigned a DGI ID equal to ‘7FFF’. A data group with this DGI value should be placed in the last STORE DATA command.
Note that if the DGI value is present in the ENC field of data coming from the personalization data center, even if bits 7 and b of parameter P1 are equal to O (the DG is not encrypted), the DG data with the specified DGI indicator value must be encrypted.
A set of transport keys is used to transfer confidential data from the data preparation center (DPC) to the personalization machine. The reason why a certain set of transport keys is used instead of a single key is to increase the security of information exchange. Transport keys are usually divided into keys that are used to encrypt PIN blocks (PIN Encryption Key), other keys (Key Encryption Key), and other data (Data Encryption Key).
Note that during the card personalization process in accordance with this standard (section 2.1.2 EMV Card Personalization Specification), the card keys for the asymmetric encryption algorithm are generated by the Issuer, not the card. Obviously, in the second case, the security of the scheme increases, because in this case, the private keys of the card for the asymmetric encryption algorithm are not known to anyone (the private keys are stored only on the card).
The data preparation center creates a certificate of the card’s public key used to calculate the cryptogram, as well as a certificate of the card’s public key used to encrypt the PIN code, if the card supports the cardholder’s Encrypted Offline PIN verification method and uses a separate key for this purpose. Certificates are created using RSA encryption with the card Issuer’s private key and uploaded to the card. The corresponding private asymmetric keys of the card are also loaded to the card in encrypted form.
In turn, the card Issuer receives a certificate of its public key from the payment system’s certification center. The Issuer’s public key certificate, along with the details of the used public key of the system certification authority, is stored on the card.
CPD should also prepare a symmetric key-card, designed for:
compute the cryptogram of the transaction;
ensuring integrity;
ensuring the confidentiality of secret data;
to calculate the ICC Dynamic Number value for a card that supports dynamic authentication.
These keys are transmitted to the personalization machine in encrypted form using the key Encryption Key. Using the cryptographic module HSM of the personalization machine controller, the listed keys are re-encrypted using the 3DES algorithm and the SCUm key.
If the card uses the offline PIN verification method to verify its holder, the CPD transmits the PIN code value in encrypted form to the personalization machine. The PIN value is encrypted using the 3DES algorithm and the PIN Encryption Key. On the personalization machine controller, the PIN value is re-encrypted using the 3DES algorithm and the SCUDEK key and transmitted to the card.
The CPU also prepares and passes data objects to the card for storage: Application Primary Account Number, PAN Sequence Number, Application Effective Date, Application Expiration Date, Application Interchange Profile, Application File Locator, Static Data to be Authenticated, and Data Authentication Code (if the card directly supports the static authentication method), SDA Tag List, Application Usage Control Application Version Number, Issuer Action Code, CD0L1, CD0L2, DDOL, tdol, card Issuer action code, card TVR Action code, CVM list (if the card Supports verification of its holder), PIN Try Limit (if the card supports offline verification of the PIN value), limits for offline transactions, etc. The purpose of the listed data objects was explained earlier.
Today, there are various offers on the market for personalization machines from DataCard, NBS, and others. However, the undisputed world leader here is the American company DataCard, which according to various estimates accounts for about 85% of the market for card personalization devices. In Russia, almost all EMV cards are personalized on this company’s machines. To personalize the MPC, you can use both desktop embossers DCl50i, DC280P, DC450, and conveyor – type devices DC500, DC7000, DC9000, Maxsys from DataCard.
Up to two smart card personalization modules can be installed on the DC7000 and DC9000 complexes, each of which contains up to seven chip initialization stations (new IPC personalization modules containing up to 11 stations have recently been introduced for DC9000 machines). The presence of several programming stations in each personalization module is due to the fact that it can take up to 15 seconds to personalize a single card application (when using HSM, this time can be reduced by about 1.5 times), i.e. the performance of the entire complex in this case is not higher than 240 cards per hour, since the performance of the personalization machine is determined by the speed of the slowest module in its composition. This is usually a color image printing module (300-500 cards per hour) or, if this module is not used, an embosser module (500-700 cards per hour). It follows that for issuing embossable smart cards with a single EMV application, it is usually enough to have 3-4 programming stations.