GP GCP 1.0 030326

Guide to Common Personalization
Version 1.0 March 2003
03/26/2003
GlobalPlatform Guide to Common Personalization v1.0
ii
Table of Contents
1. Document Overview _______________________________________________________________ 1 1.1 1.2 1.3 1.4 1.5 2. Scope________________________________________________________________________ 1 Intended Audience_____________________________________________________________ 1 Document Structure ___________________________________________________________ 1 Normative References __________________________________________________________ 2 Abbreviations and Notations ____________________________________________________ 2
Overview of the Common Personalization Process _______________________________________ 6 2.1 The Infrastructure of Common Personalization_____________________________________ 6 2.2 Secure Messaging _____________________________________________________________ 7 2.3 The STORE DATA Command and Data Groupings ___________________________________ 7 2.4 The Data Container Format _____________________________________________________ 8 2.5 Common Personalization and CAMS ____________________________________________ 10 2.5.1 Data Preparation_________________________________________________________ 11 2.5.2 Personalization Device Processing ___________________________________________ 12 2.5.3 IC Card Application Processing _____________________________________________ 12 2.6 Process Overview_____________________________________________________________ 13
3.
Data Preparation ________________________________________________________________ 16 3.1 Creating Personalization Data __________________________________________________ 16 3.1.1 Application Provider Master Keys and Data____________________________________ 16 3.1.2 Application Keys and Certificates ____________________________________________ 16 3.1.3 Application Data _________________________________________________________ 17 3.2 Creation of Data Groupings ____________________________________________________ 17 3.3 DGIs Defined by Common Personalization _______________________________________ 18 3.3.1 Completion of Personalization ______________________________________________ 18 3.3.2 Restricting the STORE DATA Command after Personalization _______________________ 18 3.3.3 Replacing the initial Security Domain key(s) after Personalization __________________ 18 3.4 Multiple Transport Key Capability ______________________________________________ 20 3.5 Processing Step ______________________________________________________________ 21 3.6 Creation of Personalization Device Instructions (Processing Step 0F) ________________ 21 3.6.1 Order that Data must be sent to the Smart Card _________________________________ 22 3.6.2 Support for Migration to New Versions________________________________________ 22 3.6.3 Encrypted Data Groupings _________________________________________________ 23 3.6.4 PIN Block Format ________________________________________________________ 24 3.6.5 Random Number for Processing _____________________________________________ 24 3.6.6 Group of DGIs in one STORE DATA command ___________________________________ 24 3.6.7 The PDI Field ___________________________________________________________ 25 3.6.8 ICC Data populated with DGIs ______________________________________________ 26 3.7 Pre-computed APDU Commands (Processing Step 0B) ____________________________ 27 3.7.1 Types of pre-computed APDU Commands _____________________________________ 27 3.7.2 Coding of APDU Commands________________________________________________ 27 3.7.3 ICC Data populated with pre-computed APDUs_________________________________ 28 3.8 Creation of Personalization Log Data ____________________________________________ 29
4.
Personalization Device Processing __________________________________________________ 30 4.1 Processing Step with code action 0F ____________________________________________ 30 4.1.1 Key Management _________________________________________________________ 30 4.1.2 Processing Flow _________________________________________________________ 31 4.1.3 Return Data From Smart Card application_____________________________________ 39 4.2 Processing Step with code action 0B ____________________________________________ 40
Copyright 2003 GlobalPlatform Inc. All Rights Reserved. The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information is governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.
03/26/2003
iii
4.2.1 Syntax Checking _________________________________________________________ 40 4.2.2 Types of data elements in ICC Return data field _________________________________ 41 4.2.3 Coding of ICC Return Data Field ____________________________________________ 41 4.2.4 Abstraction from transport layer _____________________________________________ 42 4.3 Personalization Log Creation ___________________________________________________ 43 5. IC Card Processing_______________________________________________________________ 44 5.1 Preparation for Personalization _________________________________________________ 44 5.2 Personalization_______________________________________________________________ 44 5.2.1 Smart Card Requirements __________________________________________________ 44 5.2.2 Command Support ________________________________________________________ 44 5.2.3 Secure Messaging ________________________________________________________ 44 6. Cryptography for Personalization ___________________________________________________ 45 6.1 6.2 6.3 6.4 6.5 6.6 7. Key Zones___________________________________________________________________ 45 Session Keys _________________________________________________________________ 46 MACs ______________________________________________________________________ 46 Encryption __________________________________________________________________ 46 Decryption __________________________________________________________________ 46 DES Calculations_____________________________________________________________ 47
Data Dictionary__________________________________________________________________ 48 7.1 List of data elements __________________________________________________________ 48 7.1.1 ACT (Action to be Performed) _______________________________________________ 48 7.1.2 AID (Application Identifier)_________________________________________________ 48 7.1.3 CMK (Final Master Key)___________________________________________________ 48 7.1.4 CMODE (Chaining Mode) _________________________________________________ 48 7.1.5 DTHR (Date and Time) ____________________________________________________ 48 7.1.6 ENC (Encryption Personalization Instructions) _________________________________ 48 7.1.7 GROUP (Group of Data Grouping as part of Personalization Instructions) ___________ 49 7.1.8 IDTK (Identifier of the Transport Key) _________________________________________ 49 7.1.9 IDOWNER (Identifier of the Application Specification Owner)________________________ 49 7.1.10 IDTERM (Identifier of the Personalization Device) ________________________________ 49 7.1.11 ISSUERID (Issuer Identifier Data for Personalization) ___________________________ 49 7.1.12 KENC (DES Key for Creating Personalization Session Key for Secret Data Encryption) __ 49 7.1.13 KKEK (DES Key for Creating Personalization Session Key for DES Key Encryption)_____ 49 7.1.14 KMAC (DES Key for Creating Personalization Session Key for MACs) ________________ 50 7.1.15 KEYDATA (Derivation Data for Initial Update Keys) ____________________________ 50 7.1.16 KMC (DES Master Key for Personalization Session Keys)_________________________ 50 7.1.17 L (Length of Data) ________________________________________________________ 50 7.1.18 LOGDATA (Data Logging Personalization Instructions) __________________________ 50 7.1.19 MACINP (MAC of All Data for an Application) __________________________________ 50 7.1.20 MACkey (MAC Key) ______________________________________________________ 50 7.1.21 MIC (Module Identifier Code)_______________________________________________ 50 7.1.22 ORDER (Data Grouping Order Personalization Instructions) ______________________ 51 7.1.23 RCARD (Random Number from the Smart Card) __________________________________ 51 7.1.24 RTERM (Random Number from the Personalization Device)_________________________ 51 7.1.25 RANDOM (Random Number) _______________________________________________ 51 7.1.26 REQ (Required or Optional Action) __________________________________________ 51 7.1.27 SEQNO (Sequence Number) ________________________________________________ 51 7.1.28 SKUENC (Personalization Session Key for Encryption) ____________________________ 51 7.1.29 SKUDEK (Personalization Session Key for Secret Data Exchange) ___________________ 51 7.1.30 SKUMAC (Personalization Session Key for MACing) ______________________________ 52 7.1.31 TAG (Identifier of Data for a Processing Step) __________________________________ 52 7.1.32 TK (Transport Key) _______________________________________________________ 52
03/26/2003 7.1.33 7.1.34 8.
iv
TYPETK (Indicator of Use(s) of Transport Key)__________________________________ 52 VERCNTL (Version Control Personalization Instructions)_________________________ 53
Examples of document ____________________________________________________________ 54 8.1 Examples of Data Groupings ___________________________________________________ 54 8.1.1 CPS Demonstrator________________________________________________________ 54 8.2 Examples of Personalization Device Instructions ___________________________________ 56 8.2.1 CPS Demonstrator________________________________________________________ 56 8.3 Completion of Personalization __________________________________________________ 57 8.3.1 CPS Demonstrator________________________________________________________ 57
9.
Examples of APDU mapping to T=0 TPDU ___________________________________________ 58
03/26/2003
Table of Figures
Figure 2-1 Personalization Data by MIC......................................................................................................8 Figure 2-2 Overview of Smart Card Personalization Data Format...............................................................9 Figure 2-3 Overview of Personalization Data for a Single Smart Card Application ....................................9 Figure 2-4 CAMS Architecture Diagram ...................................................................................................11 Figure 2-5 Example Personalization Data Layout for one application .......................................................12 Figure 2-6 Example of Personalization Data for one Application for one Card.........................................13 Figure 2-7 Personalization Input File for One Card ...................................................................................13 Figure 2-8 Interface between the SCMS and the Loader............................................................................14 Figure 2-9 Interface between the SCMS and the Personalization device ...................................................15 Figure 3-1 Layout of ICC Data Portion of Record .....................................................................................26 Figure 3-2 Formatting of Personalization Data within ICC Data Portion of Record..................................26 Figure 3-3 Pre-computed APDU Command placed in BERTLV structure ..............................................27 Figure 3-4 Layout of ICC Data Portion of Record .....................................................................................28 Figure 3-5 Formatting of Personalization Data within ICC Data Portion of Record..................................29 Figure 4-1 Personalization Command Flow with Explicit Initiation SCP ..................................................32 Figure 4-2 Personalization Command Flow with Implicit Initiation SCP ..................................................33 Figure 6-1 Common Personalization Key Zones........................................................................................45 Figure 6-2 Common Personalization Key Zone in pre-computed APDU commands ................................45
03/26/2003
vi
Table of Tables
Table 1-1 Normative References ..................................................................................................................2 Table 1-2 Abbreviations ...............................................................................................................................3 Table 3-1 Data Content for DGI 7FFF.....................................................................................................18 Table 3-2 Example of Key Diversification Data for the Issuer Security Domain ......................................19 Table 3-3 Example of Key Diversification Data for a Supplementary Security Domain...........................19 Table 3-4 FORMATTK Codes and Associated Data ...................................................................................20 Table 3-5 Layout of TKDATA for FORMATTK 01.................................................................................21 Table 3-6 Data Content for the Field ORDER ...........................................................................................22 Table 3-7 Data Contents for the Field VERCNTL .....................................................................................23 Table 3-8 Data Contents for the Field ENC ...............................................................................................23 Table 3-9 Data Content for the Field GROUP ...........................................................................................25 Table 3-10 Personalization Device Instructions for Personalization Processing Step................................25 Table 4-1 Example of Key Diversification Data ........................................................................................35 Table 4-2 STORE DATA Command Coding for application personalization data........................................37 Table 4-3 Coding of P1 in STORE DATA Command ...................................................................................37 Table 4-4 Contents of ICC Return Data field .............................................................................................39 Table 4-5 Contents of Personalization Log ................................................................................................43 Table 7-1 Coding of TYPETK .....................................................................................................................53 Table 8-1 CPS Demonstrator Data Groupings ...........................................................................................54 Table 8-2 Data Content for DGI 0101 .....................................................................................................54 Table 8-3 Data Content for DGI 0102 .....................................................................................................55 Table 8-4 Data Content for DGI 0103 .....................................................................................................55 Table 8-5 Data Content for DGI 8101 .....................................................................................................55 Table 8-6 Data Content for DGI 9101 .....................................................................................................55 Table 8-7 Data Content for DGI 9102 .....................................................................................................55 Table 8-8 Data Content for DGI 1101 .....................................................................................................56 Table 8-9 Data Content for DGI 1102 .....................................................................................................56 Table 8-10 Data Content for the Field ORDER .........................................................................................56 Table 8-11 Data Content for the Field VERCNTL.....................................................................................56 Table 8-12 Contents of the Field ENC with PIN data ................................................................................57 Table 8-13 Data Content for the Field GROUP .........................................................................................57 Table 8-14 Data Content for DGI 7FFF...................................................................................................57 Table 9-1 Case 1 command ........................................................................................................................58 Table 9-2 Case 2 command with matching expected length ......................................................................58 Table 9-3 Case 2 command, greedy mode..................................................................................................58 Table 9-4 Case 2 command with too low expectations ..............................................................................59 Table 9-5 Case 3 command ........................................................................................................................59 Table 9-6 Case 4 command, greedy mode..................................................................................................59 Table 9-7 Case 4 command anticipating the correct response length.........................................................59 Table 9-8 Case 4 command with too low expectations ..............................................................................59
03/26/2003
1. Document Overview
1.1 Scope
The personalization process described in this document is designed to facilitate the personalization of multi-application cards. It creates a personalization infrastructure that allows upgrades to applications without requiring a change to the Personalization Device processing. This document is a Guide for a common approach to in-card personalization. This Guide supports up to the GlobalPlatform Card Specification 2.1. Personalizing an application through its Security Domain using the Install [for personalization] is not addressed. Off-card application personalization in which personalization data is included in an application load file, is not addressed. This document should be read in conjunction with the GlobalPlatform Load and Personalization Interface Specification.
1.2 Intended Audience

