EMV® Card Personalisation Specification

EMV-SWG-NK15r4 EMV^® Card Personalisation Specification Version 2.0 August 2021 EMV Card Personalisation Specification v2.0

Legal Notice

Legal Notice

/ xi The EMV^® 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 NONINFRINGEMENT, 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 the EMV^® 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 the EMV^® 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 the EMV^® Specifications.

Specification v2.0 Revision Log

/ xi Revision Log The following table lists the version history for the EMV Card Personalisation Specification. EMVCo Specification Bulletins provide the detailed updates made with each specification release. Version Release Date Associated Specification Bulletins 1.0 October 2003 EMVCo Specification Update: Bulletin no. 23: First edition October 2003: Corrections and Clarifications to EMV Card Personalisation Specification 1.0 February 2005 EMVCo Specification Update: Bulletin no. 40: First edition February 2005: Additional Corrections and Clarifications to EMV Card Personalisation Specification 1.1 July 2007 None 2.0 August 2021 None (refer to section 1.5)

Specification v2.0 Contents

1. 1. 1. 1.

1.5 Changes in Version 2.0 1. 1.6. 1.6. 1. 1. 1. 1. 1. 1. 1. 1. 2. 2. 2. 2. 2. 2. 2.6. 2.6.

Specification v2. 3. 3.1.1 3.1.2 3.1. 3. 3. 3.3. 3. 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4. 3. 3. 4. 4.1. 4.1. 4. 4.2. 4.2. 4. 4.3.1 4.3.2 4.3.3 4.3.4 4.3. 4. 4. 5. 5. 5. 5. 5.4.

Specification v2.0 Contents

/ xi 5.4. 5.4. 6. 6. 6. 6. 6.4.1 6.4.2 6.4.3 6.4. 6. 6.5.1 6.5.2 6.5. 6. 6.6.1 6.6.2 6.6. 6. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7.

Specification v2.0 Contents

/ xi 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. A. A. A. A. A.

Specification v2.0 Figures

Specification v2.0 Tables

Table 4-8 STORE DATA Command Coding for Application Personalisation Data...

Specification v2.0 Tables Page x / xi * This page intentionally left blank *

Specification v2.0 1 Introduction

/ 114 1.1

Purpose

Card personalisation is one of the major cost components in the production of EMV cards. This specification standardises the EMV card personalisation process with the objective of reducing the cost of personalisation. In today’s environment, there are numerous methods of personalising EMV cards and many vendors providing the systems to personalise these cards. Each time a native card is developed, or a new application released, issuers and personalisation vendors are obliged to expend significant time and money to develop the corresponding personalisation process. In addition, these cards are typically personalised using proprietary commands, often making it difficult for card issuers to source cards from alternative suppliers or bureaus. This specification standardises EMV card personalisation 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 personalisation bureau) and an enhanced ability to switch suppliers.

1.2 Audience This document is intended for stakeholders involved in personalisation processes. In particular, 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 personalisation commands. 2. Designers of Personalisation 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. 1.3

Scope

In this specification, card personalisation means the use of data personalisation commands that are sent to a card that already contains the basic EMV application. This is sometimes referred to as "on-card" personalisation. The specification does not cover cards where an application load file is personalised before being loaded onto the card.

Specification v2.0

/ 114 In terms of the lifecycle of the card, card personalisation is assumed to take place after prepersonalisation (see Definitions) and prior to card issuance. However non-EMV applications may well use the same personalisation process as defined in this specification. Other card personalisation activities – embossing, magnetic stripe encoding and the personalisation of non-EMV IC applications – are not covered. The interface between the card issuer and the data preparation system is not covered.

1.4 Involved Entities The terms used in the diagram are described in the Definitions section below. Card Personalisation Bureau Manufacturer Cardholder Personalisation device Data Preparation Issuer data Issuer 1.5 Changes in Version 2.0 The use of AES as an alternative block cipher to DES is introduced. The Card Personalisation Specification now supports use of both SCP02 (DES based) and SCP03 (AES based) for the secure channel terminating on the card. The use of both protocols in the context of EMV personalisation is described here in this document. The Secure Channel Protocol (SCP) '02' branch as described in this document is compliant with Appendix E of the GlobalPlatform Card Specification. The Secure Channel Protocol (SCP) '03' branch is as defined in Amendment D of the GlobalPlatform Card Specification (including the S8/S16 data structure variants).

