PCI Watch

Tracking changes across the Payment Card Industry

EMV® Card Personalisation Specification

v1.1 Specifications
Contact Card

© 2011 EMVCo, LLC (“EMVCo”). All rights reserved. Any and all uses of these Specifications is subject to the terms and conditions of the EMVCo Terms of Use agreement available at www.emvco.com. These Specifications are provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of these Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of these Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with these Specifications

EMV Card Personalization Specification Version 1.1 July 2007

THIS PAGE LEFT INTENTIONALLY BLANK

i Tables and Figures July 2007 Table of Contents 1. Purpose v 2. Scope vi 3. Audience viii 4. Normative References ix 5. Definitions xi 6. Abbreviations and Notations xii 1 Card Personalization Data Processing 1 1.1 Overview of the Process 1 1.2 The Infrastructure of Card Personalization 2 1.3 Secure Messaging 3 1.4 The STORE DATA Command 3 1.5 The Common Personalization Record Format 4 2 Data Preparation 7 2.1 Creating Personalization Data 7 2.1.1 Issuer Master Keys and Data 8 2.1.2 EMV Application Keys and Certificates 8 2.1.3 Application Data 9 2.2 Creation of Data Groupings 10 2.3 Completion of Personalization 11 2.3.1 Multiple Transport Key Capability 12 2.4 Processing Steps and Personalization Device Instructions 12 2.4.1 Order that Data must be sent to the IC Card 13 2.4.2 Support for Migration to New Versions 14 2.4.3 Encrypted Data Groupings 15 2.4.4 PIN Block Format and Random Numbers 16 2.4.5 Grouping of DGIs 16 2.4.6 Security Level Indicator of Secure Channel Sessions 17 2.5 Creation of Personalization Log Data 19 2.6 Data Preparation-Personalization Device Interface Format 19 3 Personalization Device-ICC Interface 29 3.1 Processing Step ‘0F’ 29 3.1.1 Key Management 30 3.1.2 Processing Flow 30 3.2 Processing Step ‘0B’ 31 3.2.2 Key Management 33 3.2.3 Processing Flow 33 3.2.4 SELECT Command 34 3.2.5 INITIALIZE UPDATE Command 35 3.2.6 EXTERNAL AUTHENTICATE Command 39 3.2.7 STORE DATA Command 41 3.2.8 Last STORE DATA Command 45 3.3 Command Responses 45 3.4 Personalization Log Creation 45 4 IC Card Personalization Processing 49 4.1 Preparation for Personalization (Pre-Personalization) 49 4.2 Load / Update of Secure Channel Key Set 50

ii Tables and Figures July 2007 4.3 File Structure for Records 51 4.4 Personalization Requirements 51 4.4.1 IC Card Requirements 51 4.4.2 Command Support 51 4.4.3 Secure Messaging 51 5 Cryptography for Personalization 55 5.1 Two Key Zones 55 5.2 One Key Zone 55 5.3 Session Keys 56 5.4 MACs 56 5.4.1 MACs for Personalization Cryptograms 57 5.4.2 C-MAC for Secure Messaging 57 5.4.3 MAC for integrity of the personalization data file 60 5.5 Encryption 62 5.5.1 Encryption Using ECB mode 62 5.5.2 Encryption Using CBC Mode 62 5.6 Decryption 62 5.6.1 Decryption Using ECB Mode 63 5.6.2 Decryption Using CBC Mode 63 5.7 Triple DES Calculations 63 6 Personalization Data Elements 65 6.1 ACT (Action to be Performed) 65 6.2 AID (Application Identifier) 65 6.3 ALGSCP (Algorithm for Secure Channel Protocol) 65 6.4 C-MAC 65 6.5 CMODE (Chaining Mode) 66 6.6 CSN (Chip Serial Number) 66 6.7 DTHR (Date and Time) 66 6.8 ENC (Encryption Personalization Instructions) 66 6.9 IDTK (Identifier of the Transport Key) 66 6.10 IDOWNER (Identifier of the Application Specification Owner) 66 6.11 IDTERM (Identifier of the Personalization Device) 66 6.12 KENC (DES Key for Creating Personalization Session Key for Confidentiality and Authentication Cryptogram) 66 6.13 KDEK (DES Key for Creating Personalization Session Key for Key and PIN Encryption) 67 6.14 KMAC (DES Key for Creating Personalization Session Key for MACs) 67 6.15 Key Check Value 67 6.16 KEYDATA (Derivation Data for Initial Update Keys) 67 6.17 KMC (DES Master Key for Personalization Session Keys) 67 6.18 KMCID (Identifier of the Master Key for Personalization) 68 6.19 L (Length of Data) 68 6.20 LCCA (Length of IC Card Application Data) 68 6.21 LOGDATA (Data Logging Personalization Instructions) 68 6.22 MACINP (MAC of All Data for an Application) 68 6.23 MACkey (MAC Key) 69 6.24 MIC (Module Identifier Code) 69 6.25 ORDER (Data Grouping Order Personalization Instructions) 69 6.26 POINTER (Additional Pointer to Personalization Data or Instructions)69

iii Tables and Figures July 2007 6.27 RCARD (Pseudo-Random Number from the IC Card) 69 6.28 RTERM (Random Number from the Personalization Device) 69 6.29 RANDOM (Random Number) 69 6.30 REQ (Required or Optional Action) 70 6.31 SEQNO (Sequence Number) 70 6.32 SKUENC (Personalization Session Key for confidentiality and authentication cryptogram) 70 6.33 SKUDEK (Personalization Session Key for Key and PIN Encryption) 70 6.34 SKUMAC (Personalization Session Key for MACing) 70 6.35 TAG (Identifier of Data for a Processing Step) 71 6.36 TK (Transport Key) 71 6.37 TYPETK (Indicator of Use(s) of Transport Key) 71 6.38 VERCNTL (Version Control Personalization Instructions) 72 6.39 VNL (Version Number of Layout) 72 Annex A. Common EMV Data Groupings 73 A.1 Introduction 73 A.2 Common DGIs for EMV Payment Applications 73 A.3 Common DGIs for EMV PSE 79 A.4 Common DGIs to Load/Update Secure Channel Static Keys 80 A.5 Common DGIs to Create File Structure for EMV Records 82 Annex B. Overview of EMV Card Personalization Indirect Method 85

iv Tables and Figures July 2007 Tables Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table 1 – Data Content for tag ‘CF’ 8 2 – Data Content for DGI ‘7FFF’ 11 3 – Data Content for the Field ORDER 14 4 – Data Contents for the Version Control Field VERCNTL 15 5 – Data Content for the Field ENC 15 6 – Data Content for the Field GROUP 17 7 – Data Content for the Field SECLEV 18 8 – IC Card Application Data sent to the Personalization Device 20 9 – FORMATTK Codes and Associated Data 22 10 – Layout of TKDATA for FORMATTK ‘01’ 23 11 – Layout of Processing Steps Field 24 12 – Personalization Device Instructions for the Personalization Processing Step ‘0F’ 25 13 – INITIALIZE UPDATE Command Coding 36 14 – Response to INITIALIZE UPDATE command 36 15 – Initial Contents of KEYDATA 36 16 – Status Conditions for INITIALIZE UPDATE Command 36 17 – EXTERNAL AUTHENTICATE Command Coding 39 18 – Status Conditions for EXTERNAL AUTHENTICATE Command 39 19 – Security Level (P1) 40 20 – STORE DATA Command Coding for application personalization data 41 21 – Coding of P1 in STORE DATA Command 42 22 – Status conditions for STORE DATA command 42 23 – Contents of Personalization Log 46 24 – Derivation Data for Session Keys 56 25 – Coding of TYPETK 71 Figures Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure 1 – Overview of IC Card Personalization Data Format 5 2 – Overview of Personalization Data for an IC Card Application 5 3 – Layout of ICC Data Portion of Record (Section 3c of Table 8) 26 4 – Formatting of Personalization Data using DGIs within ICC Data Portion of Record 26 5 – Formatting of pre-computed APDU commands within ICC Data Portion of Record 27 6 – Personalization Command Flow 31 7 – Pre-computed APDU command placed in BER–TLV structure 32 8 –Personalization Two Key Zones 55 9 –Personalization One Key Zone 55 10 – C-MAC and MAC Computation 61