There are two intended audiences for this document: The designers of a specific application. 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 Data Preparation process for the application. Design of the structure for the application on the IC card. Design of the IC card commands used to personalize the application.
The designers of Personalization Device processing. This audience will use this document as a Guide for part of the design for their processing.
1.3 Document Structure

The document is organized as follows: Chapter 1 is this chapter and contains an overview of the document and a list of references. Chapter 2 provides an overview of the personalization process. Chapter 3 describes the Data Preparation process. Chapter 4 describes the Personalization Device processing. Chapter 5 describes specific requirements for IC card applications. Chapter 6 describes the cryptography used in the personalization process. Chapter 7 is the data dictionary. Chapter 8 provides examples of the use of the Common Personalization approach.
03/26/2003
1.4 Normative References

The following documents are referenced in this specification: Standard / Specification GlobalPlatform Card Specification 2.1, 2001 CAMS v3.0, 2000 ISO 9564-1, 1991 ISO/IEC 7816-3, 1997 Description Chip-card specifications for GlobalPlatform products Card and Application Management System Business Architecture Banking Personal Identification Number management and security Part1: PIN protection principles and techniques Identification Cards Integrated circuit(s) cards with contacts Part 3: Electronic signals and transmission protocols, Second Edition Identification Cards Integrated circuit(s) cards with contacts Part 4: Inter-industry commands for interchange, First Edition 1st September 1995; with Amendment 1 Information technology Open Systems Interconnection Specifications of Basic Encoding Rules for Abstract Syntax Notation One (ASN. 1) Description of the contents, format and usage of GlobalPlatform Profiles Overview of GlobalPlatform Personalization architecture and the role of scripts within it Defines how multi-application smart cards can be managed using GlobalPlatform Profiles and Scripts Describes Roles and responsibilities and interactions with other roles for a Smart Card Management System Describes a standard interface between a data preparation system and a personalization system Table 1-1 Normative References
ISO/IEC 7816-4, 1997
ISO/IEC 8825, 1990 GlobalPlatform Systems Profiles Specification, 1.0, 2002 GlobalPlatform Systems Scripting Specification, 1.0, 2002 GlobalPlatform Systems Card Customization Guide, 1.0, 2002 Implementation Primer for SCMS v1.0, 2000 GlobalPlatform Load and Personalization Interface, 1.0, 2003
1.5 Abbreviations and Notations

Table 1-2 contains the abbreviation used in this document. For an exhaustive list refer to section 7. Abbreviation APDU ATR BERTLV CA CAD CAMS CBC CDK Meaning Application Protocol Data Unit Answer-to-Reset Basic Encoding Rules Tag, Length, Value Certification Authority Card Acceptance Device Card and Application Management System (see section 1.4) Cipher Block Chaining Updated Derived Key
03/26/2003
GlobalPlatform Guide to Common Personalization v1.0 Meaning Updated Issuer Master Key Card Image Number CAMS Reference Number Card Serial Number Chinese Remainder Theorem Data Encryption Standard Triple DES (same as TDEA from FIPS Pub 46-3) Data Grouping Identifier File Control Information Integrated Circuit Integrated Circuit Card International Electro technical Commission Issuer Identification Number (ISO) International Organization for Standardization Issuer Initialization Vector Updated Derived Key Issuer Master Key Updated Issuer Master Key Least Significant Byte Mandatory or Optional Message Authentication Code Module Identifier Code Most Significant Byte Application Primary Account Number Processing Device Instructions Personal Identification Number Public Key Reserved for Future Use Rivest, Shamir and Adleman (Cryptographic Algorithm) Secure Hash Algorithm Tag, Length, Value Transport Protocol Data Unit Variable Table 1-2 Abbreviations
Abbreviation CMK CIN CRN CSN CRT DES DES3 DGI FCI IC ICC IEC IIN ISO ISS IV CDK KMC CMK LSB M/O MAC MIC MSB PAN PDI PIN PK RFU RSA SHA TLV TPDU Var.
Hexadecimal Notation Values expressed in hexadecimal form are enclosed in single quotes (e.g., _). For example, 27509 decimal is expressed in hexadecimal as 6B75.
03/26/2003
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. Operators and Functions

:= ( ) or [ ] B1 B2 [B1 B2] encrypt( )[ ] decrypt( )[ ] DES( )[ ] DES3( )[ ]
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 the key in the normal brackets. The data in the square brackets is decrypted using 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 encrypted using triple DES encryption and the key in the normal brackets. Triple DES consists of encrypting an 8-byte 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]]] X := DES3-1(K)[Y] := DES-1(KL)[DES(KR) [DES-1(KL)[Y]]] The encryption process is illustrated in the GlobalPlatform Load and Personalization Interface Specification.
sign( )[ ] verify( )[ ] SHA( )
The data in the square brackets is signed using the key in the normal brackets. The data in the square brackets is verified using the key in the normal brackets. The results of applying the SHA-1 hash algorithm to the data in the normal brackets.
Document Word Usage The following words are used often in this document and have specific meanings: Must: Defines a product or system capability that is required, compelled and mandatory. Should: Defines a product or system capability that is highly recommended.
03/26/2003
May: Defines a product or system capability that is optional.
03/26/2003
2. Overview of the Common Personalization Process

Personalization processing consists of three functional areas: 1. 2. 3. Data preparation Personalization Device processing IC card application processing.
Each of these areas is summarized in this section and discussed in detail in subsequent chapters. Data Preparation: Data preparation is the process that creates the data that is to be placed in an IC card application during personalization. Some of the data created may be the same across all cards, 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. Chapter 3 describes the Data Preparation processes that are common to all IC card applications using the Common Personalization approach. Personalization Device: The Personalization Device is the terminal that sends the personalization data to the IC card application. If the explicit Secure Channel Protocol is used, this device must have access to a security module to establish the secure session according to the Issuers security policy and to decrypt and re-encrypt secret data (For details on secure channel refer to the GlobalPlatform Card Specification 2.1). The processing of the Personalization Device when the Common Personalization approach is used is application independent. All of the processing is the same regardless of the application being personalized. Personalization Device processing is described in Chapter 4. The IC Card Application: The IC card application receives the personalization data from the Personalization Device and stores it for later use when the IC card application becomes operational. Section 5.1 describes the processing requirements for an IC card application that must be performed prior to the start of personalization. The actual processing of the IC card application prior to personalization will vary by application and must be defined in application specific documentation. All IC card applications will have Secure Messaging keys through the usage of their security domain services established for personalization prior to the start of the personalization process. Specific IC card application requirements dictated by the Common Personalization approach are described in section 5.2. The approach described in this document has been designed to work with various types of IC card platforms. However, this guide is specific to GlobalPlatform cards.
2.1 The Infrastructure of Common Personalization

The Common Personalization infrastructure consists of: Standard security between the Personalization Device and the IC card. This is summarized in section 2.2. Standard commands for sending personalization data to the IC card application. This is summarized in section 2.3. A standard record format for the personalization data sent to the Personalization Device. This is summarized in section 2.4.
03/26/2003
2.2 Secure Messaging

At the beginning of the personalization process, a Secure Channel is initiated between the Personalization Device and the IC card according to a Secure Channel Protocol. The Secure Channel may be initiated according to one of the two Secure Channel Protocols defined in the GlobalPlatform Card Specification 2.1. The Secure Channel Initiation is detailed in the GlobalPlatform Card Specification 2.1 Appendix D for the Secure Channel Protocol 1 (SCP01) and in Appendix E for the Secure Channel Protocol 2 (SCP02). Both implicit and explicit modes of secure channel initiation are supported in this document. Two derived keys on the IC card are used during the Secure Channel Initiation: KENC, used to generate SKUENC which is used to create and validate authentication cryptograms. KMAC, used to generate SKUMAC which is used to calculate MACs.
As an example both keys KENC and KMAC may be derived from the same master key, (KMC). Other key management schemes may be used to derive KENC and KMAC. The IC card provides the Personalization Device the identifiers of the keys and the derivation data used to create the derived keys. An example of master key identification using KMC is described in section 4.1.2.2. An example of initial key diversification data is shown in Table 4-1. Examples of updated key derivation data are shown in Table 3-2 and Table 3-3. Once the Secure Channel is established, personalization data can be sent to the IC card application. KENC and KMAC are used to generate session keys, to perform encryption, and MAC calculation.
2.3 The STORE DATA Command and Data Groupings

The STORE DATA command is used to send personalization data to the IC card. The STORE DATA command is described in section 4.1.2.5. The Data Preparation process organizes the personalization data to be sent to an IC 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. DGI coding rules are proposed in this document. Data groupings are described in section 3.2. The Personalization Devices parses the input record and creates a STORE DATA command for each data grouping in the input record. If a GROUP field within Processing Device Instructions is present, the STORE DATA command will contain all the DGIs listed in this GROUP field. The Personalization Device must encrypt secret data (each application defines which data is secret data for personalization purposes) in the data groupings using a key known to the IC card. The KDEK, described in section 5.1 may be used for this encryption. The IC card application design must specify which key is to be used. The STORE DATA command described in section 4.1.2.5 is used to complete the personalization process.
03/26/2003
2.4 The Data Container Format

The Common Personalization approach requires a Common Personalization record format. The Data Container format is described in the GlobalPlatform Load and Personalization Interface Specification. The Data Container is the section of the data stream that contains the set of personalization records for every card to be personalized. This container represents the actual MIC for ICC data that is provided by Card Issuers and Application Providers. A Data Container Header section precedes each Data Container Body, followed by the actual ICC data field itself. This format has been developed to support the personalization of multiple applications on a single IC card. Data to be placed in an IC card application is only one type of data that can be used by the personalization process. There may be multiple types of data required for the personalization process. For example, there is data to be embossed on cards, data to be encoded on the magnetic stripe and graphic data to be printed on the card. Many Personalization Devices support processing of all types of personalization data, not just IC card application personalization data. A Personalization Device frequently consists of a series of processing modules that perform personalization tasks. Each processing module uses data from the Data Container for a card to perform its task for that card. In the format defined in the GlobalPlatform Load and Personalization Interface Specification, 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 Personalization system provider, however, the basic structure of the Data Container format allows all types of personalization data to be included in the same file. At its most summarized level, the personalization Data Containers are arranged as shown in Figure 2-1
Figure 2-1 Personalization Data by MIC There will be a MIC that identifies data to be placed on an IC card. This data may be for multiple applications. 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 2-2, which shows the organization of personalization data for the IC card module, MIC2 is used to represent the IC card personalization data.
03/26/2003
Figure 2-2 Overview of Smart Card Personalization Data Format The header portion of this Data Container contains information that is common to all IC card applications to be personalized. The Data Container format is described in the GlobalPlatform Load and Personalization Interface Specification. An overview of the format of the data for each application is shown in Figure 2-3.
Figure 2-3 Overview of Personalization Data for a Single Smart Card Application
03/26/2003
10
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, the identifier of the Transport Key (TK) used to encrypt secret data in the record for the application (see section 3.4) and processing instructions for the Personalization Device. The creation of Personalization Device instructions is described in section 3.4. The second part of the data for an IC card application is the data to be logged for that application. As the Personalization Device uses identical processing for all applications, it cannot parse and then log application specific data for an application. The Data Preparation process for the application must perform this task and send the data to 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 sections 3.8 and 4.2 for additional information. The data to be sent to the IC card application is in the third part of the data for an IC card application. This data consists of one or more data groupings with a Data Grouping Identifier (DGI) and a length field. See section 3.2 for additional information on the format and creation of this data. A complete description of the format for the personalization data for an IC card application is given in the GlobalPlatform Load and Personalization Interface Specification. This document addresses Common Personalization, however, personalization is just one function that needs to be performed to prepare an IC card application for use. For example, the personalization process may need to be integrated into the functioning of a Smart Card Management System (SCMS). Additionally, the entity that personalizes the IC card application may also be responsible for loading and installing the IC card application on the IC card. The format of the Data Container defined in the GlobalPlatform Load and Personalization Interface Specification supports a full function SCMS. Examples of types of data that can be added are load data, installation data and initialization data. It allows dynamic loading and installation of applications. The GlobalPlatform Card Specification 2.1 gives an example of when these additional types of data would be used.
2.5 Common Personalization and CAMS