1.6 Indirect & Direct Methods of Establishing & Using Secure Personalisation Channels Two methods are included in this specification – the Indirect Method and the Direct Method.

Specification v2.0

/ 114 1.6.1 Indirect Method This method is defined in all versions 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. However, it is necessary for the Data Preparation System to be aware of whether the cards being targeted support SCP02 or SCP03 and act accordingly e.g. in data formatting to reflect block size differences between DES and AES - as well as of course to use AES cryptographic constructions. Data Preparation systems that have been targeting SCP02 cards will need to make the corresponding changes in order to target SCP03 cards. The required changes have been kept to a minimum. 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.

1.6.2 Direct Method This method is in versions (1.1) and higher 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 must also know if the cards being targeted support SCP02 or SCP03 and for SCP03 whether they support the S8 or S16 variant of SCP03. 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 Method 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.

Specification v2.0

/ 114 1.7 Normative Specification

References

The following specifications contain provisions that are referenced in this specification. The latest version including all published amendments shall apply unless a publication date is explicitly stated. Table 1-1 Normative Specification References Reference Publication Name EMV Version 4.3 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 EMVCo Specification Update: Bulletin no. 23: First edition October 2003: Corrections and Clarifications to EMV Card Personalisation Specification EMVCo Specification Update: Bulletin no. 40 First edition EMVCo Specification Update: Bulletin no. 40: First edition February 2005: Additional Corrections and Clarifications to EMV Card Personalisation Specification GlobalPlatform GlobalPlatform Technology, Card Specification V2.3.1 Card Specification GlobalPlatform Messaging Specification GlobalPlatform Systems Profiles Specification GlobalPlatform Secure Channel Protocol '03' [SCP03] GlobalPlatform Messaging Specification V1.0 GlobalPlatform Systems Profiles Specification

• V1.1 (available from the GlobalPlatform Secretariat) GlobalPlatform Technology, Secure Channel Protocol '03', Card Specification v2.3 – Amendment D, Version 1.2, Public Release, April 2020, Document Reference: GPC_SPE_014 Specification v2.0 / 114 1.8 Normative Industry Standards The following standards contain provisions that are referenced in this specification. The latest version including all published amendments shall apply unless a publication date is explicitly stated. Table 1-2 Industry Standards Reference ISO/IEC 7816-3 ISO/IEC 7816-4 ISO/IEC 7816-5 ISO/IEC 7816-6 ISO 9564-1 ISO/IEC 9797-1 ISO/IEC 10116 ISO/IEC 11770-6 ISO/IEC 18033-3 NIST 800-38B NIST 800-108 NIST FIPS 197 Publication Name 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, Interindustry 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, Interindustry data elements Banking – Personal Identification Number (PIN) – Part 1- Basic 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 – Key management — Part 6: Key derivation Information Technology – Security techniques – Encryption Algorithms – Part 3: Block Ciphers NIST Special Publication 800-38B – Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication NIST Special Publication 800-108 – Recommendation for Key Derivation Using Pseudorandom Functions NIST Federal Information Processing Standards Publication 197 – Announcing the Advanced Encryption Standard (AES) Specification v2.0 / 114 1.9

Definitions

The following terms are used in this specification: Table 1-3 Definitions Term Application Application Command Card Card Personalisation Data Preparation Personalisation Personalisation Command Personalisation Device Pre-personalisation Processing Step Definition An application resident in an EMV card. For this document specifically, an APDU command acceptable to an application after the application has been selected. An IC payment card as defined by a payment system. The personalisation of application data within a card, using personalisation commands. The process of preparing and formatting data, ready for sending to a personalisation device. The personalisation of application data to enable a card to be used by a cardholder. A command sent to a selected EMV application in order to personalise application data. A device that accepts data from a data preparation system and sends personalisation commands to a card. The initialisation of card data prior to personalisation. The action to be performed by the personalisation device.