v

Purpose

July 2007 1. Purpose Card personalization is one of the major cost components in the production of EMV cards. This specification standardizes the EMV card personalization process with the objective of reducing the cost of personalization thus facilitating the migration to chip. In today’s environment, there are numerous methods of personalizing EMV cards and many vendors providing the systems to personalize these cards. Each time a native card is developed, or a new application released, issuers and personalization vendors are obliged to expend significant time and money to develop the corresponding personalization process. In addition, these cards are typically personalized using proprietary commands, often making it difficult for card issuers to source cards from alternative suppliers or bureaus. This specification standardizes EMV card personalization leading to faster, more efficient and more economical solutions. It offers benefits which include: lower set up costs, faster time to market, greater choice of supplier (card and personalization bureau) and an enhanced ability to switch suppliers. Changes in version 1.1 This release incorporates Specification Update Bulletins no. 23 and no.40. This release also introduces a new feature presented as personalization Direct method. It also brings clarifications for the DGIs containing CRT key components in Annex A.2. This is possible to have more than one Secure Channel key set as defined in section 3.2.5. New DGIs for EMV application internal data are defined in Annex A.2. An optional file structure creation mechanism is defined in Annex A.5. All revisions and insertions are marked with a sidebar.

vi Audience July 2007 2.

Scope

In this specification, card personalization means the use of data personalization commands that are sent to a card that already contains the basic EMV application. This is sometimes referred to as “on-card” personalization. The specification does not cover cards where an application load file is personalized before being loaded onto the card. In terms of the lifecycle of the card, card personalization is assumed to take place after pre-personalization (see Definitions) and prior to card issuance. However nonEMV applications may well use the same personalization process as defined in this specification. Other card personalization activities – embossing, magnetic stripe encoding and the personalization of non-EMV IC applications – are not covered. The interface between the card issuer and the data preparation system is not covered. Involved Entities These terms are described in the Definitions section below. Card Personalization Bureau Manufacturer Cardholder Personalization device Data Preparation Issuer data Issuer

vii Audience July 2007 Indirect & Direct Methods of Establishing & Using Secure Personalisation Channels Two methods are included in this specification – the indirect method and the direct method. Indirect Method This method is defined in both the current version (1.1) and the original version (1.0) of the EMV Card Personalisation Specification. The rationale is that the Data Preparation System should not need to have knowledge of the ICC data used to establish the secure channel for a particular target card/application. The method assumes two security zones, one between the Data Preparation System and the Personalisation Device, and a second zone between the Personalisation Device and the ICC. The role of the Personalisation Device is: ƒ To receive the DGI data and Personalisation Device Instructions (PDI) from the Data Preparation System ƒ To establish the secure channel to the card ƒ To decrypt/re-encrypt the sensitive data (application keys & PIN), and ƒ To create and send personalisation APDU commands to the card. An example of the process of Indirect method is shown in Annex B. Direct Method This method has been added in the current version (1.1) of the EMV Card Personalisation Specification. The rationale is to reduce the time taken by the Personalisation Device by pre-computing APDU commands in the Data Preparation System. The method assumes a single security zone between the Data Preparation System and the ICC. The Personalisation Device does not need to create APDU commands; it simply passes on the commands received from the Data Preparation System. However the Data Preparation System needs to carry out additional preparation work. If the Secure Channel Key Set in the card (KENC, KMAC, KDEC) is not known, a pre-personalisation process is needed to load a derived key set known by the Data Preparation System on to the ICC. The ICC needs to produce a pseudo-random number, which the Data Preparation System can predict. The Data Preparation System also needs to be able to predict the Secure Channel Sequence Counter. The Data Preparation System uses this information to pre-compute the personalisation APDU commands for the ICC application. Note: In terms of the interface between the ICC and the Personalisation Device, the formats of the personalisation messages are the same for either the indirect or the direct method. The main difference between the two methods is the allocation of processing between the Personalisation Device and the Data Preparation System.

viii Audience July 2007 3. Audience There are three intended audiences for this document: 1. Designers of EMV applications This audience will use this document as one of the inputs to their design process. The areas that are impacted by this document are:

  • Design of the file and data structure for the EMV application on the IC card.
  • Design and processing of the personalization commands. 2. Designers of Personalization Device systems This audience will use this document as a specification for part of the design for their processing, in particular the input and output interfaces. 3. Designers of Data Preparation systems This audience will use this document as a specification for part of the design for their processing, in particular the output interface. ix Normative

References

July 2007 4. Normative References The following documents contain provisions that are referenced in this specification. The latest version shall apply unless a publication date is explicitly stated: EMV Version 4.1 EMVCo Specification Update: Bulletin no. 23 First edition EMVCo Specification Update: Bulletin no. 40 First edition GlobalPlatform Card Specification GlobalPlatform Messaging Specification GlobalPlatform Systems Profiles Specification ISO/IEC 7816-3 ISO/IEC 7816-4 ISO/IEC 7816-5 ISO/IEC 7816-6 Integrated Circuit Card Specifications for Payment Systems Book 1 – Application Independent ICC to Terminal Interface Requirements Integrated Circuit Card Specifications for Payment Systems Book 2 – Security and Key Management Integrated Circuit Card Specifications for Payment Systems Book 3 – Application Specification EMVCo Specification Update: Bulletin no. 23: First edition October 2003: Corrections and Clarifications to EMV Card Personalization Specification EMVCo Specification Update: Bulletin no. 40: First edition February 2005: Additional Corrections and Clarifications to EMV Card Personalization Specification GlobalPlatform Card Specification V2.2 GlobalPlatform Messaging Specification V1.0 GlobalPlatform Systems Profiles Specification

  • V1.1 Identification cards
  • Integrated circuit(s) cards with contacts
  • Part 3: Electronic signals and transmission protocols Identification cards
  • Integrated circuit(s) cards with contacts
  • Part 4, Inter-industry commands for interchange Identification cards
  • Integrated circuit(s) cards with contacts
  • Part 5, Numbering system and registration procedure for application identifiers Identification cards
  • Integrated circuit(s) cards with contacts
  • Part 6, Inter-industry data elements x ISO/IEC 9564-1 ISO/IEC 9797-1 ISO/IEC 10116 ISO/IEC 18033-3 Normative References July 2007 Banking – Personal Identification Number (PIN) – Part 1Basic principles and requirements for online PIN handling in ATM and POS systems Information Technology – Security Techniques – Message Authentication Codes – Part 1: Mechanisms using a block cipher Information Technology – Modes of Operation of an n-bit block cipher algorithm Information Technology – Security techniques – Encryption Algorithms – Part 3: Block Ciphers xi

Definitions

July 2007 5. Definitions The following terms are used in this specification. Application – An application resident in an EMV card. Application Command – For this document specifically, an APDU command acceptable to an application after the application has been selected. Card – An IC payment card as defined by a payment system. Card Personalization – The personalization of application data within a card, using personalization commands. Data Preparation – The process of preparing and formatting data, ready for sending to a personalization device. Payment System – For the purposes of this specification JCB, MasterCard International, or Visa International Service Association. Personalization – The personalization of application data to enable a card to be used by a cardholder. Personalization Command – A command sent to a selected EMV application in order to personalize application data. Personalization Device – A device that accepts data from a data preparation system, and sends personalization commands to a card. Pre-personalization – The initialization of card data prior to personalization. Processing Step – The action to be performed by the personalization device.