This section uses the Card and Application Management System (CAMS) architecture (see reference in section 1.4) to describe the responsibilities each role has when dealing with the Common Personalization process. While the Common Personalization approach does not require the use of scripts for the personalization process, the data preparation process can use GlobalPlatform Profiles and Scripting to drive the data preparation process. A simple and generic personalization script fragment can be used to drive the personalization process as well. Figure 2-4 is taken from CAMS has been modified to provide additional detail.
03/26/2003
11
Application Developer
Provide Application Code, Application Profile and Application Script Fragments Provide Application Code, Application Profile and Application Script Fragments
Specify Application Requirements, including Personalization Data Layout
Application Provider
Application Owner
Provide Application Load Files/Units and Keys, Personalization Data, CRN, Card Profile*, Application Profile, Application Script Fragments
Request Application Code, Application Profile and Application Script Fragments
Application Loader * Application Provider sends card Profile to Application Loader in post issuance only. In pre and instant issuance the Card Issuer sends the Card Profile
Figure 2-4 CAMS Architecture Diagram The following sections describe the individual steps that are performed by each of the roles when personalizing a single card with multiple applications. 2.5.1 Data Preparation The Application Owner specifies the Application Requirements and the Personalization Data Layout (see Figure 2-5) for each application. The Personalization Data Layout defines the Data Grouping Identifiers (DGIs). See section 3.2 for DGI rules and conventions. This information is sent to the Application Developer. The Application Developer creates the Application Code including the code to process the DGIs during personalization. If the Application Owner decides to use GlobalPlatform Profiles and Scripting for data preparation or personalization the following components also need to be developed The Application Profile. Application Profile Script Fragments.
The Application Profile describes all data (Data Elements) and Scripting Fragments that are needed to create the data to personalize the application on a target chip platform. The Application Script Fragments are included in the Application Profile and are used by the Data Preparation Process and the Personalization Device.
03/26/2003
12
The Application Developer sends the application code and may send the Application Profile that contains Scrip Fragments, to the Application Owner. The Application Owner sends these items to the Application Provider. The Application Provider creates Personalization Data (see Figure 2-6) and sends the Personalization Data to the Loader. The Application Provider typically uses a Data Preparation system to create a personalization file using the Data Preparation Scripts and the cardholder data. The Application Provider and the Card Issuer may also send to the Application Loader additional components needed by the Application Loader to complete the personalization preparation and personalization processes. The items that may be sent include the following: Application Load Files/Units and Keys CRN Card Profile Application Profile
2.5.2 Personalization Device Processing The Loader interprets the personalization input file (see Figure 2-7) as described in section 4 and sends commands to the IC card. 2.5.3 IC Card Application Processing The IC Card application receives each STORE DATA command and processes it.
DGI
0x0001 0x0002 0x0003
Description
PAN Name Key
Format
16 numeric 30 alphanumeric 8 binary
Figure 2-5 Example Personalization Data Layout for one application Figure 2-5 shows only a single data element in each DGI it is recommended that a DGI contain multiple data elements (i.e. be a record with format expanded to 16 bytes ASCII, 30 bytes ASCII and 8 bytes Hexadecimal in the example above). For each application, it is recommended that a document detailing the specific contents of each DGI as well as any ordering, grouping and encryption information is specified for the application. Section 8 presents an example of such a document.
03/26/2003
13
DGI
0x0001 0x0002 0x0003 16 30 8
Length
Value
1234 5678 1234 5678 Mr John Smith 0102030405060708
Figure 2-6 Example of Personalization Data for one Application for one Card Figure 2-6 shows a sample of the actual data as output by the data generation process for the example from Figure 2-5 above.
Key MIC (Module ID Code) Len (Length of following field)
MIC MIC MIC
Embossing Data
Optional Len
Magnetic Stripe Data Graphic Data Len IC Card Application Data
Len
MIC
Figure 2-7 Personalization Input File for One Card Once the ICC data has been generated it is normally included with the other data from the embossing file as shown in Figure 2-7 above. If the specific implementation of the Security Domain supports the STORE DATA command for updating data (including keys) on a GlobalPlatform card then the common personalization approach could be used to personalize the Security Domain. The type of documentation described in section 8 is required to provide detailed information on DGIs to be used to personalize the Security Domain.
2.6 Process Overview

A detailed description of the personalization preparation process is described in the Implementation Primer for SCMS, however, an example of the interaction between the Card Issuer and the Loader is shown in Figure 2-8 below. The initial interaction between the Card Issuer and Loader (Load & Personalization) system is out of scope in this document.
03/26/2003
14
TRANSACTION
Ca r d Issu er
Va lida t e Ca r d P r odu ct a ga in st Ca r d P r ofile a n d Applica t ion pr ofiles. Bu ild per son a liza t ion da t a a s per In t er fa ce spec. Colla t ion of per son a liza t ion da t a don e by t h e P er son a liza t ion bu r ea u , (opt ion a l) Da t a in clu des set of Applica t ion IDs, Issu er ID CRN a n d con t r ol SCMS. da t a . *P la ce or der wit h bu r ea u on a ppr opr ia t e ICCs Va lida t e or der , con fir m wit h Tr a n sa ct ion ID Loa der
P r epa r e set of AP DUs for per son a liza t ion device. Sen d P a cka ges t o device*
P er son a liza t ion r esu lt s a s per in t er fa ce spec, in clu din g er r or m essa ges. Da t a in clu des CRN a n d r equ est ed a u dit da t a in clu din g ca r d ser ia l n u m ber .
*
Not e, Ma y be it er a t ive or wor kflow
Figure 2-8 Interface between the SCMS and the Loader Figure 2-8 is specific to Load and Personalization Interface (see GP Load and Personalization Interface Specification). An alternative flow depicted in Figure 2-9 is normally associated with the communication to an instant issuance site. In other words, a request for card production is initiated from the personalization station.
03/26/2003
15
TRANSACTION
Ca r d Issu er Loa der
Requ est pr e det er m in ed Ca r d P r odu ct (P r ofile +Apps) wit h Ca r dh older or Ca r d Iden t ifica t ion Da t a , ID of Ca r d P r odu ct , a n d t r a n sa ct ion I.D. Va lida t e Requ est a n d Ret u r n CRN a n d Tr a n sa ct ion ID Requ est P er son a liza t ion da t a wit h CRN, Device ID & or der depen den cy. CSN field (m a y n ot be popu la t ed or pr e k n own ) + key ID a n d ver sion .
P er son a liza t ion Or der a s per In t er fa ce spec. Colla t ion of per so da t a don e by SCMS syst em or P er so Bu r ea u . Da t a in clu des set of Applica t ion IDs, Issu er ID, CRN CIN a n d con t r ol da t a . *
P r epa r e set of AP DUs for P er son a liza t ion device. Sen d P a cka ges t o device*
P er son a liza t ion r esu lt s a s per in t er fa ce spec, in clu din g er r or m essa ges. Da t a in clu des CRN a n d r equ est ed a u dit da t a .
* Not e, May be it er a t ive or wor k flow
Figure 2-9 Interface between the SCMS and the Personalization device
03/26/2003
16
3. Data Preparation
The Data Preparation process creates the data that is used to personalize an IC card application. Secret data created by the Data Preparation process must be encrypted for transport and all data sent to the Personalization Device should contain a Message Authentication Code (MAC). The Data Preparation process has five steps: 1. 2. 3. 4. 5. Creating personalization data. Combining personalization data into data groupings. Creating personalization instructions. Creating data to be logged for the application. Creating the input file to the Personalization Device.
3.1 Creating Personalization Data

The designer of the personalization process for an application 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 to be created as part of personalization preparation falls into three categories: 1. 2. 3. Application Provider Master Keys and Data. Application Keys and Certificates. Application Data.
The Application Provider may also be referred to as the Card Issuer if a single entity is responsible for all applications on the IC card. 3.1.1 Application Provider Master Keys and Data The personalization process usually requires that Issuer and Application Provider master keys and data be created. The master keys are used in the generation of security domain or application keys. Key separation between security domain and application keys is recommended. The enablement process may also use one or more of the master keys used by the personalization process. To allow sharing of master keys between processes, a method of importing or exporting master keys is required. If public key technology is used, then an Application Provider key pair may be generated and if necessary, certified by the Certification Authority for the application. 3.1.2 Application Keys and Certificates Application keys must be created. In most cases these are derived from the Application master keys.
03/26/2003
17
If public key technology is used, then an application key pair may be generated and certified by the Application Provider. If necessary, the Application Provider certificate corresponding to the Application Provider private key used to certify the application public key must also be stored in the application. 3.1.3 Application Data The application data may be common across all IC cards for an Application Provider (e.g. the identifier of the Application Provider) 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 personalization data for the IC card application has been created, it must be placed into the correct data grouping. The following requirements and guidelines should be used when creating data groupings: 1. 2. 3. 4. 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. All data elements to be sent to the IC card during the personalization process must be placed in a data grouping. There are benefits from grouping all fixed length data elements together, and placing all variable length data elements into another data grouping. The length of data in a data grouping must not exceed 237 bytes as the maximum length of an APDU command shall not exceed 254 bytes, including the header (5 bytes), the MAC (8bytes), the DGI (3 bytes) and the Le field (1 byte). 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 only for internal IC card application processing. 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. Data grouping identifier (DGI) 9F66 is reserved for sending personalization CPLC data to the IC card and must not be used as a DGI by an application other than a Security Domain. Data grouping identifiers (DGIs) 7FF0 through 7FFF are reserved for Common Personalization processing and must not be used as a DGI by an application other than a Security Domain. See section 3.3. Data grouping identifier (DGI) 00CF is reserved for Common Personalization processing and must not be used as a DGI by an application other than a Security Domain. See section 3.3.3.
5.
6.
7. 8.
9.
10. The number of data groupings should be minimized to improve performance during the personalization process. The DGI must be coded on 2 bytes in binary format followed by a length indicator coded on 1 byte in binary format.
03/26/2003
18
A recommendation for assigning DGIs for data stored in files is to use the most significant byte as SFI and the second byte as a record number. For data not stored in files a number greater than '31' may be used. Examples of data groupings are shown in section 8.1.
3.3 DGIs Defined by Common Personalization

DGIs to be used by all IC card applications using the Common Personalization approach have been defined to support the following functions: Completing the Personalization Process - Data to be sent to the IC card application with the last STORE DATA command. Disabling the STORE DATA Command - Data to restrict the use of the personalization commands (i.e. the STORE DATA command) after the personalization process is complete.
3.3.1 Completion of Personalization If specific data need 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). The contents of this DGI are shown in Table 3-1. The DGI 7FFF is not mandatory. Data Element DGI Length Description 7FFF Length of data Data to be included in the last STORE DATA command Table 3-1 Data Content for DGI 7FFF See section 8.3 for an example of DGI 7FFF. 3.3.2 Restricting the STORE DATA Command after Personalization Further protection can and should be applied by disabling the STORE DATA command after personalization. Length 2 1 Var.
3.3.3 Replacing the initial Security Domain key(s) after Personalization If the security domain keys were used for personalization it is good practice to replace the Initial Security Domain derived keys with keys known only to the Card Issuer (for Issuer Security Domain) or Application Provider (for supplementary Security Domains). These are known as the final Security Domain Derived keys.
03/26/2003
19
During initial personalization the Initial Issuer Master key (KMC) may be distributed between 3 entities (See CAMS): 1. 2. 3. The Issuer The Enabler The Loader
Replacing the KMC provided security, involves replacing three Security Domain key components: 1. 2. 3. The derived Security Domain key (s) for Secure Messaging The new key derivation data. The version number of the master key used to derive the Security Domain keys (if different from the version number of initial master key).
The new derived key(s) may be derived from the IC card serial number and the last two bytes of the Security Domain AID (see section 5.1). The Personalization Device retrieves this data from the KEYDATA field in the response to the INITIALIZE UPDATE command (see Table 4-1) in section 4.1.2.3. It is customary to replace both the derivation data and the keys, when replacing the KMC derived security. An example of the Key Diversification Data for the updated set of the Issuer Security Domain Keys is shown in Table 3-2.
Field Issuer Identification Number (IIN) Right most (low order) bytes of the Card Image Number (CIN)
Length 6 4
Table 3-2 Example of Key Diversification Data for the Issuer Security Domain An example of the Key Diversification Data for the updated set of a Supplementary Security Domain Keys is shown in Table 3-3. Field Application Provider Identification Number (AIN) Right most (low order) bytes of the Security Domain Image Number (SDIN) Length 6 4
Table 3-3 Example of Key Diversification Data for a Supplementary Security Domain
03/26/2003
20
3.4 Multiple Transport Key Capability