1.10 Abbreviations The abbreviations listed in Table 1.4 are used in this specification. Additional abbreviations can be found at the end of this specification in section 7. Table 1-4 Abbreviations Abbreviation AES AID ANSI ASCII

Description

Advanced Encryption Standard Application Identifier American National Standards Institute American Standard Code for Information Interchange

Specification v2.0

/ 114 Abbreviation ATR BER BIN CBC CDA CLA C-MAC CMAC CPLC CPS CRN CRT CSN DDA DEK DES DF DGI ECB EF FCI FCP HSM IC ICC ICV Description Answer-to-Reset Basic Encoding Rules Bank Identification Number Cipher Block Chaining Combined DDA/Application Cryptogram Generation Authentication Class Byte Command Message Authentication Code, a service protecting the integrity of a command APDU by using MACs (Block) Cipher based Message Authentication Code Card Production Life Cycle Card Personalisation Specification Card and Application Management System (CAMS) Reference Number Chinese Remainder Theorem Chip Serial Number Dynamic Data Authentication Data Encryption Key Data Encryption Standard Dedicated File Data Grouping Identifier Electronic Code Book Elementary File File Control Information File Control Parameter Hardware Security Module Integrated Circuit Integrated Circuit Card Initial Chaining Vector

Specification v2.0

/ 114 Abbreviation ID IEC IIN INS ISO IV KDF KEK KMC LSB M/O MAC MIC MSB PAN PDI PEK PIN PK PRF PS RFU R-MAC RSA SDA SFI Description Identifier International Electrotechnical Commission Issuer Identification Number Instruction Byte International Organization for Standardization Initialisation Vector Key Derivation Function Key Encryption Key Master Key for Personalisation Session Keys (DES or AES) Least Significant Byte Mandatory or Optional Message Authentication Code, a value or a function generating such values, for example ANSI Retail MAC, CMAC Module Identifier Code Most Significant Byte Application Primary Account Number Personalisation Device Instructions PIN Encryption Key Personal Identification Number Public Key Pseudo Random Function Processing Step Reserved for Future Use (values to be ignored) Response Message Authentication Code, a service protecting the integrity of a response APDU by using MACs Rivest, Shamir and Adleman (Cryptographic Algorithm) Static Data Authentication Short File Identifier

Specification v2.0 Abbreviation SKU TK TLV var. Description Personalisation Session Key Transport Key Tag, Length, Value Variable

/ 114 1.11 GlobalPlatform Secure Channel Protocol Status The following table provides the Protocol Version Number status by GlobalPlatform Secure Channel Protocol Version Number underpinning the CPS. Table 1-5 Protocol Version Numbers Protocol Version Number SCP02 Legacy SCP03 Active Status

Specification v2.0 1.12 Supporting Documentation There is no further supporting documentation referenced.

/ 114 1.13 Terminology and Conventions The following words are used often in this specification and have a specific meaning: Shall or Must Defines a product or system capability which is mandatory. May Defines a product or system capability which is optional or a statement which is informative only and is out of scope for this specification. Should Defines a product or system capability which is recommended. 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 ∧ Logical AND. ∨ Logical OR.:= Assignment (of a value to a variable). () or [ ] Ordered set (of data elements). B1 B2 Concatenation of bytes B1 (the most significant byte) and B2 (the least significant byte). [B1 B2] Value of the concatenation of bytes B1 and B2. AES()[ ] The data in the square brackets is encrypted using AES encryption and the key in the normal brackets.

Specification v2.0

/ 114 AES-1()[ ] DES()[ ] DES-1()[ ] DES3()[ ] DES3-1()[ ] XOR The data in the square brackets is decrypted using AES decryption and the key in the normal brackets. 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. 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 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 ciphertext block Y to an 8-byte plaintext block X 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.

1.14 Constraints The Specification or any implementation of the Specification is not intended to replace or interfere with any international, regional, national or local laws and regulations; those governing requirements supersede any industry standards.

Specification v2.0