xii Abbreviations and Notations July 2007 6. Abbreviations and Notations The following abbreviations and notations are used in this specification. Additional abbreviations can be found at the end of this specification in chapter 6. AID Application Identifier ASCII American Standard Code for Information Interchange ATR Answer-to-Reset BER Basic Encoding Rules BIN Bank Identification Number CBC Cipher Block Chaining CDA Combined DDA Application Cryptogram Generation Authentication CLA Class Byte C-MAC Command Message Authentication Code CPLC Card Production Life Cycle CPS Card Personalization Specification CRN Card and Application Management System (CAMS) Reference Number CRT Chinese Remainder Theorem CSN Chip Serial Number DDA Dynamic Data Authentication DES Data Encryption Standard DF Dedicated File DGI Data Grouping Identifier ECB Electronic Code Book EF Elementary File EMV Europay, MasterCard and Visa FCI File Control Information

xiii FCP HSM IC ICC ICV ID IEC IIN INS ISO IV KMC LSB M/O MAC MIC MSB PAN PDI PIN PK RFU RSA SDA SFI Abbreviations and Notations File Control Parameter Hardware Security Module Integrated Circuit Integrated Circuit Card Initial Chaining Vector Identifier International Electrotechnical Commission Issuer Identification Number Instruction Byte International Organization for Standardization Initialization Vector DES Master Key for Personalization Session Keys Least Significant Byte Mandatory or Optional Message Authentication Code Module Identifier Code Most Significant Byte Application Primary Account Number Personalization Device Instructions Personal Identification Number Public Key Reserved for Future Use (values to be ignored) Rivest, Shamir and Adleman (Cryptographic Algorithm) Static Data Authentication Short File Identifier July 2007

xiv Abbreviations and Notations July 2007 SKU Personalization Session Key TK Transport Key TLV Tag, Length, Value var. Variable The following notations apply: Hexadecimal Notation Values expressed in hexadecimal form are enclosed in single quotes (e.g., ‘_’). For example, 27509 decimal is expressed in hexadecimal as ‘6B75’. Letters used to express constant hexadecimal values are always upper case (‘A’ - ‘F’). Where lower case is used, the letters have a different meaning explained in the text. Binary Notation Values expressed in binary form are followed by a lower case “b”. For example, ‘08’ hexadecimal is expressed in binary as 00001000b (most significant bit first). Length Fields Length fields are “big-endian” encoded. For example if a two-byte length field has a hexadecimal value of ‘13F’ (319 in decimal), it is encoded as ‘013F’. Operators and Functions ∧ ∨:= () or [ ] B1 ⎢⎢B2 [B1 ⎢⎢B2] DES()[ ] DES-1()[ ] Logical AND. Logical OR. Assignment (of a value to a variable). Ordered set (of data elements). Concatenation of bytes B1 (the most significant byte) and B2 (the least significant byte). Value of the concatenation of bytes B1 and B2. The data in the square brackets is encrypted using DES encryption and the key in the normal brackets. The data in the square brackets is decrypted using DES decryption and the key in the normal brackets.

xv DES3()[ ] DES3-1()[ ] XOR Abbreviations and Notations July 2007 The data in the square brackets is encrypted using triple DES encryption and the key in the normal brackets. Triple DES consists of encrypting an 8byte plaintext block X to an 8 byte ciphertext block Y using a double length (16 byte) secret key K = (KL || KR) where KL and KR are DES keys. This is done as follows: Y:= DES3(K)[X]:= DES(KL)[DES-1(KR)[DES(KL)[X]]] The encryption process is illustrated in section 5.7.1.1. The data in the square brackets is decrypted using triple DES decryption and the key in the normal brackets. Triple DES consists of decrypting an 8byte plaintext block X to an 8 byte ciphertext block Y using a double length (16 byte) secret key K = (KL || KR) where KL and KR are DES keys. This is done as follows: X:= DES3-1(K)[Y]:= DES-1(KL)[DES(KR)[DES-1(KL)[Y]]] Exclusive OR Requirement Numbering Requirements are highlighted by being indented and numbered with a four digit reference namely, section, subsection and requirement number. All requirements in this specification are therefore uniquely numbered with the number appearing next to each requirement. This convention is adopted to allow test specifications to be conveniently developed. A requirement can have different numbers in different versions of the specifications. Hence, all references to a requirement must include the version of the document as well as the requirement’s number. Document Word Usage The following words are used often in this document and have specific meanings:

  • “Shall” or “Must” Defines a product or system capability that is required, compelled and mandatory.
  • “Should” Defines a product or system capability that is highly recommended.
  • “May” Defines a product or system capability that is optional. xvi Abbreviations and Notations July 2007 THIS PAGE LEFT INTENTIONALLY BLANK 1 Card Personalization Data Processing July 2007 1 Card Personalization Data Processing 1.1 Overview of the Process Within a personalization bureau environment the processing of Personalization Device Instructions (PDI) and IC card personalization data processing requires the following three functional steps: 1. Data preparation 2. Personalization device set-up and processing 3. IC card application processing. Each of these steps, together with the two interfaces (1 to 2, 2 to 3), is briefly described below and discussed in detail in subsequent chapters. An overview diagram of the complete EMV Card Personalization process Indirect method appears in Annex B. Data Preparation Data preparation is the process that creates the data that is to be placed in an IC card application during card personalization. Some of the data created may be the same across all cards in a batch; other data may vary by card. Some data, such as keys, may be secret and may need to be encrypted at all times during the personalization process. Data preparation may be a single process or it may require interaction between multiple systems. Much of the definition of data preparation is application specific. This document focuses on the data preparation processes that are commonly used for EMV cards and a description of these is given in Chapter 2. Data Preparation-Personalization Device Interface The output of the data preparation process is a file of personalization data, which is passed to the personalization device. The format of the file records is shown in Table 8. The data preparation system must protect the completed personalization data file for integrity and authenticity (e.g. MAC or signed hash). An example of implementation in XML format is provided in the GlobalPlatform Messaging Specification section 5. 2 Card Personalization Data Processing July 2007 Personalization Device The personalization device is the terminal that acts on Processing Step and Personalization Device Instruction data to control how personalization data is selected and then sent to the IC card application. The Processing Step indicates the format of the personalization data to be sent t the IC card application. Depending on the Processing Step for IC card personalization processes this device must have access to a security module (HSM) to establish and operate a secure channel between the personalization device on the one hand and the application on an IC card on the other. If the Processing Step indicates the pre-computed APDU commands as personalization data then the commands to establish the secure channel are part of the pre-computed APDU commands therefore the personalization device is not required to explicitly establish the secure channel with the IC card application. The secure channel services consist of MAC verification/ generation e.g. on commands sent to the application, and decryption and reencryption of secret data e.g. PIN values. Personalization device processing is described in Chapter 3. Personalization Device-ICC Interface The personalization device sends a series of personalization commands to the ICC. The personalization command flow is shown in Figure 6. The IC Card Application The IC card application receives the personalization data from the personalization device and stores it in its assigned location, for use when the EMV card application becomes operational. Section 4.1 describes the processing requirements for an EMV card application that must be performed prior to the start of personalization. The actual processing of the EMV card prior to personalization (pre-personalization) is outside the scope of this specification. However it is assumed that the EMV card application will have secure channel keys established for personalization prior to the start of the personalization process.

1.2 The Infrastructure of Card Personalization The personalization process described in this document is designed to facilitate the personalization of the EMV application on IC cards. It creates a personalization infrastructure that allows for upgrades to EMV applications without requiring a change to the personalization device processing, and one that can also be extended to other applications in a generic way. The personalization infrastructure consists of:

3 Card Personalization Data Processing July 2007

  • Standard security between the personalization device and the IC card. This is summarized in section 1.3.
  • Standard commands for sending personalization data to the IC card application. These are summarized in section 1.4.
  • A standard record format for the personalization data sent to the personalization device. This is summarized in section 1.5.

1.3 Secure Messaging At the beginning of processing by the personalization device, a secure channel is established between the personalization device and the IC card EMV application. Depending on the personalization method (see section 2), the secure channel is established either by the personalization device for the Indirect method or through the pre-computed APDU commands for the Direct method. The commands used to establish this secure channel are the INITIALIZE UPDATE command and the EXTERNAL AUTHENTICATE command. These commands are described in sections 3.2.5 and 3.2.6 respectively. Two derived keys on the IC card are used during the establishment of the secure channel. These are the KENC, used to generate a session key SKUENC which is in turn used to create and validate authentication cryptograms, and the KMAC, used to generate a session key SKUMAC which is in turn used to compute the MAC of the EXTERNAL AUTHENTICATE command. Both of these keys (KENC and KMAC) are derived from the same master key, the KMC. When the secure channel is to be established explicitly by the personalization device the IC card provides the personalization device with the identifiers of the KMC and the derivation data used to create the derived keys. The identification of the KMC is described in section 3.1.1. The creation of derived keys is described in section 4.1. Once a secure channel is established, personalization data can be sent to the IC card application. Based on the security level set in the EXTERNAL AUTHENTICATE command, the SKUENC may also be used to encrypt the command data field, and the SKUMAC to produce the Command Message Authentication Code (C-MAC). In Direct method the APDU commands are pre-computed according to the requested security level by the data preparation system rather than by the personalization device.

1.4 The STORE DATA Command The STORE DATA command is used to send personalization data to the card application; it is described in detail in section 3.2.7. In order to reduce personalization time, the data preparation process organizes the personalization data to be sent to an EMV card application by the personalization device into data groupings. A Data Grouping Identifier (DGI) identifies each data grouping. The IC card application uses the DGI to determine how the data grouping is to be processed after it is received from the personalization device. Much of the data for an application is organized into records within the application when the application is designed. Where this is the case, the easiest way to create data groupings for an application is to make each record in the application a data

4 Card Personalization Data Processing July 2007 grouping. The principles of data grouping are described in section 2.2. In the Indirect method the personalization devices parse the input record and create a STORE DATA command for each data grouping or group of data groupings (see section 2.4.5) in the input record. Some data groupings will contain data that must be kept secret during transmission from the personalization device to the card application; this can be done using a secret key known on either side of this interface. In this case an additional derived key (KDEK) on the IC card is used to generate a session key SKUDEK. The KDEK is derived from the same master key (KMC) as the KENC and KMAC. The IC card provides the personalization device with the identifiers of the KMC and the derivation data used to create the derived key. The SKUDEK, described in section 5.3 may be used for this encryption. In addition to this requirement for security, the secure messaging described in section 1.3 provides the option for two additional security features: the C-MAC and command data field encryption for all subsequent STORE DATA commands. In the Direct method the data grouping or group of data groupings are wrapped into the pre-computed STORE DATA commands and the data groupings containing secret data have been encrypted under the IC card’s SKUDEK by the data preparation system.

1.5 The Common Personalization Record Format The common personalization approach requires a common personalization record format. This record format is described in section 2.6. This format has been developed to support the personalization of one or more applications on a single IC card. The overall card personalization process normally consists of a series of processing modules that perform personalization tasks (e.g. embossing and magnetic stripe encoding). Each processing module uses data from the input record for a card to perform its task for that card. In the format defined in this document, the data for a processing module is identified by a Module Identifier Code (MIC). Each MIC is followed by the data to be processed for that processing module. Many processing modules also require a length field that specifies the length of the data for that processing module. The input for the personalization process for non IC card application data is defined in documentation provided by the personalizer, however, the basic structure of the most commonly used personalization record format allows all types of personalization data to be included in the same file. There will be a MIC that identifies data to be placed on an IC card. The exact MIC used for personalization data must be established between the data preparation processing system(s) and the personalization device processing system(s). In Figure 1, which shows the organization of personalization data for the IC card module, MIC2 is used to represent the IC card personalization data. MIC1 and MIC3 indicate non-ICC personalization data.

5 Card Personalization Data Processing July 2007 Figure 1 – Overview of IC Card Personalization Data Format The header portion of this record contains information that is common to all IC card applications to be personalized. Header information is described in Table 8. An overview of the format of the data for each application is shown in Figure 2. Figure 2 – Overview of Personalization Data for an IC Card Application header data for chip card appl 1 data for chip card appl 2 data for chip card appl 3 data for perso device data to be logged data to be sent to IC Application

  • data for personalization device The first part of the data for an IC card application is data that provides processing information to the personalization device. This data consists of the AID for the application, if required the identifier of the Transport Key (TK) used to encrypt secret data in the record for the application (see section 6.36), processing steps and if required the processing instructions for the personalization device. The creation of personalization device instructions is described in section 2.4. 6 Card Personalization Data Processing July 2007
  • data to be logged The second part of the data for an IC card application is the data to be logged for that application. However, the personalization device is not aware of what data is contained in the data groupings. Therefore, data that must be logged must be sent to the personalization device in a manner that indicates that this is data that must be logged. The data preparation process for the application must perform this task and instruct the personalization device. The data to be logged may be a duplicate copy of some of the data to be sent to the IC card application. See section 2.5 for additional information.
  • data to be sent to the IC application The data to be sent to the IC card application is in the third part of the data for an IC card application. Depending on the Processing Step this data may consist of one or more data groupings with a Data Grouping Identifier (DGI) and a length field for Processing Step ‘0F’ in Indirect method. See section 2.2 for additional information on the format and creation of this data. For Processing Step ‘0B’ in Direct method this data consists of one or more pre-computed APDU command pre-pended by an indicator of the APDU command case and the length of the APDU command. See section 3.2 for additional information on the format and creation of this data. Note that the information provided in section 2.2 applies to each individual data grouping within a pre-computed STORE DATA command. A complete description of the format for the personalization data for an IC card application is given in section 2.6. 7 Data Preparation July 2007 2 Data Preparation The data preparation process creates application data that is used to personalize the IC card application and depending on the Processing Step the Personalization Device Instructions (PDI) data that are used to direct the personalization process. Whatever is produced by the data preparation process must be transported securely to the personalization device itself (unless it is created in an HSM attached to the personalization device). Any secret data created by the data preparation process remotely from the personalization device must therefore be encrypted before transmission and all data files generated remotely from the personalization device must be protected by a Message Authentication Code (MAC) before transmission. For Indirect method where the personalization device computes the APDU commands the data preparation process consists of the following five steps: 1. Creating personalization data. 2. Combining personalization data into data groupings. 3. Creating personalization instructions. 4. Creating data to be logged for the application. 5. Creating the input file to the personalization device. For Direct method where the data preparation system computes the APDU commands the data preparation process consists of the following five steps: 1. Creating personalization data. 2. Combining personalization data into data groupings. 3. Pre-computing APDU commands. 4. Creating data to be logged for the application. 5. Creating the input file to the personalization device.

2.1 Creating Personalization Data The EMV CPS compliant application developer must determine what data is to be placed in the application at personalization time, and must determine the source of the data. In some cases a single data preparation process will create all of the data. In other cases, the data will come from multiple sources. The data falls into three categories: 1. Issuer Master Keys and Data 2. Application Keys and Certificates 3. Application Data