It is customary to encrypt secret data per application under unique Transport Keys during transfer from the Data Preparation system to the Personalization System. See Table 3-4 for an explanation of this process. The requirement for multiple TKs relates to encrypting PINs under a PEK (PIN Encryption Key) and encrypting 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).
LTK 0D
FORMATTK 00
Description of TKDATA (Only one Transport Key is used to encrypt all the secret data) The identifier of the Transport key (TK) used to encrypt secret data for the application. This field is composed of: 4 bytes: Issuer Identifier (IIN left justified and padded, if necessary, with 1111b (F Hex) per nibbles) 7 bytes: hex '00' 1 byte (binary): version identifier of the TK (Multiple Transport Keys are used) See Table 3-5
Variable
01
Table 3-4 FORMATTK Codes and Associated Data Field For entry #1 IDTK #1 Length 12 Description The identifier of a Transport key (TK) used to encrypt secret data for the application. This field has two parts, the first 4 bytes are the issuer id IIN left justified and padded, if necessary, with 1111b (F Hex) per nibbles), the last 8 bytes are the version identifier of the TK See Table 7-1 Algorithm associated with the TK to encrypt the secret data 10 CBC 11 ECB The number of DGIs in the following list.
TYPETK #1 CMODE for TK #1
1 1
Number of DGIs for TK #1 DGIs for TK #1
Var
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
03/26/2003 Field For entry #n IDTK #n
GlobalPlatform Guide to Common Personalization v1.0 Length 12 Description The identifier of a Transport key (TK) used to encrypt secret data for the application. This field has two parts, the first 4 bytes are the issuer id IIN left justified and padded, if necessary, with 1111b (F Hex) per nibbles), the last 8 bytes are the version identifier of the TK See Table 7-1 Algorithm associated with the TK to encrypt the secret data 10 CBC 11 ECB The number of DGIs in the following list.
21
TYPETK #n CMODE for TK #n
1 1
Number of DGIs for TK #n DGIs for TK #n
Var
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
Table 3-5 Layout of TKDATA for FORMATTK 01 MACKEY must always be the first entry, use CBC mode and a general purpose TK type.
3.5 Processing Step

The processing step describes what action is being performed by the personalization device. Processing Step is described in the GlobalPlatform Load and Personalization Interface Specification. If the action being performed is Common Personalization based on DGIs only within the ICC data field then the value of this step must be set to0F. If the action being performed is Common Personalization based on DGIs inside pre-computed APDUs within the ICC data field then the value of this field must be set to 0B.
3.6 Creation of Personalization Device Instructions (Processing Step 0F)

The Personalization Device instructions are special instructions that are created by the Application Provider 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 IC card. This section defines the Personalization Device Instructions when the Common Personalization approach is used along with DGIs only within the ICC data field. The Personalization Device Instructions defined in this section are not to be used with pre-computed APDUs within the ICC data field. The Examples of Personalization Device Instructions are shown in section 8.2. The Personalization Device Instructions for personalization must be placed in PDI field within the Processing Step.
03/26/2003
22
3.6.1 Order that Data must be sent to the Smart 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 IC card application in any order. However, there may be applications where the order of the data groupings is important for a correct personalization. To inform the Personalization Device of these situations, the ORDER field in the PDI field (see Table 3-10) must be created. The contents of the ORDER field are shown in Table 3-6. If a DGI is part of a grouped DGIs (See section 3.6.6) 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 IC application. 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. When a DGI is part of a 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. Data Element Order #1 Order of STORE DATA command for Order #1 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 nnth 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 nnth STORE DATA command FF must be placed in the last STORE DATA command Length of Order #n List of DGIs in Order #n Table 3-6 Data Content for the Field ORDER 3.6.2 Support for Migration to New Versions In general, the data for the IC card application should be defined in a manner that allows data added in newer versions of the specifications to be added at the end of existing records. Earlier versions of the application will ignore this new data, thus providing backwards compatibility. However, there may be times when adding a new data grouping is necessary. This may be accompanied by the need to remove an old data grouping. Length 1 1
Length Order of DGIs Order #n Order of STORE DATA command for Order #n
1 Var. 1 1
Length Order of DGIs
1 Var.
03/26/2003
23
The Data Preparation process may not need to not know the version of the application it is creating data for. It should always be able to create the data for the latest version of the application and be guaranteed backwards compatibility for the older versions. Old versions of the application will reject DGIs for new data groupings while new versions of the application may reject DGIs for old data groupings. To inform the Personalization Device of these situations, the VERCNTL field in the Smart Card Application Data (see Table 3-10) must be created. The contents of the VERCNTL field are shown in Table 3-7. Any response from the IC card other than a 9000 is considered a rejection of a data grouping. Data Element List of DGIs Description List of data grouping identifiers that may be rejected without error. Table 3-7 Data Contents for the Field VERCNTL 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. 3.6.3 Encrypted Data Groupings To inform the Personalization Device of data groupings that must be encrypted, the ENC field in the Smart Card Application Data (see Table 3-10) 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 3-8. Data Element DGI #1 Encryption type Description The identifier of the first data grouping to be encrypted 11 to be decrypted using TK if FORMATTK =00 in ECB mode and re-encrypted using SKUDEK (SCP02) or KKEK (for SCP01) in the algorithm implemented by the GP Card. 10 to be decrypted using TK if FORMATTK =00 in CBC mode and re-encrypted using SKUDEK (SCP02) or KKEK (for SCP01) in the algorithm implemented by the GP Card. 0A to be encrypted using SKUDEK (SCP02) or KKEK (for SCP01) in the algorithm implemented by the GP Card. The identifier of the nth data grouping to be encrypted 11 to be decrypted using TK if FORMATTK =00 in ECB mode and re-encrypted using SKUDEK (SCP02) or KKEK (for SCP01) in the algorithm implemented by the GP Card. 10 to be decrypted using TK if FORMATTK =00 in CBC mode and re-encrypted using SKUDEK (SCP02) or KKEK (for SCP01) in the algorithm implemented by the GP Card. 0A to be encrypted using SKUDEK (SCP02) or KKEK (for SCP01) in the algorithm implemented by the GP Card. Table 3-8 Data Contents for the Field ENC Length 2 1 Length Var.
DGI #n Encryption type 2 1
03/26/2003
24
3.6.4 PIN Block Format Format 1 PIN Block as defined in ISO 9564-1 referenced in section 1.4 should be used as the format to exchange the PIN block from a PIN Origination System or a Data Preparation System to a Personalization System. The security module that encrypts the PIN block must generate the Random Number to be used as the transaction digit. This Random Number is part of PIN block format 1 and is actually the diversifier of the PIN block. This encrypted PIN block of 8 bytes may be in a separate DGI. Table 8-7 provides an example. If the PIN block format stored within the smart card application is expected to be different from format 1, the smart card application must reformat the PIN block and store it in the required format. If format 1 for PIN block is used, the TYPETK in Table 3-5 should not be set to TK using RANDOM field and XOR operation (b7=1, b6=0) see Table 7-1. 3.6.5 Random Number for Processing In some cases the simple encryption of secret data is not sufficient for protecting the exchanged data. If the encrypted data is not sufficiently diverse (e.g. a PIN-block having only PIN-digits as variations), a Random Number can be used to XOR the secret data before encryption. If present, RANDOM should be 8 bytes minimum. To inform the Personalization Device that the Random Number is to be used for processing of this application, the RANDOM field in the Smart Card Application Data (see Table 3-10) must be used. This Random Number must be used if the TYPETK in Table 3-4 takes a value of [TK using RANDOM field and XOR operation] (b7=1, b6=0) as described in Table 7-1. 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. If ISO 9564-1 format 1 for PIN Block as described in section 3.6.4 is used to exchange the PIN block, the use of the random number method is unnecessary. The Random Number to use is contained in the RANDOM field as shown in Table 3-10. 3.6.6 Group of DGIs in one STORE DATA command In general, the personalization device sets a STORE DATA command for each DGI present in the ICC data filed within application personalization data file. To allow multiple DGIs in one STORE DATA command the GROUP field within the Processing Device Instructions should contain a list of DGIs to be included in one STORE DATA command. This feature can reduce processing time and allow for encrypted DGIs to be combined with non-encrypted DGIs in one STORE DATA command. DGIs within a group should be concatenated in the same order indicated in the GROUP field. The DGI entries must be concatenated together 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 DGI 0208 followed by DGI 0029 (including identifier, length and content of each DGI).
03/26/2003 Data Element Group #1 Length List and order of DGIs for Group #1 Group #n Length List and order of DGIs for Group #n
GlobalPlatform Guide to Common Personalization v1.0 Description 01 Length of Group #1 List of DGIs in Group #1 Length 1 1 Var.
25
nn Length of Order #n List of DGIs in Group #n Table 3-9 Data Content for the Field GROUP
1 1 Var.
3.6.7 The PDI Field Personalization Device Instructions (PDI) field is part of Processing Step field (See GlobalPlatform Load and Personalization Interface Specification). The format and contents of the PDI field are shown in Table 3-10. Field LORDER ORDER LVERCNTL VERCNTL LENC ENC LRANDOM RANDOM LGROUP GROUP Length Length of ORDER if no order is required for data groupings, this field must be 0000 See section 3.6.1 for a description of this field Length of VERCNTL if there is no version control required, this field must be 0000 See section 3.6.2 for a description of this field Length of ENC if there is no data is to be encrypted, this field must be 0000 See section 3.6.3 for a description of this field Length of RANDOM if there is no Random Number this field must be 0000 See section 3.6.5 for a description of this field Length of GROUP if there is no grouped DGIs this field must be 0000 See section 3.6.6 for a description of this field Description 2 Var. 2 Var. 2 Var. 2 Var. 2 Var.
Table 3-10 Personalization Device Instructions for Personalization Processing Step
03/26/2003
26
3.6.8 ICC Data populated with DGIs The Data Container format is defined in the GlobalPlatform Load and Personalization Interface Specification. 3.6.8.1 The ICC Data Field The data in the ICC Data field includes tags and length-bytes to allow a combination of personalization data and data for other processing steps. The format is shown in Figure 3-1.
Tag of step #1 data Length of step #1 data Tag of step #2 data Value of step #1 data Length of step #2 data Tag of step #n data Value of step #2 data Length of step #n data
Value of step #n data
Figure 3-1 Layout of ICC Data Portion of Record If personalization is step #2 of the processing steps, Figure 3-2 shows how the value portion for step #2 is expanded into the data layout for personalization data. If this portion contains DGIs, then it will be identified by tag EF.
DGI of data group #1 data
Length of data group #1 data
Value of data group #1 data
DGI of data group #2 data
Length of data group #2 data
Value of data group #2 data
DGI of data group #n data
Length of data group #n data
Value of data group #n data
Figure 3-2 Formatting of Personalization Data within ICC Data Portion of Record If the data to be sent to the IC card is to be encrypted based on the ENC field (see section 3.6.3), only the value portion of the data grouping is encrypted. The DGI and the length field are not encrypted.
03/26/2003
27
3.7 Pre-computed APDU Commands (Processing Step 0B)

If Common Personalization is used with pre-computed APDU Commands, there are no explicit Personalization Device Instructions and therefore the PDI field is empty. Parsing information and APDU case (see ISO/IEC 7816-3) related instructions are incorporated in the TAG of the TLVs within the ICC data field. A data preparation system should create the APDU Commands using the rules defined in this section as shown in Figure 3-3. The data preparation system includes an APDU command as the value of a BERTLV structure. The length of the TLV follows BER. The length of a tag itself is one byte.
Tag of APDU Command
Length of APDU Command BER coded
Pre-computed APDU Command
Figure 3-3 Pre-computed APDU Command placed in BERTLV structure 3.7.1 Types of pre-computed APDU Commands The following three types of APDU commands are supported: Push command: card command not requiring inclusion of the card command or corresponding response in the ICC Return data field. Pull command: card command requiring inclusion of the corresponding card response in the ICC return data field. Dialogue command: card command requiring inclusion of both the card command itself and the corresponding card response in the ICC Return data field.
Each of three commands can have an error bypass flag. A command with an error bypass flag will not result in abortion of the APDU processing if it gives rise to a card processing error. 3.7.2 Coding of APDU Commands The different types of APDU commands are coded as concatenations of TLV elements. The tags used for the different commands and the error bypass flag are coded in a single byte and have all primitive encoding. The tag values are the following: 86: push command. C1: pull command. C7: dialogue command. C9: error bypass flag.
03/26/2003
28
3.7.2.1 Coding of commands If the command in the value field is present and shorter than 4 bytes or longer than 261 bytes, this implies a syntax error. If the value field of a command is not present, the personalization device should interpret this as a request to perform a card reset. In some cases, card-reader specific protocols may impose upper limits on the length of commands. If the command cannot be sent due to this reason, a length limit error shall be generated. 3.7.2.2 Coding of error bypass flag C9 The value field of the error bypass flag is a single byte equal to 01. If the value is different, a Command syntax error should be generated. A command has an error bypass flag if the error bypass flag TLV element precedes the command TLV element. An error bypass flag that is not followed by a command shall be treated as a command syntax error. 3.7.3 ICC Data populated with pre-computed APDUs The Data Container format is defined in the GlobalPlatform Load and Personalization Interface Specification.
3.7.3.1 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-4.
Figure 3-4 Layout of ICC Data Portion of Record
03/26/2003
29
If personalization is step #2 of the processing steps, Figure 3-5 shows how the value portion for step #2 is expanded into the data layout for personalization data. If this portion contains DGIs, then it will be identified by tag EE.
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
Tag of Command APDU #1
Length of Command APDU #1
Command APDU #1
Tag of Command APDU #2
Length of Command APDU #2
Command APDU #2
Tag of Command APDU #n
Length of Command APDU #n
Command APDU #n
Figure 3-5 Formatting of Personalization Data within ICC Data Portion of Record
3.8 Creation of Personalization Log Data