/ 114 2 Card Personalisation Data Processing 2.1 Overview of the Process Within a personalisation bureau environment the processing of Personalisation Device Instructions (PDI) and IC card personalisation data processing requires the following three functional steps: 1. Data preparation 2. Personalisation 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 Personalisation 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 personalisation. 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 personalisation 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 section 3. Data Preparation-Personalisation Device Interface The output of the data preparation process is a file of personalisation data, which is passed to the personalisation device. The format of the file records is shown in Table 3-8. The data preparation system must protect the completed personalisation data file for integrity and authenticity (e.g.by use of a MAC or signed hash). An example of implementation in XML format is provided in the GlobalPlatform Messaging Specification section 5.

Specification v2.0

/ 114 Personalisation Device The personalisation device is the terminal that acts on Processing Step and Personalisation Device Instruction data to control how personalisation data is selected and then sent to the IC card application. The Processing Step indicates the format of the personalisation data to be sent to the IC card application. Depending on the Processing Step for IC card personalisation processes this device must have access to a security module (HSM) to establish and operate a secure channel between the personalisation device on the one hand and the application on an IC card on the other. If the Processing Step indicates the precomputed APDU commands as personalisation data then the commands to establish the secure channel are part of the pre-computed APDU commands, in this case therefore the personalisation 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 re-encryption of secret data e.g. PIN values. Personalisation device processing is described in section 4. Personalisation Device-ICC Interface The personalisation device sends a series of personalisation commands to the ICC. The personalisation command flow is shown in Figure 6. The IC Card Application The IC card application receives the personalisation data from the personalisation device and stores it in its assigned location, for use when the EMV card application becomes operational. Section 5.1 describes the processing requirements for an EMV card application that must be performed prior to the start of personalisation. The actual processing of the EMV card prior to personalisation (pre-personalisation) is outside the scope of this specification. However, it is assumed that the EMV card application will have secure channel keys established for personalisation prior to the start of the personalisation process.

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

• Standard security between the personalisation device and the IC card. This is summarised in section 2.3.
• Standard commands for sending personalisation data to the IC card application. These are summarised in section 2.4.
• A standard record format for the personalisation data sent to the personalisation device. This is summarised in section 2.5. Specification v2.0 / 114 2.3 Secure Messaging At the beginning of processing by the personalisation device, a secure channel is established between the personalisation device and the IC card EMV application. Depending on the personalisation method (see section 3), the secure channel is established either by the personalisation 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 (see section 4.3.2) and the EXTERNAL AUTHENTICATE command (see section 4.3.3). These commands apply to both SCP02 and SCP03. When a secure channel is established (SCP02 or SCP03), authentication or privacy security services can be invoked to protect command data sent to the IC card application from the personalisation device according to the security level set in the EXTERNAL AUTHENTICATE command. The privacy service is referenced as C-DECRYPTION and the authentication service is referenced as C-MAC. Additionally, in SCP03 only, the EXTERNAL AUTHENTICATE command can invoke privacy and authentication security services on data returned from the card application, these services are referenced as R-ENCRYPTION and R-MAC respectively. Two derived keys, KENC and KMAC, on the IC card are used during the establishment of the secure channel. KENC is used for SCP03 to generate card challenges and for SCP02 to generate a session key SKUENC which is in turn used to create and validate authentication cryptograms. KMAC is used to generate a session key SKUMAC which is in turn used for SCP02 to generate card challenges, for SCP03 SKUMAC is used to create and validate authentication cryptograms, and for both SCP02 and SCP03 it is 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 personalisation device the IC card provides the personalisation device with the identifiers of the KMC and the diversification data to be used to create the derived keys. The identification of the KMC is described in section 4.1.1. The creation of derived keys is described in section 5.1. Once a secure channel is established, personalisation data can be sent to the IC card application. Based on the security level set in the EXTERNAL AUTHENTICATE command, the SKUENC may 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 personalisation device. For SCP03, if required by the security level, KMAC is used during the establishment of the secure channel to generate a session key SKURMAC which in turn is used to produce the Response Message Authentication Code (R-MAC) in card responses.

2.4 The STORE DATA Command The STORE DATA command is used to send personalisation data to the card application; it is described in detail in section 4.3.4.

Specification v2.0