8 Data Preparation July 2007 2.1.1 Issuer Master Keys and Data EMV personalization cannot take place unless the card issuer creates master keys and other specific data. The master keys are used in two ways, firstly to support secure transmission of personalization data and secondly to create application-level data for personalization of an EMV application. Some of the data may be used to manage the personalization process and some will be placed on the card during personalization. Other processes may also use one or more of the master keys used by the personalization process. In this circumstance, a method of importing or exporting master keys to allow appropriate data sharing between processes will be required. Prior to the personalization process the identifier of the personalization master key KMCID, key version number, KEYDATA and the corresponding relevant keys, must be placed onto the card. KMCID and key version number are used to access the issuer personalization master key (KMC) in order to derive the card unique static keys using diversification data (KEYDATA). The 6 byte KMCID (e.g. IIN right justified and left padded with 1111b per quartet) concatenated with the 4 byte CSN (least significant bytes) form the key diversification data that must be placed in tag ‘CF’. This same data must be used to form the response to the INITIALIZE UPDATE command. Table 1 – Data Content for tag ‘CF’ Data Element KEYDATA

Description

Key derivation data:

  • KMCID (6 bytes)
  • CSN (4 bytes)1 Length 10 Format Binary 2.1.2 EMV Application Keys and Certificates For EMV applications an issuer RSA key pair must be generated and certified by the Payment System Certification Authority, for use in SDA and DDA/CDA. Application level symmetric DES secret keys for transaction certificate generation etc. must be created during data preparation. In most cases such keys are derived from appropriate issuer master keys. If public key technology (DDA/CDA) is supported in the card, then a card level EMV application RSA key pair must be generated and certified by the issuer. A second 1 If the CSN does not ensure the uniqueness of KEYDATA across different batches of cards other unique data (e.g. 2 right most bytes of IC serial number and 2 bytes of IC batch identifier) should be used instead. 9 Data Preparation July 2007 application RSA key pair may be required for PIN decipherment. The issuer certificate(s) corresponding to the issuer private key used to certify the application public key(s) must also be stored in the application.

2.1.3 Application Data Application data will fall into two categories

It may be common across all IC cards for an issuer (e.g. the identifier of the issuer) or it may be unique to the IC card (e.g. the PAN of a debit/credit application).

10 Data Preparation July 2007 2.2 Creation of Data Groupings After the personalization data for the IC card application has been created, it must be placed into the correct data grouping. The design of the data groupings plays a key part of the personalization process. The application designer will have created default file and record definitions. An optional file structure creation mechanism is defined in Annex A.5. In general, a data grouping should be a record for the application. As all of the data in a grouping will be sent to the IC card application in a single command, having a data grouping based on a record will reduce the processing required by the IC card application. The following requirements and guidelines shall be used when creating data groupings: 1. All data elements to be sent to the IC card during the personalization process must be placed in a data grouping. 2. DES keys must be placed in a data grouping that consists of only DES keys. More than one data grouping of DES keys may be created. 3. For ease of IC card management, most, if not all, of the content of each data grouping should be identical to the content of a record for the application. 4. When assigning identifiers for data groupings, use of a combination of the SFI and the record number is recommended. For the DGIs with the first byte equal to ‘01’ through ‘1E’, the first byte indicates the SFI in which the data is to be stored and the second byte indicates the record number within the SFI. 5. The first two or three data bytes of any DGI for the EMV application in the range ‘01xx’ through ‘0Axx’ will consist of a record template tag ‘70’ and the length of the remaining record data. 6. There are benefits from grouping all fixed length data elements together, and placing all variable length data elements into another data grouping. 7. It is recommended that the length of data in a data grouping does not exceed 237 bytes. 8. Application designers do not usually place data elements that are only used by internal IC card application processing in records. However, these data elements must be placed in one or more DGIs. It is recommended that these DGIs contain only data elements used exclusively for internal IC card application processing. 9. If an application contains information in its FCI (the response to the SELECT command) that is dependent on the personalization data, one or more data groupings must be created for the FCI data. 10. Data grouping identifiers (DGI) ‘9F60’ through ‘9F6F’ are reserved for sending payment systems proprietary data, e.g. card production life cycle (CPLC) data to the IC card (rather than the application) and must not be used as a DGI by an EMV CPS compliant application.

11 Data Preparation July 2007 11. Data grouping identifiers (DGIs) ‘7FF0’ through ‘7FFE’ are reserved for application-independent personalization processing and must not be used as a DGI by an EMV CPS compliant application. 12. Data grouping identifiers (DGIs) ‘8F01’, ‘7F01’ and ‘00CF’ are reserved respectively for the secure channel derived keys, the key related data and the key derivation data and must not be used as a DGI by an EMV CPS compliant application for other purposes. 13. Data grouping identifiers (DGIs) ‘0062’ is reserved for file structure creation and must not be used as a DGI by an EMV CPS compliant application for other purposes. 14. The number of data groupings should be minimized to improve performance during the personalization process. 15. If the data grouping is to be encrypted and the data is a DES key or PIN Block data, no padding is required. Otherwise all data must be padded. Such padding is accomplished by appending an ‘80’, followed by 0-7 bytes of ‘00’. The length of the data part of the data grouping must be a multiple of 8bytes. 16. The Key Check Value for any DES key will be computed by encrypting 8 bytes of ‘00’ using ECB 3DES with the key concerned. The Key Check Value is defined in section 6.15. 17. It is recommended that the data preparation system generate the Reference PIN Block according to ISO 9564-1 format 1. The card application must reformat the PIN Block if necessary. 18. The data within a DGI with a leftmost byte of the identifier in the range of ‘80’ to ‘8F’ is always encrypted. Nevertheless, encrypted data may also be included in a DGI outside this range. The DGI must be coded on two bytes in binary format, followed by a length indicator coded as follows: ƒ On 1-byte in binary format if the length of data is from ‘00’ to ‘FE’ (0 to 254 bytes). ƒ On 3-byte with the first byte set to ‘FF’ followed by 2 bytes in binary format from ‘0000’ to ‘FFFE’ (0 to 65 534), e.g. ‘FF01AF’ indicates a length of 431 bytes.

2.3 Completion of Personalization If specific data needs to be sent to the IC card application at the end of the personalization process, this can be indicated to the Personalization Device by using a special Data Grouping Identifier (‘7FFF’) that will be included in the last STORE DATA command. The contents of this DGI are shown in Table 2. Table 2 – Data Content for DGI ‘7FFF’ Data Element DGI Length Description ‘7FFF’ Length of data Data Length 2 1 or 3 var. Format Binary Binary var.

12 Data Preparation July 2007 This DGI can in turn be used as the command body of a final STORE DATA command issued in the personalization of the EMV application. The DGI ‘7FFF’ is not mandatory. Independently of the DGIs (including ‘7FFF’), the personalization device shall set b8 of the P1 parameter in the last STORE DATA command to 1b, indicating the completion of personalization for the application.

2.3.1 Multiple Transport Key Capability It is also possible to encrypt secret data per application under different Transport Keys while the data is being transferred from the data preparation system to the personalization device. See Table 9 for an explanation of this process. The usual reason for having multiple TKs would be to encrypt PINs under a PEK (PIN Encryption Key) and encrypt other secret data under a different Transport Key. This use of multiple TKs allows separation between true KEKs (Key Encryption Keys), PEKs and DEKs (Data Encryption Keys).