Application providers and smart card management systems need data from the personalization process to be logged. However, the Personalization Device is not aware of what data within the ICC data is required to be logged. Therefore, any data to be logged in addition to what the device logs by default must be sent to the Personalization Device in a manner that indicates that this is log data. To inform the Personalization Device of application data that must be logged, the LOGDATA field in the Data Container (see GlobalPlatform Load and Personalization Interface Specification) must be created. The data contained in this field is the actual data to be logged. It is not a list of DGIs or pre-computed APDU commands and merely duplicates data in the ICC data field for logging purposes. In certain cases the LOGDATA may include all of the personalization data for the application. In this case, the contents of ICC data filed (see GlobalPlatform Load and Personalization Interface Specification) 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 would be the PAN.
03/26/2003
30
4. Personalization Device Processing

The Personalization Device processing is greatly simplified by the Common Personalization approach. This section describes what need to be done by the personalization device base on the Processing Step action code. Therefore this section is divided in two subsections:

Processing Step with code action 0F Processing Step With code action 0B
4.1 Processing Step with code action 0F

This subsection describes the process to be performed by the personalization device when the ICC data field contains DGIs only. The process is as follows: The Personalization Device activates the IC card (RESET). The IC card responds (Answer To Reset (ATR)). The AID of the application to personalize is retrieved from the input data. The application to be personalized is selected. A Secure Channel is initiated according to the protocol defined in the GlobalPlatform Card Specification 2.1 Appendix D for the Secure Channel Protocol 1 (SCP01) and in Appendix E for the Secure Channel Protocol 2 (SCP02). The application is personalized using one or more STORE DATA commands. Personalization is completed via a last STORE DATA command with a specific parameter.
The successful last STORE DATA command concludes the personalization process for the application. If there are more applications to be personalized, then the next AID is retrieved from the input data and the process described above is repeated. 4.1.1 Key Management The Personalization Device must share the Transport key (TK) with the Data Preparation process. Personalization device processing must be able to identify the Transport key (TK) in the Personalization Device key storage by the TK identifier(s) that will be in the file from the Data Preparation system. The Transport key (TK) used to encrypt data between the Data Preparation system and the Personalization Device is not related to the keys KKEK and SKUKEK used to encrypt secret data between personalization device and IC Card application. The Personalization Device and the entity that loads the KENC, the KMAC, and the KDEK to the IC card prior to personalization share the master key used to create the KENC, the KMAC, and the KDEK. The Personalization Device processing must be able to identify the master key in the Personalization Device key storage.
03/26/2003
31
4.1.2 Processing Flow The Personalization Device must read a data record for each IC card to be personalized and reset the IC card. For each IC card application to be personalized, the Transport key (TK) identified in the input record (IDTK) must be retrieved from the key storage. If the Issuer Id is the information that allows the Personalization Systems to retrieve the Issuer Master Key then a GET DATA command for Tag 42 should be used to retrieve the Issuer Id.
Data grouping 7FFF, if present, should be retrieved from the input record and, must be used as the data to be sent to the IC card application with the last STORE DATA command. The ORDER field within PDI may override this rule. The AID of each application to be personalized must be retrieved from the data record for the IC card (see GlobalPlatform Load and Personalization Interface Specification). A series of STORE DATA commands are sent to the IC card application, followed by a last STORE DATA command. Figure 4-1 summarizes the flow of commands and responses that must occur between the Personalization Device and the IC card using a Secure Channel Protocol with explicit initiation mode. Issuer Security Domain is usually the default selected application after a RESET command. If it is not the case or the application to be personalized is under the control of a Supplementary Security Domain then a SELECT command should be sent to that Security Domain before using GET DATA command to retrieve Tag 42. If a Supplementary Security Domain is to be used to establish the secure channel then this Supplementary Security Domain needs to include tag '42'. The content of this tag could be used to identify the master key of the Application Provider. This master key is used to derive the Supplementary Security Domain static keys. It is recommended that the first time reader review the commands in the order that they appear in the command flow.
03/26/2003