/ 114 In order to reduce personalisation time, the data preparation process organises the personalisation data to be sent to an EMV card application by the personalisation 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 personalisation device. Much of the data for an application is organised 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 grouping. The principles of data grouping are described in section 3.2. In the Indirect Method the personalisation devices parse the input record and create a STORE DATA command for each data grouping or group of data groupings (see section 3.4.5) in the input record. Some data groupings will contain data that must be kept confidential during transmission from the personalisation device to the card application. The STORE DATA command has access to a data encryption service. In the Indirect Method, data encryption using an additional derived key (KDEK) available on the IC card is used. The IC card provides the personalisation device with the identifiers of the KMC and the diversification data to be used by the personalisation device to re-derive the IC card KDEK key value. The KDEK is derived from the same master key (KMC) as the KENC and KMAC as described in section 5.1. The KDEK is used either directly for encryption in SCP03 or in SCP02 to derive an encryption session key SKUDEK - see section 6.3 for the derivation mechanism. Encryption is performed as described in section 6.5. In the Direct Method the data grouping or group of data groupings are wrapped into the precomputed STORE DATA commands and the data groupings containing secret data have been encrypted under the IC card’s KDEK (SCP03) or SKUDEK (SCP02) by the data preparation system. It is possible to apply the KDEK encryption mechanism and additionally apply the secure messaging security services described in section 2.3.

2.5 The Common Personalisation Record Format The common personalisation approach requires a common personalisation record format. This record format is described in section 3.6. This format has been developed to support the personalisation of one or more applications on a single IC card. The overall card personalisation process normally consists of a series of processing modules that perform personalisation 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 personalisation process for non IC card application data is defined in documentation provided by the personaliser, however, the basic structure of the most commonly used personalisation record format allows all types of personalisation 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 personalisation data must be established between the data preparation processing system(s) and the personalisation device processing system(s). In Figure 1, which shows the organisation of personalisation data for the IC card module, MIC2 is used to represent the IC card personalisation data. MIC1 and MIC3 indicate non-ICC personalisation data.

Specification v2.0

/ 114 Figure 1 Overview of IC Card Personalisation Data Format The header portion of this record contains information that is common to all IC card applications to be personalised. Header information is described in Table 3-8. An overview of the format of the data for each application is shown in Figure 2. Figure 2 Overview of Personalisation 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 personalisation device The first part of the data for an IC card application is data that provides processing information to the personalisation 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 7.37), processing steps and if required the processing instructions for the personalisation device. The creation of personalisation device instructions is described in section 3.4. Specification v2.0 / 114
• 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 personalisation device is not aware of what data is contained in the data groupings. Therefore, data that must be logged must be sent to the personalisation 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 personalisation 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 3.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 the Indirect Method. See section 3.2 for additional information on the format and creation of this data. For Processing Step '0B' in the Direct Method this data consists of one or more pre-computed APDU commands pre-pended by an indicator of the APDU command case and the length of the APDU command. See section 4.2 for additional information on the format and creation of this data. Note that the information provided in section 3.2 applies to each individual data grouping within a pre-computed STORE DATA command. A complete description of the format for the personalisation data for an IC card application is given in section 3.6.

2.6 Cryptography This specification relies on cryptography to deliver authenticity and confidentiality security services.

2.6.1 SCP02 Authenticity and Confidentiality For SCP02 the delivery of these services is based on the use of the DES block cipher as composed to always use a double length key in a manner commonly known as triple DES (DES3). For authenticity services two different DES MAC constructions are used by this specification. The ANSI Retail MAC is used for C-MAC secure messaging purposes and the MACing of the personalisation data file exchanged between the Data Preparation function and the Personalisation Device in the Indirect Method for SCP02. The ANSI Retail MAC is also used to generate the card challenge. The full triple DES CBC MAC is used for the generation/validation of authentication cryptograms. Triple DES CBC mode of operation is used in session key derivation. For confidentiality services, both DES3 ECB and CBC modes of operation are used by this specification.

Specification v2.0