2.4 Processing Steps and Personalization Device Instructions A Processing Step (PS) describes what action is to be performed by the personalization device. For EMV cards the only action to be performed is personalization based on DGIs and immaterial of whether the personalization APDU commands are computed by the personalization device (i.e. DGIs within the ICC data field) or by the data preparation system (i.e. pre-computed APDU commands within the ICC data field). For Indirect method as the APDU commands are to be computed by the personalization device the value of the ACT field (see Table 11) within the PS data element (see Table 8 section 3a.2) for this step must be set to ’0F’. For Direct method as the personalization is performed using the pre-computed APDU commands by the Data Preparation System this value must be set to ‘0B’. The personalization device instructions are special instructions that are created during the data preparation process and are used by the personalization device during the personalization process. The personalization device instructions are not sent to the card. At this point no personalization device instructions are defined for the Processing Step ‘0B’. The personalization device instructions for Processing Step ‘0F’ are:

13 Data Preparation July 2007 Order – The order in which data groupings must be sent to the IC card application is specified in this instruction. Version Control – As IC card applications are modified and different versions of their specifications are created, the required data groupings for the application may change. Data groupings that vary by application version, and which may be rejected by the IC card application without causing the personalization process to terminate with an error, are specified in this instruction. Encryption – Data groupings that must be decrypted and re-encrypted by the personalization device are specified in this instruction. Random Number – If a random number is required for any processing of this application, the random number in this field must be used. Group – Any set of data groupings that must be sent to the IC card application within one STORE DATA command is specified with this instruction. Security Level – The expected security level of the secure channel to be established between the personalization device and the IC card application. Update CPLC – This is used if the personalization device is required to generate the DGI ‘9F66’ with the appropriate CPLC data and send it to the card within one STORE DATA command. The personalization device instructions for personalization must be placed in a PDI field within the Processing Step.

2.4.1 Order that Data must be sent to the IC Card In general, the data for an IC card application should be organized into data groupings in a manner that allows the data groupings to be sent to the IC card application in any order. However, there may be applications where it is not possible to organize data in this manner. To inform the Personalization Device of these situations, the ORDER field in the PDI field (see Table 12) must be created. The contents of the ORDER field are shown in Table 3. If a DGI is part of a group of DGIs (See section 2.4.5) then only the first DGI listed for that group should be included in this ORDER field. Multiple data grouping orders may be created. It is also possible to indicate to the personalization device the order in which the DGI or a group of DGIs is to be sent to the IC application. A DGI can only occur once within the value fields of all ORDER statements taken together. If the orders of STORE DATA command are set to ‘00’ for Order #1 and Order #n then there is no requirement that Order #1 must be sent to the IC card before Order #n. The DGI entries must be concatenated together without separators. For example, if DGIs ‘0101’ and ‘0019’ were the DGIs in Order # 1, they would be coded ‘01010019’.

14 Data Preparation July 2007 When a DGI is part of a set of GROUPed DGIs, for example DGI ‘0129’ is part of GROUP ‘02080129’ and should be sent to the IC application after DGI ‘0101’ then the Order #n should be ‘01010208’. Table 3 – Data Content for the Field ORDER Data Element Order #1 Order of STORE DATA command for Order #1 Length Order of DGIs Order #n Order of STORE DATA command for Order #n Length Order of DGIs Description ‘01’ ‘00’ order does not matter ‘01’ must be placed in the first STORE DATA command ‘02’ must be placed in the second STORE DATA command ‘nn’ must be placed in the ‘nn’th STORE DATA command ‘FF’ must be placed in the last STORE DATA command Length of Order#1 List of DGIs in Order #1 … ‘nn’ ‘00’ order does not matter ‘01’ must be placed in the first STORE DATA command ‘02’ must be placed in the second STORE DATA command ‘nn’ must be placed in the ‘nn’th STORE DATA command ‘FF’ must be placed in the last STORE DATA command Length of Order #n List of DGIs in Order #n Length 1 1 Format Binary Binary 1 Binary var. Binary 1 Binary 1 Binary 1 Binary var. Binary 2.4.2 Support for Migration to New Versions The data preparation process does not necessarily know the version of the application it is creating data for. Given that applications will reject all unknown DGIs with error responses, migrating application versions will require synchronization between the data preparation process and the personalization process. This is undesirable. In order to ease migration between new versions, one approach would be to produce personalization data that is a superset of the personalization data for all possible application versions. By itself this does not completely ease migration problems, it is necessary to inform the personalization device of such a transition process so that it can detect allowed rejections. The

15 Data Preparation July 2007 version control field (VERCNTL) in the IC Card Application Data (see Table 12) is the mechanism to signal to the personalization device what are acceptable rejections. The contents of the VERCNTL field are shown in Table 4. If a DGI is listed in VERCNTL field and the response from the IC card application is ‘6A88’ (considered a rejection of a data grouping), the personalization process must not be aborted. Table 4 – Data Contents for the Version Control Field VERCNTL Data Element List of DGIs Description List of data grouping identifiers that may be rejected without error. Length var. Format Binary The DGI entries must be concatenated together without separators. For example, if DGIs ‘0101’ and ‘0029’ may be rejected without error, they would be coded ‘01010029’.

2.4.3 Encrypted Data Groupings To inform the personalization device of data groupings that must be encrypted, the ENC field in the IC Card Application Data (see Table 12) must be created. All of the data, not just the secret data, in the data grouping is encrypted. The DGI and the length field for the data grouping are not encrypted. The contents of the ENC field are shown in Table 5. The specifications for the encryption process appropriate to a given data grouping for the IC card application must match the equivalent encryption process, either in the data preparation process or in a local process associated with the personalization device. Normally the encryption process of the card application mirrors that of the data preparation process. Since the encryption process for the EMV application is in ECB mode (if the FORMATTK ‘00’ is used), the encryption of the prepared data must also be done in ECB mode. In this case the personalization device decrypts the DGI in ECB mode using the Transport Key before re-encrypting it in ECB mode under the card secure channel session key SKUDEK. Table 5 – Data Content for the Field ENC Data Element DGI #1 Encryption type DGI #n Description The identifier of the first data grouping to be encrypted Type of encryption needed ’11’ – to be encrypted using SKUDEK in ECB mode The identifier of the nth data grouping to be encrypted Length 2 1 2 Format Binary Binary Binary

16 Data Preparation July 2007 Data Element Encryption type Description Type of encryption needed ’11’ – to be encrypted using SKUDEK in ECB mode Length 1 Format Binary 2.4.4 PIN Block Format and Random Numbers Between the data preparation system and the personalization system the simple encryption of secret data is sometimes insufficient for protecting the exchanged data. If the encrypted data is not sufficiently diverse (e.g. a PIN-block having only PINdigits as variations), a random number can be used to XOR the secret data before encryption. To inform the personalization device that the random number is to be used for processing of this application, the RANDOM field in the IC Card Application Data (see Table 8) is the mechanism that must be used. The use of this random number mechanism must be indicated by the setting of TYPETK. In particular the TYPETK in Table 10 takes a value of “TK using RANDOM field and XOR operation” (b7=1, b6=0) as described in Table 25. In this case the secret data must be XORed with the random number prior to encryption and after decryption. If the RANDOM field is shorter than the data to be XORed, the data to be XORed must be divided into blocks the length of the RANDOM field. If the final block is shorter than the RANDOM field, the leftmost bytes of the RANDOM field must be used to XOR the short block. The random number to use is contained in the RANDOM field as shown in Table 8. If ISO 9564-1 format 1 is used to transport the PIN block, the use of the above random number method to diversify the PIN block during transportation is unnecessary. In this case, if the PIN block format stored within the card application is different from ISO 9564-1 format 1, the IC application must reformat the PIN block (e.g. to the format defined in the EMV VERIFY command).

2.4.5 Grouping of DGIs DGIs may be grouped using the GROUP mechanism described below. Personalization devices must not group DGIs within a single STORE DATA command without a GROUP field within the Processing Device Instruction specifying the DGIs to be applied jointly. Where a STORE DATA command is to process multiple DGIs, DGIs within a group shall be concatenated in the same order indicated in the GROUP field. The DGI entries must be concatenated without separators. For example, if DGIs ‘0208’ and ‘0029’ were the Grouped DGIs in GROUP # 1, they would be coded ‘02080029’. The Personalization Device must set the STORE DATA command with