Personalization Device Reset ATR Select Security Domain FCI Get Data tag 42 Tag 42 data Select application FCI Initialize Update Key information and card challenge External Authenticate
32
Card
Commands repeated for each application to be personalized Command repeated for each block of data to be inserted into card
OK Store Data OK Last Store Data OK
Figure 4-1 Personalization Command Flow with Explicit Initiation SCP An alternative to the flow shown in Figure 4-1 is to use a Secure Channel Protocol with implicit initiation mode. Figure 4-2 depicts this flow. Issuer Security Domain is usually the default selected application after a RESET command. If it is not the case or the application to be personalized is under the control of a Supplementary Security Domain then a SELECT command should be send to that Security Domain before using the GET DATA to retrieve Tag 42. If a Supplementary Security Domain is to be used to establish the secure channel then this Supplementary Security Domain needs to include tag '42'. The content of this tag could be used to identify the master key of the Application Provider. This master key is used to derive the Supplementary Security Domain static keys. If the entity that computes the APDUs (Data preparation system or Personalization System) is not aware of Key Diversification Data and the Sequence Counter, it uses two GET DATA commands followed by the first STORE DATA command with a mandatory C-MAC (to authenticate the sender). The first GET DATA command is used to retrieve the Key Information Template of the initial key of the Security Domain (tag 'E0'). The second GET DATA command is used to retrieve the Sequence Counter of the initial key of the Security Domain (tag 'C1 for GlobalPlatform compliant cards).
03/26/2003

Personalization Device Reset ATR Select Security Domain FCI Get Data tag 42 Tag 42 data Get Data Commands used only if the information is not known Key information Template Get Data Sequence Counter Select application FCI
33
Card
Commands repeated for each application to be personalized
Command repeated for each block of data to be inserted into card
Store Data OK Last Store Data OK
Figure 4-2 Personalization Command Flow with Implicit Initiation SCP The commands in this section have been placed in alphabetic order for ease of reference.
4.1.2.1 EXTERNAL AUTHENTICATE Command The EXTERNAL AUTHENTICATE DATA command is detailed in the GlobalPlatform Card Specification 2.1 Appendix D for the Secure Channel Protocol 1 (SCP01) and in Appendix E for the Secure Channel Protocol 2 (SCP02). These SCPs use explicit initiation mode. Error conditions are detailed in the GlobalPlatform Card Specification 2.1. Additional proprietary error conditions may be defined by the Application Provider.
03/26/2003
34
4.1.2.2 GET DATA Command The GET DATA command is used to retrieve data objects from the card, including the Card Recognition Data.
4.1.2.2.1 Card Recognition Data
The GlobalPlatform Card Specification 2.1 Appendix F, describes a scheme that allows an Personalization Device to discover how to work with an IC card of unknown characteristics without having to resort to trial and error. The Card Recognition Data is available at any time, and through it the Personalization Device may learn how to work with the card. There are two aspects to this: The Security Domain related to the application to be personalized should be selected. A GET DATA command can be issued that will provide details of the card and how to access it, primarily for card management purposes.
Issuing the GET DATA command for tag 66 provides Card Data, which is TLV (tag-length-value) encoded as described in ISO/IEC standard 7816-6. This in return contains a constructed data object, Card Recognition Data, with tag 73. Card Recognition Data is unambiguously identified because it contains an object identifier that GlobalPlatform has assigned for this purpose. The method for accessing Card Recognition Data is as follows: 1. Use the SELECT command (select by name) with no command data and with the first or only occurrence option set. This selects the Card Management function on the card. Ignore any response status other than 61xx or 6Cxx. Issue a GET DATA command as defined in ISO/IEC standard 7816-4 for a data object with tag 66 (Card Data), and within that access Card Recognition Data (tag 73) which contains the various card recognition data objects. (Note that this command only returns the value field of Card Data, not its tag or length.) Check that the Card Recognition Data object contains the GlobalPlatform Card Recognition Data object identifier. If this fails, then trial-and-error is necessary, as the card does not support Card Recognition Data.
2.
3. 4.
If the application is using the services of other Security Domain than the Issuer Security Domain (Card Manager for OP Card 2.01), then the same commands should be sent to the related Security Domain. In this case, the SELECT command should contain the AID of that Security Domain.
4.1.2.2.2 Issuer Identifier (ISSUERID)
When using KMC, Issuer Identifier (ISSUERID) is required to identify the KMC for this IC card. The Issuer OID may be retrieved from the Card Scheme Id data element of the Card Recognition Data (tag '63'). When the Card Scheme Id is set to {globalplatform 3} OID, the Issuer Identifier (IIN) is present in tag '42'.
03/26/2003
35
The Issuer Identifier (ISSUERID) may also have been be provided by the Card Issuer and inserted into the card prior to the personalization process. In this case, to retrieve this Issuer Identifier, the FIELD P1P2 of the command message must be coded with the value '0042'. 4.1.2.3 INITIALIZE UPDATE Command The INITIALIZE UPDATE command is the first command issued to the IC card after the Personalization Device selects the application. The INITIALIZE UPDATE command is used to establish the Secure Channel Protocol in explicit initiation mode to be used during personalization. The INITIALIZE UPDATE command is issued once for each IC card application to be personalized. The INITIALIZE UPDATE command must be coded according to the GlobalPlatform Card Specification 2.1. When SCP01 is used the data field of the response message is according to the GlobalPlatform Card Specification 2.1 Appendix D. When SCP02 is used the data field of the response message is according to the GlobalPlatform Card Specification 2.1 Appendix E. An example of the Key Diversification Data returned in the response to the INITIALIZE UPDATE command with the initial set of Security Domain Keys is shown in Table 4-1 Field Last 2 bytes of the Security Domain AID IC Fabrication date IC Serial Number IC Batch Identifier Length 2 2 4 2
Table 4-1 Example of Key Diversification Data As an example, using the responses from the GET DATA and INITIALIZE UPDATE commands to identify the master key for Secure Messaging (KMC), the Personalization Device uses the KMC and KEYDATA to generate the KENC, the KDEK and the KMAC1 for this IC card as defined in section 5.1. These keys must then have been placed in the IC card prior to the start of the personalization process. Subsequent processing must use the algorithm for Secure Channel Protocol in the response to the INITIALIZE UPDATE command to determine how to create MACs and when to create session keys. This information could also be retrieved from the card from the Card Recognition Data through GET DATA command prior to INITIALIZE UPDATE command. MACs are created as described in the GlobalPlatform Card Specification 2.1. The session keys must be calculated during processing of the INITIALIZE UPDATE response using data from the Personalization Device and the IC card. The session keys must be calculated as described in the GlobalPlatform Card Specification 2.1.
The keys being derived may be the CDKKEK, CDKMAC and CDKENC, if the initial keys have been replaced. See section 3.3.3
03/26/2003
36
The Personalization Device must verify the card cryptogram in the response to the INITIALIZE UPDATE command by generating a duplicate cryptogram and comparing it to the value returned in the response. The card cryptogram is a MAC created as described in the GlobalPlatform Card Specification 2.1. If the card cryptogram does not verify correctly, personalization processing must be terminated and a log of the process written. 4.1.2.4 SELECT Command The SELECT command is used to select each IC card application to be personalized. Application selection is described in the GlobalPlatform Card Specification 2.1. The SELECT FILE command will be issued once for each IC card application to be personalized. If an application is accessible through its Security Domain, then the related Security Domain may be selected. 4.1.2.5 STORE DATA Command The STORE DATA command is used to personalize the IC card applications. There will be one STORE DATA command for each data grouping in the record from the Data Preparation process. If GROUP field within Processing Device Instructions is populated (see section 3.6.6) then some STORE DATA commands will contain a group of DGIs accordingly. The STORE DATA command requires a Secure Channel to be established. The security level of the STORE DATA command is the security level of EXTERNAL AUTHENTICATE command. The security level of the EXTERNAL AUTHENTICATE command P1 = 00 does not require MAC for STORE DATA command in explicit initiation mode and requires C-MAC on the first STORE DATA command in implicit initiation mode. The DGIs and data groupings used by the STORE DATA command are dependent on the data in the input record. Field ENC in the input record lists the identifiers of data groupings that must be encrypted. Keys, sensitive data such as PIN should not be available in plain text at any time during the personalization process. The STORE DATA command used to personalize the IC card applications must be coded as shown in Table 4-2.
03/26/2003
37
Field CLA INS P1 P2 Lc DGI Length Data
Content 80 or 84 E2 See Table 4-3 Sequence Number Length of command data Identifier of data to be inserted Length of data to be inserted (1-237) Data to be inserted C-MAC (conditional, depends on the Security Level defined at the initiation of the Secure Channel Session, i.e. Authenticated only or Authenticated and C-MAC)
Length 1 1 1 1 1 2 1 Var.
Table 4-2 STORE DATA Command Coding for application personalization data
The ICC Application invokes its Security Domain services to verify the secure messaging of the command. If secure messaging is present and successfully verified by the Security Domain, the class byte of the command is changed from 84 to '80' and the C-MAC is stripped off and Lc byte recomputed accordingly when the APDU is returned to the ICC application (see GlobalPlatform Card Specification 2.1).
b8 x 1 0
b7
b6
b5-b1
Meaning Last data grouping indicator Last data grouping Not the last data grouping
x 1 0 0 1
x 1 0 1 0 xxxxx
Encryption indicators All DGIs encrypted under KEK No DGI is encrypted One or more DGIs (but not all) are encrypted RFU RFU
Table 4-3 Coding of P1 in STORE DATA Command
03/26/2003
38
If the FORMATTK field in the input record is set to 00 and a DGI is listed in the ENC field in the input record, the TK identified in the input record must be used to decrypt the data within the DGI (created and encrypted by the Data Preparation process). In the same process, the data within the DGI (after being decrypted), it must be re-encrypted under session key SKUDEK (SCP02) or KKEK (for SCP01) prior to sending it to the IC card. Encryption of data must be done in the algorithm implemented by the GP Card. Only the data portion of the data grouping is encrypted. The DGI and length field are not encrypted. If the FORMATTK field in the input record is set to 00 and the encryption type for the DGI listed in field ENC is 10, decryption of data by the Personalization Device must be done in CBC mode. Triple DES is used to decrypt each block. If the FORMATTK field in the input record is set to 00 and the encryption type for the DGI listed in field ENC is 11, decryption of data by the Personalization Device must be done in ECB mode. Triple DES is used to decrypt each block. If the FORMATTK field in the input record is set to 01 and a DGI is listed in the DGIs for TK field (as shown in Table 3-5) in the input record, the TK identified in the input record must be used to decrypt the data created by the Data Preparation process. If the same DGI is listed in the ENC field in the input record, after the input data is decrypted, it must be re-encrypted under session key SKUDEK (SCP02) or KKEK (for SCP01) prior to sending it to the IC card. Encryption of data must be done in the algorithm implemented by the GP Card. Only the data portion of the data grouping is encrypted. The DGI and length field are not encrypted. If the FORMATTK field in the input record is set to 01 and the CMODE field (as shown in Table 3-5) is set to 10, decryption of data by the Personalization Device must be done in CBC mode. Triple DES is used to decrypt each block. If the FORMATTK field in the input record is set to 01 and the CMODE field (as shown in Table 3-5) is set to 11, decryption of data by the Personalization Device must be done in ECB mode. Triple DES is used to decrypt each block. Several DGIs may be sent to the card within the data field of the STORE DATA command. If all DGIs included in one STORE DATA command are encrypted, the Personalization Device must set b7 of P1 to 1, and b6 of P1 to 1. The IC card must use session key SKUDEK (if SCP02) or KKEK (if SCP01) to decrypt the data in the algorithm implemented by the GP Card. To indicate that some DGIs are encrypted, the Personalization Device must set b5 of P1 to 1 and b6 of P1 to 0, and b7 of P1 to 0. If a DGI shall always be encrypted when sent to the card, it is the responsibility of the on-card application to ensure that the DGI is received with the appropriate parameter P1 in the STORE DATA command. The Personalization Device must set P2 to 00 for the first STORE DATA command sent to the IC card application. The Personalization Device must then increment the value of P2 by 1 for each subsequent STORE DATA command. If the security level in the EXTERNAL AUTHENTICATE command specified MACing, the C-MAC must be calculated by the Personalization Device and verified by the IC card. The padding is not sent to the IC card. Proprietary error conditions may be used in addition to the error conditions defined in the GlobalPlatform Card Specification 2.1. It should be noted by the Application Developers that if the security Level in the EXTERNAL AUTHENTICATE command requires at least a MAC, and a MAC is not presented or MAC verification fails, the error condition '6982' must be returned by the card.
03/26/2003
39
If the Issuer Security Domain or Supplementary Security domain related to the IC Application being personalized is in the SECURED state, it is recommended that the IC application requires at least MAC verification. In this case if a MAC is not presented or MAC verification fails, the error condition '6982' must be returned by the card. If the IC card application does not recognize the DGI in the STORE DATA command, it must respond with an SW1 SW2 of 9301. If the SW1 SW2 that is returned by the IC card is 9301, the input data record for the IC card application must be checked for field VERCNTL. If the Data Grouping Identifier (DGI) that was rejected by the IC card is listed in field VERCNTL, normal processing must continue and the C-MAC must be saved to be used as the initialization vector (IV) for the next C-MAC. If the data grouping DGI is not listed in field VERCNTL, personalization processing of the IC card application must be ended. The IC card must be rejected and an error log entry written. 4.1.2.6 Using the STORE DATA Command as the last Personalization Command The personalization device must set b8 of P1 to 1 for the Last STORE DATA command. A STORE DATA command with b8 of P1 set to 1 must be treated by the IC card application as the end of personalization. If a DGI of 7FFF is present in input file, the personalization device should keep the DGI 7FFF until all other DGIs are sent to the IC Card Application, then a Last STORE DATA command with a DGI of 7FFF should be sent to the IC Card Application. This rule may be overridden by the field ORDER or field GROUP within the Processing Device Instructions PDI. After processing the last STORE DATA command, the application should take the necessary step to make transition of its Life Cycle State. 4.1.3 Return Data From Smart Card application During the personalization process data may be generated by the Smart Card application such as RSA Key pair generation. Part of this data should be provided to the Application Provider. The field ICC Return Data (See Smart Card Return Data Table in GlobalPlatform Load and Personalization Interface Specification 1.0) must be used to carry the return data to the Application Provider. The Personalization device must fill the ICC Return Data field every time the APDU Response Data contains data, according to the Table 4-4. Data Element DGI #1 Length Return Data DGI #n Length Return Data The identifier of the nth data grouping that triggered the Response Data The length of the data returned by the ICC application in BER Data returned by the ICC application Table 4-4 Contents of ICC Return Data field 2 Var Var Description The identifier of the first data grouping that triggered the Response Data The length of the data returned by the ICC application in BER Data returned by the ICC application Length 2 Var Var
03/26/2003
40
4.2 Processing Step with code action 0B

This subsection describes the process to be performed by the personalization device when the ICC data field contains pre-computed APDU Commands. During processing, the personalization device keeps track of the number of commands sent to the card in the command counter. The personalization device performs the following processing: 1. 2. 3. The Personalization Device activates the IC card (RESET). It sets the command counter to 0. It processes the commands. If the personalization device detects an invalid implicit instruction within a TLV element (see section 3.7) or a command with invalid syntax (see 3.7.2.1) it goes to step 4 (see section 4.2.1 for more information on syntax checking). It sends the commands to the card in the order in which they appear. For each command: (a) (b) It increments the command counter. It sends the command to the card. (At this point, the Terminal Transport Layer may return a message that the command syntax is not valid. If so, the personalization device goes to step 4). Only for a dialogue command: it appends the dialogue command to the ICC Return data field. If the personalization device detects that the card is removed or if the card does not respond within a certain time period (time out), it goes to step 4. If the card returns SW that indicate a card processing error (value different from 9000, 61xx, 62xx or 63xx, where x can be any value) and the command does not have an error bypass flag, it appends the card response (even for a push command) to the ICC Return data field and goes to step 4. Only for a pull command or dialogue command: it appends the card response the ICC Return data field.
(c) (d) (e)
(f) 4.
The personalization device appends the termination reason and the command counter to the ICC Return data field.
4.2.1 Syntax Checking The personalization device may check the syntax of the complete sequence of pre-computed APDU commands before sending commands to the card. If it detects a script syntax error or a command syntax error, it may generate an ICC Return data field without sending any command to the card. This ICC Return data field will indicate a command syntax error as termination reason and a command counter equal to 0. However, a personalization device may also parse the commands just before sending them to the card. In that case, a number of commands may have been sent to the card before the syntax error is detected. This is reflected by the value of the command counter in the ICC Return data field.
03/26/2003
41
4.2.2 Types of data elements in ICC Return data field The types of data elements that can occur in ICC Return data field are: Dialogue command: copied from the ICC data field. Card Response: card response to a command in the ICC data field. Termination reason: indicates whether personalization was completed successfully and if not, the reason for incomplete personalization (see section 4.2.3.1). Command counter: indicates the total number of commands that the personalization device has sent to the card for the current personalization process.
An ICC Return data field will be a sequence of card response and dialogue command data elements, whereby each dialogue command must be followed by a card response. At the end of the ICC Return data Field there is a mandatory termination reason and command counter. The simplest ICC Return Data Field will only contain these two data elements. 4.2.3 Coding of ICC Return Data Field The data elements in the ICC Return data Field are coded by the following tags: C3: card response. C4: termination reason. C5: command counter. C7: dialogue command.
4.2.3.1 Coding of termination reason The termination reason, coded in tag C4 can have one of the following values: 00: success: commands sent to the card successfully. 01: syntax error: personalization process aborted due to a syntax error in setting TLV elements within ICC data field. 02: length limit error: personalization process aborted due to an exceeded command length (see Section 3.7.2.1) 03: command syntax error: the card command has an invalid syntax. 04: card processing error: personalization process aborted due to a card processing error. 05: card response time-out: personalization process has been aborted due to a time-out on the card response. 06: card removed: personalization process has been aborted due to removal of a card
03/26/2003
42
4.2.3.2 Coding of the command counter The command counter is BER-TLV encoded with tag C5 and number is binary. The value 0 is encoded as a single 00 byte. Some examples follow (tag in bold, length underlined): Value 010: C5 01 00 Value 2510: C5 01 19 Value 12810: C5 02 00 80 Value 35110: C5 02 01 5F
4.2.4 Abstraction from transport layer For communication with a smart card several transport protocols exist. At this level, communication with a card is done by the exchange of TPDU messages as defined in ISO/IEC 7816-3. If the GP cards support the T=0 protocol. The value of the TLV data elements in the ICC data field consists of the commands to be sent to the card, at the APDU level (see ISO/IEC 7816-4). We consider the mapping between the APDU level and the TPDU level common knowledge and to be taken care of by the driver at the communication layer. At the T=0 level, the card may return error codes starting with 61 or 6C. These are interpreted by the T=0 driver with which the personalization device communicates. The T=0 driver should perform the correct processing as indicated by these error codes. Such examples are provided in section 9.
03/26/2003
43
4.3 Personalization Log Creation

At the end of the personalization process for an IC card application, a log of the personalization process for that IC card application must be created. At the end of the entire process an audit file containing the logs of the personalization processes for all IC card applications must be created. The format of the data in the log for each IC card is shown in Table 4-5. Field SEQNO DTHR IDTERM LISSUERID LCRN LAID AID Content Sequence number of card personalized Date and time of personalization YYMMDDHHSS Identifier of the Personalization Device Length of ISSUERID ISSUERID Length of CRN CRN IC Serial Number (from KEYDATA returned by application #1) Length of the AID of the 1st application AID of the 1st application personalized Version Number of the master update key (KMC) returned in response to INITIALIZE UPDATE for 1st application The status condition returned from the last step of the personalization process for the 1st application. Length of the field LOGDATA for the 1st application Data from Data Preparation to be logged for the 1st application Length of the AID for the nth application AID of the nth application personalized Version Number of the master update key (KMC) returned in response to INITIALIZE UPDATE for nth application The status condition returned from the last step of the personalization process for the nth application. Length of the field LOGDATA for the nth application Data from Data Preparation to be logged for the nth application Table 4-5 Contents of Personalization Log Length 3 5 4 1 Var. 1 Var. 4 1 5-16 1 2 2 Var. 1 5-16 1 2 2 Var.
SW1 SW2 LOGDATA LAID AID
SW1 SW2 LOGDATA
03/26/2003
44
5. IC Card Processing
IC card personalization processing consists of two separate processes, a preparation for personalization process and an actual personalization process.
5.1 Preparation for Personalization

Prior to personalization, certain data must be placed onto the IC card. In some cases this data applies to the entire card (e.g. ISSUERID). In some cases, this data only applies to a single application (e.g. the AID). Each application must be selectable by its AID or being accessible through its security domain. The version number of the personalization master key (KMC) used to generate the initial personalization keys (KENC, the KKEK and the KMAC) for each application must be on the IC card. This field must be updateable (see section 3.3.3). Key Diversification Data must be set as shown in Table 4-1. This field must be updateable (see section 3.3.3).
5.2 Personalization
5.2.1 Smart Card Requirements Technical requirements for the IC to be personalized must follow the specifications for the various layers of the application: 5.2.2 Command Support Each IC card that supports the Common Personalization approach should support the commands described in section 4.1.2 according to Figure 4-1 for SCP01 and SCP02 in explicit mode and according to Figure 4-2 for SCP02 in implicit mode. 5.2.3 Secure Messaging Secure messaging should be required by all applications for the following personalization commands: EXTERNAL AUTHENTICATE (see GlobalPlatform Card Specification) STORE DATA (see section 4.1.2.5)
For a complete description of Secure Messaging, refer to the GlobalPlatform Card Specification.
03/26/2003
45
6. Cryptography for Personalization

6.1 Key Zones
If the Secure Channel Protocol is to be used in explicit mode, two key zones exist in the Common Personalization process. There is a key zone between the Data Preparation processes and the Personalization Device. There is also a key zone between the Personalization Device and the IC card. These two key zones are shown in Figure 6-1. Figure 6-1 Common Personalization Key Zones
Data Prep
Perso Device
IC Card
One or more Transport Keys (TK) to encrypt secure data grouping
Derived personalization keys by application derived from a master personalization key (KMC) shared by the card supplier and the personalizer
If the pre-computed APDU commands are used, one key zone may exist between the Data Preparation System and the IC card. This key zone is shown in Figure 6-2.
Data Prep
IC Card
Derived Personalization keys by application, derived from a Master Personalization Key (KMC) known by the Data Preparation
Figure 6-2 Common Personalization Key Zone in pre-computed APDU commands
03/26/2003
46
6.2 Session Keys

DES Session Keys are generated every time a Secure Channel is initiated. These Session Keys may be used for subsequent commands if Secure Messaging is required. Up to three Session keys may be generated, namely SKUENC, SKUMAC, and SKUDEK. The derivation process for creating session keys in Process 2 is described in the GlobalPlatform Card Specification 2.1. Appendix D and Appendix E.
6.3 MACs
All data sent from the Data Preparation process to the Personalization system should be MACed to ensure the integrity of the personalization data file. The process of creating MACs is described in the GlobalPlatform Load and Personalization Interface Specification. Depending on the level of security required during the Secure Channel initiation, the personalization process may also create MACs. Some commands sent from the Personalization Device to the IC card require Secure Messaging MACs. These MACs ensure the integrity of the personalization data and because each MAC incorporates the MAC from the previous command as an initialization vector, they also ensure that all the personalization data is sent to the IC card. During the personalization process, the Personalization Device sends the host cryptogram to the IC card and the IC card returns the card cryptogram. The IC card and the Personalization Device authenticate each other using these cryptograms. Depending on the level of security defined in the Secure Channel Initiation, Secure messaging (MAC) may be required for the STORE DATA personalization commands. The MAC calculation shall follow the rules defined in the GlobalPlatform Card Specification 2.1. Commands using Secure Messaging must include an 8 byte MAC created by the Personalization Device and verified by the IC card prior to accepting the command.
6.4 Encryption
After personalization, confidential or secret data may be exchanged between a terminal and an IC card application. For example, a PIN may be changed between a terminal and an IC card during an online transaction. This section does not apply to encryption of secret data after personalization. Post personalization encryption is covered in application specific documents. The methods for encrypting secret data during personalization are described in the GlobalPlatform Load and Personalization Interface Specification
6.5 Decryption
If the explicit mode of the Secure Channel Protocol is used, the Personalization Device must decrypt secret data encrypted by the Data Preparation process. This secret data will then be re-encrypted under session key SKUDEK (SCP02) or KKEK (for SCP01) prior to sending the data to the IC card. The methods for decrypting secret data during personalization are described in the GlobalPlatform Load and Personalization Interface Specification
03/26/2003
47
6.6 DES Calculations

Triple DES (DES3) is used for all symmetric key cryptographic operations. The triple DES method used for encryption is described in the GlobalPlatform Load and Personalization Interface Specification.
03/26/2003
48
7. Data Dictionary
7.1 List of data elements
The data elements are presented in alphabetical sequence of abbreviated name. 7.1.1 ACT (Action to be Performed) Purpose: Format: Content: Identifier for the action to be performed in a processing step. 1 byte binary A value of 0F is used for the Common Personalization Step. A value of 0B is used for the Common Personalization Step if the pre-computed APDU commands are used. See the appropriate platform reference for other values.
7.1.2 AID (Application Identifier) Reference: Purpose: Format: Content: ISO 7816-5 Identifier for the application. Used during Application Selection as prescribed in the GlobalPlatform Card Specification 2.1 5-16 bytes RID || PIX where the RID is the five-byte global registered identifier as specified in, ISO/IEC 78165 and the PIX (011 bytes) is at the discretion of the owner of the RID.
7.1.3 CMK (Final Master Key) Purpose: Format: Note: This DES key is used for generating derived keys to generate MACs and encrypt and decrypt DES keys and secret data during personalization (CDKENC, CDKDEK and CDKMAC). Binary, 16 bytes Must be generated with odd parity.
7.1.4 CMODE (Chaining Mode) Purpose: Format: Content: Identifies the chaining mode to use to decrypt the related DGI 1 byte, binary 10 CBC mode. 11 ECB mode.
7.1.5 DTHR (Date and Time) Purpose: Format: The date and time in YYMMDDHHSS format BCD, 5 bytes.
7.1.6 ENC (Encryption Personalization Instructions) Purpose: Format: Specifies the data groupings which must be encrypted. See section 3.6.3 Binary, variable.
03/26/2003
49
7.1.7 GROUP (Group of Data Grouping as part of Personalization Instructions) Purpose: Format: Specifies a group of DGIs to be sent to the IC card Application in one STORE DATA command. See section 3.6.6. Binary, Variable
7.1.8 IDTK (Identifier of the Transport Key) Purpose: Format: Content: Identifier of the key used to encrypt secret data sent from the Data Preparation process to the Personalization Device. Binary, 12 bytes See GlobalPlatform Load and Personalization Interface Specification
7.1.9 IDOWNER (Identifier of the Application Specification Owner) Purpose: Format: Content: Identifies the owner of the specifications for this application. Binary, variable It is recommended that the RID of the owner of the specifications for the application be used in the coding of this field.
7.1.10 IDTERM (Identifier of the Personalization Device) Purpose: Format: Identifies the device used to personalize an IC card. Binary, 4 bytes.
7.1.11 ISSUERID (Issuer Identifier Data for Personalization) Purpose: Data required by the Personalization Device for identification of the Card Issuer. This field is used to determine which KMC is to use to derive the keys for Secure Messaging. This data must be placed in the IC card prior to personalization, and must be retrievable by the GET DATA command prior to the explicit selection of an application. This field will normally contain the Card Issuer BIN. However, if the Personalization Device is at a personalization bureau that uses an identifier for Card Issuers other than a BIN, that identifier may be used in this field. If a Card Issuer has multiple card suppliers and uses different KMCs for each card supplier, this field may contain an identifier of the card supplier as well as the identifier of the Card Issuer. Variable, 1-10 bytes
Format:
7.1.12 KENC (DES Key for Creating Personalization Session Key for Secret Data Encryption) Purpose: Format: Notes: This DES key is created prior to the start of the personalization process and is used by the personalization process to create the session key SKUENC. Binary, 16 bytes Must be generated with odd parity.
7.1.13 KKEK (DES Key for Creating Personalization Session Key for DES Key Encryption) Purpose: Format: Notes: This DES key is created prior to the start of the personalization process and is used by the personalization process to create the session key SKUDEK. Binary, 16 bytes Must be generated with odd parity.
03/26/2003
50
7.1.14 KMAC (DES Key for Creating Personalization Session Key for MACs) Purpose: Format: Notes: This DES key is created prior to the start of the personalization process and is used by the personalization process to create the session key SKUMAC. Binary, 16 bytes Must be generated with odd parity.
7.1.15 KEYDATA (Derivation Data for Initial Update Keys) Purpose: Format: Contents: The data used to derive the KDEK, KMAC and the KENC from the KMC. Binary, 10 bytes See Table 4-1
7.1.16 KMC (DES Master Key for Personalization Session Keys) Purpose: Format: Notes: This DES key is used for generating derived keys to generate MACs and encrypt and decrypt DES keys and secret data during personalization (KENC, KDEK and KMAC). Binary, 16 bytes Must be generated with odd parity.
7.1.17 L (Length of Data) Purpose: Format: Remarks: The length of data that follows. Binary, variable Length and content depend upon usage
7.1.18 LOGDATA (Data Logging Personalization Instructions) Purpose: Format: Specifies the data which must be logged by the personalization process. See section 3.8. Binary, Variable.
7.1.19 MACINP (MAC of All Data for an Application) Purpose: Format: A MAC created over all of the data for an IC card application. MACINP is the 4 leftmost bytes of the created MAC. Binary, 4 bytes
7.1.20 MACkey (MAC Key) Purpose: Format: The DES key used to create MACINP. This key should be uniquely created for the data for each application on each IC card. Binary, 8 or 16 bytes
7.1.21 MIC (Module Identifier Code) Purpose: Format: An identifier that specifies that this is data for IC card application(s). The length and values of this field are established when the Personalization Device is configured. ASCII, Variable, 1 to 7 bytes
03/26/2003
51
7.1.22 ORDER (Data Grouping Order Personalization Instructions) Purpose: Format: Specifies the order in which data groupings which must be sent to the IC card. See section 3.6.1. Binary, Variable.
7.1.23 RCARD (Random Number from the Smart Card) Purpose: Format: A Random Number generated by the IC card or the IC card application. Used in the creation of the host and card cryptograms. Binary, 6 bytes (if ALGSCP = 02) or 8 bytes (if ALGSCP = 01)
7.1.24 RTERM (Random Number from the Personalization Device) Purpose: Format: A Random Number generated by the Personalization Device. Used in the creation of the host and card cryptograms. Binary, 8 bytes
7.1.25 RANDOM (Random Number) Purpose: Format: Content: Used during encryption and decryption of secret data encrypted with a TK Binary, Variable 8 bytes recommended A Random Number to be used during personalization processing
7.1.26 REQ (Required or Optional Action) Purpose: Indicates whether the action to be performed in a processing step is required or optional. If a processing step is required, it must be done, even if it has been done before. If a processing step is optional, it must not be re-done if it has been done before. 1 byte binary 00 is optional, 01 is required
Format: Content:
7.1.27 SEQNO (Sequence Number) Purpose: Format: The sequence number of a personalized IC card in a run of IC cards personalized. The first card has sequence number 1, the second, number 2, etc. Binary, 3 bytes
7.1.28 SKUENC (Personalization Session Key for Encryption) Purpose: Format: Content: Remarks: This DES key is created during the personalization process and is used to create cryptograms and may be used to encrypt and decrypt secret data in CBC mode. Binary, 16 bytes Derived as described in section 6.2. Must be generated with odd parity
7.1.29 SKUDEK (Personalization Session Key for Secret Data Exchange) Purpose: Format: Content: This DES key is created during the personalization process and is used to encrypt and decrypt secret data in ECB mode. Binary, 16 bytes Derived as described in section 6.2.
03/26/2003 Remarks:
GlobalPlatform Guide to Common Personalization v1.0 Must be generated with odd parity
52
7.1.30 SKUMAC (Personalization Session Key for MACing) Purpose: Format: Content: Remarks: This DES key is created during the personalization process and is used when secure MACing is required to create C-MACs. Binary, 16 bytes Derived as described in section 6.2. Must be generated with odd parity
7.1.31 TAG (Identifier of Data for a Processing Step) Purpose: Format: Content: Identifier for the data in ICC Data in the input record to be used in a processing step. Binary, Variable A BER TLV encoded tag. A value of EF is used for the personalization step. See the appropriate platform reference for other values.
7.1.32 TK (Transport Key) Purpose: Format: Remarks: A DES key used to encrypt Keys, PINs or other secret data between the Data Preparation system and the Personalization Device. Binary, 16 bytes This key is not related to the KKEK and the SKUKEK used to encrypt secret data sent to an IC card.
7.1.33 TYPETK (Indicator of Use(s) of Transport Key) Purpose: Format: Content: Identifies the uses of a Transport Key Binary, 1 byte Provides information on what the TK encrypts and the encryption algorithm used. See Table 7-1. If a TK is a general purpose TK with an Encryption algorithm (b7 and b6) = 01b, then the TK encrypts secret data as described in section 6.4. If a TK is indicated by an Encryption method (b7 and b6) of 10b, then the secret data is XORed with the RANDOM number for this application before encryption (by the Data Preparation system) and after decryption (by the personalization system) as described in section 3.6.5.
b8 x 0 1
b7
b6
b5
b4
b3
b2
b1
Meaning TK for MACkey encryption TK not used for MACkey encryption TK used for MACkey encryption
x 0 1 0 1
x 1 0 0 1 x x x x x
Encryption algorithm General purpose TK TK using RANDOM field and XOR operation RFU for Common Personalization RFU for Common Personalization RFU for Common Personalization RFU for Proprietary Implementations
03/26/2003
GlobalPlatform Guide to Common Personalization v1.0 Table 7-1 Coding of TYPETK
53
7.1.34 VERCNTL (Version Control Personalization Instructions) Purpose: Format: Specifies the data groupings which may be rejected by the IC card without error. See section 3.6.2. Binary, Variable.
03/26/2003
54
8. Examples of document
These examples reflect the CPS Demonstrator Application. CPS Demonstrator is a Java Card Applet that has been developed as a sample of implementation for Common Personalization Specification. The source and CAP file as well as sample of personalization data are available to public. This sample does not cover all possibilities offered by the Common Personalization Specification. However, it could be used as a reference for studying a concrete sample CPS Compliant Applet and personalization data stream. This sample could be used for testing a personalization system as a use case.
8.1 Examples of Data Groupings

8.1.1 CPS Demonstrator Table 8-1 lists the data groupings developed for a CPS Demonstrator application. DGI 0101 0102 0103 8101 9101 9102 1101 1102 Data Content CPS Demonstrator Issuer Data see Table 8-2 CPS Demonstrator Card Holder Identity Data see Table 8-3 CPS Demonstrator Card Holder Address Data see Table 8-4 CPS Demonstrator Card Holder Secret Data see Table 8-5 Authentication Key to sign output Data (AKSCPS) see Table 8-6 FCI Data see Table 8-6 PIN Block see Table 8-7 PIN Related Data see Table 8-9 Length 9 64 68 40 16 Var. 8 2 Encryption Key Used2 N/A N/A N/A SKUDEK or KKEK SKUDEK or KKEK N/A SKUDEK or KKEK N/A
Table 8-1 CPS Demonstrator Data Groupings Data Element ISID CARDEXP Description Issuer Identifier Card Expiration Date DDMMYYYY Table 8-2 Data Content for DGI 0101 Length 5 4
N/A in this column means that the data is clear text data and not encrypted.
03/26/2003
GlobalPlatform Guide to Common Personalization v1.0 Data Element Description Card Holder First Name Card Holder Middle Name Card Holder Last Name Card Holder Date of Birth DDMMYYYY Table 8-3 Data Content for DGI 0102 Data Element Description Card Holder Street Address Card Holder City Card Holder ZIP Address Card Holder Country Address Card Holder Phone Number Table 8-4 Data Content for DGI 0103 Length 20 20 10 3 15 Length 20 20 20 4
55
FNAME MNAME LNAME DOB
STREETADD CITYADD ZIPADD COUNTRY PHONE
Data Element SSNCH CITYOB COUNTRYOB
Description Card Holder Social Security Number Card Holder City Of Birth Card Holder Country Of Birth
Length 17 20 3
Table 8-5 Data Content for DGI 8101 Data Element AKSCPS Description Authentication Key to Sign Length 16
Table 8-6 Data Content for DGI 9101 Data Element 6F 84 A5 50 87 5F2D 9F11 9F12 BF0C C9 DF10 5F28 C0 9F08 Description Indicates FCI template DF Name (AID) FCI Proprietary template Application Label Application Priority Indicator Language Preference Issuer Code Table Index Application Preferred Name Issuer Discretionary Data Application Profile (APCPS) Application Data Locator (ADL) Country code (CNTRY) Domain (DOM) (00 if not used) Application Version Number (AVN) Length Var. 5-16 Var. 1-16 1 2-8 1 1-16 Var. 2 Var. 3 1 2
Table 8-7 Data Content for DGI 9102
03/26/2003 Data Element PIN Block
GlobalPlatform Guide to Common Personalization v1.0 Description Reference PIN Block Table 8-8 Data Content for DGI 1101 Length 8
56
Data Element PINcount PINlimit
Description Number of PIN tries remaining Maximum number of consecutive unsuccessful PIN tries Table 8-9 Data Content for DGI 1102
Length 1 1
8.2 Examples of Personalization Device Instructions

8.2.1 CPS Demonstrator Table 8-10 through Table 8-14 list the Personalization Device Instructions developed for the CPS Demonstrator application. 8.2.1.1 Support for Data Grouping Order Data Element Order #1 Order of STORE DATA command for Order Length Order of DGIs Order #2 Order of STORE DATA command for Order Length Order of DGIs Description 01 00 Length 1 1
Length of Order#1 04 01020103 02 00
1 4 1 1
Length of Order#2 04 11021101 Table 8-10 Data Content for the Field ORDER
1 4
The DGI 0102 Card Holder Identity must be sent to the CPS Demonstrator before DGI 0103 Card Holder Address Information. The PIN related data (DGI 1102) must be sent to the CPS Demonstrator before the PIN (DGI 1101). Note that there is no reason that Order #1 must come before Order #2. 8.2.1.2 Support for Migration to New Versions Data Element List of DGIs Description Not used at this time Length 0
Table 8-11 Data Content for the Field VERCNTL As only one version of the CPS Demonstrator application exists at this time, this field is not currently used. However, LVERCNTL must be set to 0000.
03/26/2003
57
8.2.1.3 Encrypted Data Groupings Data Element Data for first data grouping to be encrypted Data for second data grouping to be encrypted Data for third data grouping to be encrypted Description 110111 810111 910111 Length 3 3 3
Table 8-12 Contents of the Field ENC with PIN data 8.2.1.4 Group of Data Grouping Data Element List of DGIs Description Not used at this time Length 0
Table 8-13 Data Content for the Field GROUP This version of the CPS Demonstrator application does not require any group DGIs to be placed in one STORE DATA command. This field is not currently used. However, LGROUP must be set to 0000.
8.3 Completion of Personalization

8.3.1 CPS Demonstrator Table 8-14 lists the contents of DGI 7FFF developed for a CPS Demonstrator application. Data Element DGI Length Description 7FFF Length of data to be included in last STORE DATA command value 03 Key check value for AKSCPS Table 8-14 Data Content for DGI 7FFF The key check value for AKSCPS must be computed by encrypting 8 bytes of 00 using the key AKSCPS and Triple DES. Length 2 1 3
03/26/2003
58
9. Examples of APDU mapping to T=0 TPDU

For communication with a smart card several transport protocols exist. Typically, in the terminal there is a specific piece of software that takes care of the transport protocol. This is denoted by the Terminal Transport Layer (TTL). At TTL level, communication with a card is done by the exchange of transport protocol data units (TPDU) as defined in ISO/IEC 7816-3. At the TTL level, the card may return Status Words where SW1 has value 61 or 6C. These are interpreted by the TTL level T=0 driver with which the personalization device communicates. The TTL should perform the correct processing as indicated by these SW values. As such, the personalization device does not receive these Status Words. The only exception to this rule is for case 4 commands in which the card processing results in a response that is longer than Le bytes, in which case the card informs the personalization device of the number of response bytes still available. The mapping between APDUs and TPDUs is specified in ISO/IEC 7816-3 and ISO/IEC 7816-4 and is out of scope of this document. Followings tables provide examples of coding Command APDU and Command TPDU as well as Response APDU and Response TPDU for different command cases:
Sequence C-APDU C-TPDU R-TPDU R-APDU 80 3E 00 04 80 3E 00 04 00
Exchanged strings
90 00 90 00 Table 9-1 Case 1 command
Sequence C-APDU C-TPDU R-TPDU R-APDU 80 CA DF 0A 04 80 CA DF 0A 04
Exchanged strings
DF 0A 01 F3 90 00 DF 0A 01 F3 90 00 Table 9-2 Case 2 command with matching expected length
Sequence
C-APDU C-TPDU R-TPDU C-TPDU R-TPDU R-APDU 80 CA DF 0A 04 80 CA DF 0A 00 80 CA DF 0A 00
Exchanged strings
6C 04 DF 0A 01 F3 90 00 DF 0A 01 F3 90 00 Table 9-3 Case 2 command, greedy mode
03/26/2003
GlobalPlatform Guide to Common Personalization v1.0 Exchanged strings 80 CA DF 0A 01 80 CA DF 0A 01
59
Sequence C-APDU C-TPDU R-TPDU R-APDU
DF 61 03 DF 61 03 Table 9-4 Case 2 command with too low expectations
Sequence C-APDU C-TPDU R-TPDU R-APDU
Exchanged strings 80 7A 00 01 09 08 60 27 61 98 CF 17 60 CB 80 7A 00 01 09 08 60 27 61 98 CF 17 60 CB 90 00 90 00 Table 9-5 Case 3 command
Sequence C-APDU C-TPDU R-TPDU C-TPDU R-TPDU R-APDU 00 C0 00 00 10 80 CE 00 01 03 D0 01 00
Exchanged strings 80 CE 00 01 03 D0 01 00 00 61 10 D0 01 00 D2 01 00 C0 02 00 03 C2 01 14 C3 01 00 90 00 D0 01 00 D2 01 00 C0 02 00 03 C2 01 14 C3 01 00 90 00 Table 9-6 Case 4 command, greedy mode
Sequence C-APDU C-TPDU R-TPDU C-TPDU R-TPDU R-APDU 00 C0 00 00 10 80 CE 00 01 03 D0 01 00
Exchanged strings 80 CE 00 01 03 D0 01 00 10 61 10 D0 01 00 D2 01 00 C0 02 00 03 C2 01 14 C3 01 00 90 00 D0 01 00 D2 01 00 C0 02 00 03 C2 01 14 C3 01 00 90 00
Table 9-7 Case 4 command anticipating the correct response length Sequence C-APDU C-TPDU R-TPDU C-TPDU R-TPDU R-APDU 00 C0 00 00 0A D0 01 00 D2 01 00 C0 02 00 03 61 06 D0 01 00 D2 01 00 C0 02 00 03 61 06 Table 9-8 Case 4 command with too low expectations
Exchanged strings 80 CE 00 01 03 D0 01 00 80 CE 00 01 03 D0 01 00 61 10

GP GCP 1.0 030326

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

GP GCP 1.0 030326

Hochgeladen von

Copyright:

Verfügbare Formate

Guide to Common Personalization

Version 1.0 March 2003

GlobalPlatform Guide to Common Personalization v1.0

GlobalPlatform Guide to Common Personalization v1.0

03/26/2003 7.1.33 7.1.34 8.

GlobalPlatform Guide to Common Personalization v1.0

Examples of APDU mapping to T=0 TPDU ___________________________________________ 58

GlobalPlatform Guide to Common Personalization v1.0

GlobalPlatform Guide to Common Personalization v1.0

GlobalPlatform Guide to Common Personalization v1.0

1.2 Intended Audience

1.3 Document Structure

GlobalPlatform Guide to Common Personalization v1.0

1.4 Normative References

ISO/IEC 7816-4, 1997

1.5 Abbreviations and Notations

GlobalPlatform Guide to Common Personalization v1.0

sign( )[ ] verify( )[ ] SHA( )

GlobalPlatform Guide to Common Personalization v1.0

May: Defines a product or system capability that is optional.

GlobalPlatform Guide to Common Personalization v1.0

2. Overview of the Common Personalization Process

2.1 The Infrastructure of Common Personalization

GlobalPlatform Guide to Common Personalization v1.0

2.2 Secure Messaging

2.3 The STORE DATA Command and Data Groupings

GlobalPlatform Guide to Common Personalization v1.0

2.4 The Data Container Format

GlobalPlatform Guide to Common Personalization v1.0

GlobalPlatform Guide to Common Personalization v1.0

2.5 Common Personalization and CAMS

GlobalPlatform Guide to Common Personalization v1.0

Specify Application Requirements, including Personalization Data Layout

Request Application Code, Application Profile and Application Script Fragments

GlobalPlatform Guide to Common Personalization v1.0

GlobalPlatform Guide to Common Personalization v1.0

MIC MIC MIC

Magnetic Stripe Data Graphic Data Len IC Card Application Data

2.6 Process Overview

GlobalPlatform Guide to Common Personalization v1.0

Not e, Ma y be it er a t ive or wor kflow

GlobalPlatform Guide to Common Personalization v1.0

* Not e, May be it er a t ive or wor k flow

GlobalPlatform Guide to Common Personalization v1.0

3.1 Creating Personalization Data

GlobalPlatform Guide to Common Personalization v1.0

3.2 Creation of Data Groupings

GlobalPlatform Guide to Common Personalization v1.0

3.3 DGIs Defined by Common Personalization

GlobalPlatform Guide to Common Personalization v1.0

GlobalPlatform Guide to Common Personalization v1.0

3.4 Multiple Transport Key Capability

TYPETK #1 CMODE for TK #1

Number of DGIs for TK #1 DGIs for TK #1

03/26/2003 Field For entry #n IDTK #n

TYPETK #n CMODE for TK #n

Number of DGIs for TK #n DGIs for TK #n

3.5 Processing Step

3.6 Creation of Personalization Device Instructions (Processing Step 0F)

GlobalPlatform Guide to Common Personalization v1.0

Length Order of DGIs

GlobalPlatform Guide to Common Personalization v1.0

DGI #n Encryption type 2 1