/ 114 2.6.2 SCP03 Authenticity and Confidentiality For SCP03 personalisation, the delivery of these security services is based on the use of the AES block cipher. Unlike [SCP03] this specification only allows the use of AES-128 and AES-256. Although AES-192 is not supported by this personalisation specification, this does not prevent the personalisation of AES-192 keys into EMV applications. It does mean that to maintain "weakest link" security at 192-bit strength that AES-256 must be used for the personalisation of these applications, not AES-128. For authenticity services the AES based CMAC construction is always used for MAC calculations [NIST 800-38B]. Additionally, the AES based CMAC construction is always used as the underlying Pseudo Random Function (PRF) for Key Derivation Function (KDF) processes [NIST 800-108] that generate authentication challenges/cryptograms or derive keys as required in SCP03. AES is used in CBC mode of operation to provide encryption services. [SCP03] (April 2020) introduces the use of 16-byte length challenges and 16-byte length MACs (denoted S16) into the secure channel set-up and processing, 8-byte challenges and 8-byte MAC lengths (denoted S8) are categorised as legacy. However, 8-byte lengths have not been deprecated and so do not need to be sunset. The choice of 8-byte or 16-byte lengths is left to the implementor. In any transition from SCP02 to SCP03, preserving 8-byte lengths reduces effort and provides ample security. In text where there is an SCP03 branch – 8-byte challenges/MACs vs 16-byte challenges/MACs - are flagged as S8 or S16 respectively.

Specification v2.0

/ 114 3 Data Preparation The data preparation process creates application data that is used to personalise the IC card application and depending on the Processing Step the Personalisation Device Instructions (PDI) data that are used to direct the personalisation process. Whatever is produced by the data preparation process must be transported securely to the personalisation device itself (unless it is created in an HSM attached to the personalisation device). Any secret data created by the data preparation process remotely from the personalisation device must therefore be encrypted before onward transmission and all data files generated remotely from the personalisation device must be protected by a Message Authentication Code (MAC) before onward transmission. For the Indirect Method where the personalisation device computes the APDU commands the data preparation process consists of the following five steps: 1. Creating personalisation data. 2. Combining personalisation data into data groupings. 3. Creating personalisation instructions. 4. Creating data to be logged for the application. 5. Creating the input file to the personalisation device. For the Direct Method where the data preparation system computes the APDU commands the data preparation process consists of the following five steps: 1. Creating personalisation data. 2. Combining personalisation 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 personalisation device.

3.1 Creating Personalisation Data The EMV CPS compliant application developer must determine what data is to be placed in the application at personalisation 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 3.1.1 Issuer Master Keys and Data EMV personalisation 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 personalisation data and secondly to create application-level data for personalisation of an EMV application. Some of the data may be used to manage the personalisation process and some will be placed on the card during personalisation.

Specification v2.0

/ 114 Other processes may also use one or more of the master keys used by the personalisation 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 personalisation process the following must be placed on the card:

• the identifier of the personalisation master key (KMCID);
• key version number;
• KEYDATA;
• the corresponding relevant keys. KMCID and key version number are used to access the issuer personalisation 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. Data Element KEYDATA Table 3-1 Data Content for tag 'CF' Description Key diversification data: - KMCID (6 bytes) - CSN (4 bytes)1 Length 10 Format Binary 3.1.2 EMV Application Keys and Certificates For EMV applications supporting SDA, DDA, or CDA an issuer RSA key pair must be generated and certified by the Payment System Certification Authority. For EMV applications supporting XDA an issuer ECC key pair must be generated and certified by the Payment System Certification Authority. Application level symmetric DES/AES 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 DDA or 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 application RSA key pair may be required for PIN decipherment. If XDA is supported in the card, then a card level EMV application ECC key pair must be generated and certified by the issuer. A second application ECC key pair may be required for ECC based Offline Data Encipherment. Even if the same ECC key is used for XDA and Offline Data Encipherment two certificates will be required. 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. 1 If the CSN does not ensure the uniqueness of KEYDATA across different batches of cards other unique data (e.g. 2 rightmost bytes of IC serial number and 2 bytes of IC batch identifier) should be used instead. Specification v2.0 / 114 3.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).

3.2 Creation of Data Groupings After the personalisation 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 personalisation 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 the minimum number of commands, 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 personalisation 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. AES keys must be placed in a data grouping consisting only of AES keys. More than one data grouping of AES 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. 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. 8. If an application contains information in its FCI (the response to the SELECT command) that is dependent on the personalisation data, one