17 Data Preparation July 2007 DGI ‘0208’ followed by DGI ‘0029’ (including identifier, length and content of each DGI). Table 6 – Data Content for the Field GROUP Data Element Group #1 Length List and order of DGIs for Group #1 Group #n Length List and order of DGIs for Group #n Description ‘01’ Length of Group #1 List of DGIs in Group #1 … ‘nn’ Length of Order #n List of DGIs in Group #n Length 1 1 var. 1 1 var. Format Binary Binary Binary Binary Binary Binary 2.4.6 Security Level Indicator of Secure Channel Sessions While not required, it is possible for a data preparation system to define different security level of secure channel for different DGIs in the personalization process of an application. This could be achieved by duplicating the SECLEV field within the PDI as many times as it is required by the Issuer. The following requirements exist: ƒ When only one security level is required for the entire personalization session of an application only one SECLEV field shall be present in the PDI. ƒ A value of ‘FF’ in the SECLEV indicates that more than one security levels of secure channel are required for the personalization of the application. ƒ If several security levels are specified, a DGI shall appear only once in the DGI list associated to security levels. ƒ When several security levels are specified, each security level requires to a new secure channel initiation. Performance objectives may be achieved by regrouping and ordering DGIs according to their security level requirements. The LASTSCS field indicates whether the personalization is complete and the personalization device shall set b8 of P1 of the last STORE DATA command to 1 or not. If value of this field is set to ‘01’ it indicates that the personalization of the application is not complete yet and further process is required. Note that further process may be in a subsequent Processing Step or in another personalization session that is out of scope of this document.

18 Data Preparation July 2007 Table 7 – Data Content for the Field SECLEV Data Element SECLEV Description - Security level for the only secure channel of the personalization session (See Table 19 for the value of this field) Length 1 Format Binary NBSECLEV SECLEV #1 NBDGISECLEV#1 DGISECLEV#1 SECLEV #2 NBDGISECLEV#2 DGISECLEV#2 - ‘FF’ = more than one security level for secure messaging of the personalization session defined (see next field) Number of different security levels defined for the personalization session Security level for secure channel assigned to the first set of DGIs. See Table 19 for the value of this field Number of DGIs assigned to the SECLEV #1 List of DGIs assigned to the security level SECLEV #1. For grouped DGIs only the first DGI of the group shall be listed Security level for secure channel assigned to the second set of DGIs. See Table 19 for the value of this field Number of DGIs assigned to the SECLEV #2 List of DGIs assigned to the security level SECLEV #2. For grouped DGIs only the first DGI of the group shall be listed 0 or 1 0 or 1 Binary Binary 0 or 2 Binary 0 or Var. Binary 0 or 1 Binary 0 or 2 Binary 0 or Var. Binary SECLEV #n LASTSCS Security level for secure channel assigned to the remaining DGIs (those that are not assigned to a previous security level). See Table 19 for the value of this field. ‘00’ = Last STORE DATA command shall have b8 of P1 set to 1 0 or 1 Binary 0 or 1 Binary ‘01’ = Last STORE DATA command shall have b8 of P1 set to 0

19 Data Preparation July 2007 2.5 Creation of Personalization Log Data Issuers may need data from the personalization process to be logged. However, the personalization device is not aware of what data is contained in the data groupings. Therefore, data that must be logged must be sent to the personalization device in a manner that indicates that this is data that must be logged. The personalization device must handle the logging of data that the personalization device is aware of, such as personalization date. To inform the personalization device of application data that must be logged, the LOGDATA field in the IC Card Application Data (see Table 8) must be created. The data contained in this field usually duplicates some of the data in the data groupings to be sent to the IC card application. This is the actual data to be logged; it is not a list of DGIs. One example of the possible contents of LOGDATA would be all of the personalization data for the application. In that case, the contents of LOGDATA and ICCDATA (see Table 8) would be the same. Another example would be to only include an identifier of the card/cardholder for the application in LOGDATA. For a credit/debit application, this could be just the PAN.

2.6 Data Preparation-Personalization Device Interface Format This section describes the format for sending EMV card application data to the personalization device. The record format allows card management data for personalization as well as functions other than personalization to be included in the file. These functions are referred to in this document as processing steps. Examples of other types of card management data are load or install application. Table 8 provides the details of the format for the EMV card application data. Sections 1 and 2 of the data format provide the details for the data that is common to all IC card applications. Section 3 provides the details of the data for the first IC card application (the EMV application); there must be as many section 3s as the value of COUNTAID. They must be presented in the same order as in the list of AIDs in section 2 of Table 8. The data for an application has four parts. These are identified as a, b, c and d in sections 3 of Table 8. The first part (a) is processing data for the personalization device for the IC card application. This part of the data is subdivided into parts “a1” and “a2”. The second part (b) is the data for the IC card application to be logged by the personalization device.

20 Data Preparation July 2007 The third part (c) is the data to be sent to the IC card application. The fourth part (d) is the MAC related information for the IC card application data. Table 8 – IC Card Application Data sent to the Personalization Device Section 1 2 Data Element MIC (Module Identifier Code) LCCA VNL LDATA LHDR LCRN CRN STATUSCOLL NUMBERPID LIDVC1 Description An identifier that specifies that this is data for an IC card application(s). This field matches current personalization standards for identifying the type of data that follows. The length and values of this field are established when the personalization device is configured and is fixed format and length thereafter. Length of the IC card application data - includes all of sections 2 and 3 below. This is coded as ASCII-represented decimal digits, padded at the most significant end by zeros (ASCII “30”). Version number of this layout - shall be “02.2”2 Length from LHDR to the end of the last application’s MACINP inclusive Length of the header data for IC card applications. The length of the data from the byte immediately following this length field up to and including the AID for application #n Length of the CRN, this field may be zero meaning no CRN present Shall be unique per record - see GlobalPlatform Messaging Specification Collator (see GlobalPlatform Messaging Specification) Status: ‘00’ – Not Applicable ‘01’ – request for collation ‘02’ – request for collation and collation data ‘03’ – collation data only ‘04’ – collation complete Number of Profile Identifiers IDVC see GlobalPlatform Messaging Specification, ‘00’ means no Profile ID present Length of IDVC Length 1 - 7 7 4 2 2 1 var. 2 1 1 Format ASCII ASCII ASCII Binary Binary Binary Binary ASCII Binary Binary 2 A personalization system implementing VNL 02.2 shall accept a MIC with VNL = 02.1

21 Data Preparation July 2007 Section Data Element IDVC1 LIDVCn IDVCn COUNTAID LAID1 AID1 LAIDN AIDN 3 LAPPL LPDD1 3a.1 LAID AID LTK FORMATTK TKDATA LPDD2 3a.2 LIDOWNER IDOWNER LPS PS Description Length Format Identifier(s) of the first card profile (see GlobalPlatform Systems Profiles Specification) … Length of IDVC Identifier(s) of the nth card profile Number of Application IDs Length of the AID for application #1 Application ID#1 in its correct relative position … Length of the AID for application #n Application ID n in its correct relative position Length of the data for IC card application #1. The length of the data from the byte immediately following this length field to and including the MAC for application #1 Length of the non-script driven personalization device data for application #1. The length of the data from the byte immediately following this length field up to but not including the field L PDD2 for application #1 Length of the AID for application #1 AID for application #1 Length of the two TK fields that follow. Set to ‘0D’ if FORMATTK = '00' The format of the TK fields that follow. See Table 9. See Table 10. Length of the second part of the personalization device data for application #1. The length of the data from the byte immediately following this length field up to but not including the length field for LOGDATA for application #1 Length of IDOWNER field The identifier of the owner of the specifications for this application Length of processing steps (PS) Processing steps for application #1. See Table 11. var. 1 var. 1 1 var. 1 var. 2 1 1 5 to 16 1 1 var. 2 1 var. 2 var. Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary

22 Data Preparation July 2007 Section Data Element 3b LLOGDATA LOGDATA LICCDATA 3c ICC Data LMACDATA MACkey 3d MACINP Description Length Format Length of LOGDATA – if there is no data to be logged, this field must be ‘0000’ See section 2.5 for a description of this field. Length of the data for application #1 to be sent to the IC card. The length of the data from the byte immediately following this length field to but not including the length field for MAC data for application #1 The data for application #1 to be sent to the IC card (see Figure 3) ‘14’ = Length of the MACkey and MACINP for application #1. If this field is ‘00’ the data has not been MACed (if generated remotely from the personalization device the data for IC card application must be protected by a MAC) Key used to compute the MAC for the data for application #1. For FORMATTK = ‘00’ this key is encrypted under the TK listed in the TKDATA field. For all other values of FORMATTK, this key is encrypted under the TK marked for MACkey encryption MAC of the data for application #1. The leftmost bytes of the computed MAC are used; the MAC is computed using the fields starting with the length of IC card application #1 (LAPPL) up to but not including the key used to compute the MAC (MACkey field) for the data in application #1; the MAC is computed with encrypted data still encrypted 2 var. 2 var. 1 16 0 or 4 Binary Binary Binary Binary Binary Binary Binary Table 9 – FORMATTK Codes and Associated Data LTK ‘0D’ ‘00’ to ‘FF’ FORMATTK ‘00’ ‘01’ Description of TKDATA The identifier of the Transport Key (TK) used to encrypt secret data for the application. This field has two parts, the first 4 bytes are the Issuer ID (the issuer BIN/IIN right justified and left padded, if necessary, with 1111b per quartet), the last 8 bytes are the version identifier of the TK See Table 10

23 Data Preparation July 2007 Table 10 – Layout of TKDATA for FORMATTK ‘01’ Field For entry #1 IDTK #1 TYPETK #1 CMODE for TK #1 Number of DGIs for TK #1 DGIs for TK #1 For entry #n IDTK #n TYPETK #n CMODE for TK #n Number of DGIs for TK #n DGIs for TK #n Description The identifier of the Transport Key (TK) used to encrypt secret data for the application. This field has two parts, the first 4 bytes are the Issuer ID (the issuer BIN/IIN right justified and left padded, if necessary, with 1111b per quartet), the last 8 bytes are the version identifier of the TK See Table 25 Algorithm associated with the TK to encrypt the secret data. ‘11’ indicates ECB The number of DGIs in the following list. A list of the DGIs encrypted under this TK. There are no delimiters in this string. If a TK encrypts DGIs ‘9101’ and ‘9104’, this list would be coded ‘91019104’ … The identifier of the Transport Key (TK) used to encrypt secret data for the application. This field has two parts, the first 4 bytes are the Issuer ID (the issuer BIN/IIN right justified and left padded, if necessary, with 1111b per quartet), the last 8 bytes are the version identifier of the TK See Table 25 Algorithm associated with the TK to encrypt the secret data. ‘11’ indicates ECB The number of DGIs in the following list. A list of the DGIs encrypted under this TK. There are no delimiters in this string. If a TK encrypts DGIs ‘9101’ and ‘9104’, this list would be coded ‘91019104’ Length 12 1 1 1 var. 12 1 1 1 var. Format Binary See Table 25 Binary Binary Binary Binary See Table 25 Binary Binary Binary

24 Data Preparation July 2007 Table 11 – Layout of Processing Steps Field Field LS1 ACTS1 REQS1 TAGS1 LPDI PDI S1 LPOINTER POINTERS1 LSn ACTSn REQSn TAGSn LPDI PDI Sn Description Length of the information for Processing Step #1 Action to be performed in Processing Step #1. The action depends on the ICC Data format: ‘0B’: Pre-computed APDU commands in the ICC Data field within the TAGS1 data field '0F': DGI in the ICC Data field within the TAGS1 data field Processing Step #1 mandatory (‘01’) or optional (‘00’) For example if the action is “initialize” and the application is already initialized, a setting of mandatory says re-initialize, a setting of optional says do not re-initialize TAG of the data within the ICC data field where the Processing Step #1 must apply. ‘EE’ for Pre-computed APDU commands ‘EF’ for DGIs as personalization data Length of the Processing Device Instructions Processing Device Instructions for Processing Step #1. Currently only defined for the personalization step. See Table 12. Length of the POINTER RFU … Length of the information for Processing Step #n Action to be performed in Processing Step #n. The action depends on the ICC Data format: ‘0B’: Pre-computed APDU commands in the ICC Data field within the TAGSn data field '0F': DGI in the ICC Data field within the TAGSn data field Processing Step #n mandatory (‘01’) or optional (‘00’). For example if the action is “initialize” and the application is already initialized, a setting of mandatory says re-initialize, a setting of optional means do not re-initialize Tag of the data within the ICC data field where the Processing Step #n must apply. ‘EE’ for Pre-computed APDU commands ‘EF’ for DGIs as personalization data Length of the Processing Device Instructions Processing Device Instructions for Processing Length 1 1 1 1 2 var. 2 var. 1 1 1 1 2 var. Format Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary Binary

25 Data Preparation Field LPOINTER POINTERSn Description Step #n. Currently only defined for the personalization step. See Table 12 Length of the POINTER RFU July 2007 Length Format 2 Binary var. Binary The PDI Field The data in the personalization device instruction (PDI) field may be part of each Processing Step field. It also contains instructions for the Processing Step. The contents of the field for the personalization Processing Step ‘0F’ are shown in Table 12. Table 12 – Personalization Device Instructions for the Personalization Processing Step ‘0F’ Field LORDER ORDER LVERCNTL VERCNTL LENC ENC LRANDOM RANDOM LGROUP GROUP SECLEV UPDATECPLC Description Length of ORDER – if no order is required for data groupings, this field is ‘0000’ See section 2.4.1 for a description of this field Length of VERCNTL – if there is no version control required, this field is ‘0000’ See section 2.4.2 for a description of this field Length of ENC – if there is no data to be encrypted, this field is ‘0000’ See section 2.4.3 for a description of this field Length of RANDOM –if there is no random number, this field is ‘0000’ See section 2.4.4 and Table 25 for a description of this field Length of GROUP – if there is no grouped DGIs, this field is ‘0000’ See section 2.4.5 for a description of this field Security level for secure messaging. See section 2.4.6 for a description of this field ‘00’ means no update – If other values, see requirement for specific applications Length 2 Format Binary var. Binary 2 Binary var. Binary 2 Binary var. Binary 2 Binary var. Binary 2 Binary var. Binary 1 or var. Binary 1 Binary There is no personalization device instruction (PDI) for the personalization Processing Step ‘0B’. The ICC Data Field The data in the ICC Data field has been “tagged” to allow it to contain data for other processing steps and personalization data. The format is shown in Figure 3.

26 Data Preparation July 2007 Figure 3 – Layout of ICC Data Portion of Record (Section 3c of Table 8) Tag of step #1 data Length of step #1 data Value of step #1 data Tag of step #2 data Length of step #2 data Value of step #2 data Tag of step #n data Length of step #n data Value of step #n data The ICC Data Field for the Processing Step ‘0F’ If personalization using DGIs within the ICC Data field is step #2 of the processing steps, Figure 4 shows how the value portion for step #2 is expanded into the dat

Shown in part. Read the original for the full text.