Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Table of Contents
1. INTRODUCTION .................................................................................................................................................6
1.1 SUMMARY ....................................................................................................................................................6
1.2 SCOPE ...........................................................................................................................................................6
1.3 AUDIENCE ....................................................................................................................................................7
1.4 NORMATIVE REFERENCES ............................................................................................................................8
1.4.1 List of References.................................................................................................................................8
1.4.2 GlobalPlatform Document Navigation..............................................................................................10
1.5 TERMINOLOGY AND DEFINITIONS ...............................................................................................................11
1.6 ABBREVIATIONS AND NOTATIONS ..............................................................................................................17
1.7 REVISIONS HISTORY ...................................................................................................................................18
2. OVERVIEW ........................................................................................................................................................19
2.1 APPLICATION CODE AND LOAD FILE PROFILE ............................................................................................20
2.2 APPLICATION PROFILE AND CUSTOMIZATION SCRIPTS ...............................................................................20
2.3 APPLICATION SPECIFIC KEYS .....................................................................................................................21
2.4 OTHER CUSTOMIZATION SCRIPTS ...............................................................................................................21
2.5 APPLICATION INSTALLATION OPTIONS .......................................................................................................22
2.6 EXTERNAL DATA REQUIREMENTS FOR APPLICATION PERSONALIZATION ..................................................22
2.7 SELECTABLE SMART CARDS AND CARD PROFILES .....................................................................................23
2.8 CARD ISSUER SUPPLIED OR MANAGED KEYS .............................................................................................23
2.9 SMART CARD MANAGEMENT SYSTEMS ......................................................................................................23
3. THE CARD CUSTOMIZATION PROCESS ...................................................................................................25
3.1 CARD CUSTOMIZATION AND CARD PERSONALIZATION ..............................................................................26
3.2 MAJOR CUSTOMIZATION COMPONENTS......................................................................................................26
3.2.1 XML Parser .......................................................................................................................................26
3.2.2 Card Configuration ...........................................................................................................................26
3.2.3 Conflict Check ...................................................................................................................................27
3.2.4 Interface.............................................................................................................................................27
3.2.5 Script Interpreter ...............................................................................................................................27
3.3 CARD CUSTOMIZATION PROCESSES ............................................................................................................28
3.3.1 Application Development...................................................................................................................30
3.3.2 Personalization Data Preparation ....................................................................................................33
3.3.3 Card Customization ...........................................................................................................................36
3.3.4 Customization Validation (or Verification) .......................................................................................39
3.3.5 Post Issuance Customization .............................................................................................................41
3.4 RESPONSIBILITIES .......................................................................................................................................43
3.4.1 Application Developer Responsibilities.............................................................................................43
3.4.2 Application Provider Responsibilities ...............................................................................................43
3.4.3 Card Issuer Responsibilities ..............................................................................................................43
3.4.4 Card Manufacturer Responsibilities..................................................................................................44
3.4.5 Application Loader Responsibilities..................................................................................................44
4. PROFILES AND CARD CUSTOMIZATION PROCESS..............................................................................45
4.1 APPLICATION PROFILES ..............................................................................................................................46
4.2 CARD PROFILES ..........................................................................................................................................46
List of Tables
Table 1-1: GP Normative References..........................................................................................................................8
Table 1-2: non GP Normative References.................................................................................................................10
Table 1-3: Terminology and Definitions ...................................................................................................................16
Table 1-4: Abbreviations and Notations....................................................................................................................18
Table 4-1 – Summary of Profiles ..............................................................................................................................45
Table 4-2 – Additional Conflict Determination Rules...............................................................................................53
Table 5-1 – Minimum Scripts for every Security Domain Application Profile.........................................................56
Table 5-2 – Minimum Scripts for Application Profile ..............................................................................................56
Table 5-3 – Supplementary Scripts ...........................................................................................................................57
List of Figures
Figure 3-1 – Logical Representation of Card Customization Processes....................................................................29
Figure 3-2 – Work Flow for Application Development ............................................................................................32
Figure 3-3 – Work Flow for Personalization Data Preparation.................................................................................34
Figure 3-4 – Work Flow for Pre-Issuance Card Customization ................................................................................38
Figure 3-5 – Work Flow for Customization Validation (or Verification) .................................................................40
Figure 3-6 – Work Flow for Post-Issuance Card Customization ..............................................................................42
Figure 4-1 – Relationship between Card Profile and Card without SCMS ...............................................................47
Figure 4-2 – Relationship between Card Profile and Cards with SCMS...................................................................47
Figure 4-3 – Examples of Using Tag EE and SCMS Fields......................................................................................49
Figure 4-4 – Smart Card Identification Using Card Profile ......................................................................................51
Figure 5-1 – Suggested GP Scripting Objects Available for Use by Load/Install Scripts ........................................59
Figure 5-2 – Minimum Profile and Script Components for Load/Install Script........................................................60
Figure 5-3 – Minimum Object Creation for Load/Install Script................................................................................61
Figure 5-4 –Suggested GP Scripting Objects Available for Use by Data Preparation Scripts..................................64
Figure 5-5 – Minimum Profile and Script Components for Data Preparation Script ................................................65
Figure 5-6 – Minimum Object Creation for Data Preparation Script ........................................................................66
Figure 5-7 –Suggested GP Scripting Objects Available for Use by Personalization Scripts ....................................69
Figure 5-8 – Minimum Profile and Script Components for Personalization Script...................................................70
Figure 5-9 – Minimum Object Creation for Personalization Script ..........................................................................71
Figure A- 1 – Examples of Interactions Using Profiles.............................................................................................72
Figure A- 2 - Smart Cards and GP Card Profile for ACME MegaCard 1.0.0...........................................................73
Figure A- 3 –Card and Card Profile for ACME MegaCard 1.0.0 with EasyChipPay...............................................74
Figure A- 4 – UniversalChip Supply Chip Information using a Partial Card Profile................................................74
Figure A- 5 – GP Application Profile for Bleinheim’s Security Domain Application..............................................75
Figure A- 6 – Profile and Script for Load/Install at the Personalization Bureau.......................................................75
Figure A- 7 – Four Personalized Smart Cards with One GP Card Profile ................................................................77
Figure A- 8 –Application Profile Created for EasyChipPay .....................................................................................78
Figure A- 9 – GP Load File Profile Created for EasyChipPay Application..............................................................78
1. Introduction
1.1 Summary
For smart card implementations, one of the key efforts facing card issuers is the processes involved in
transforming a basic smart card product to one that is personalized for an individual cardholder or customer.
For each application the issuer considers as part of their smart card offerings, time must be set aside to
understand the requirements for the application in order for the application to be successfully placed on a smart
card. These requirements include potential smart card dependencies, installation options for the application,
data requirements, and steps used to personalize the application onto the smart card. These requirements and
the resultant implementation effort are multiplied when multiple permutations are available for the
customization of an application.
Currently, for each of the requirements, the card issuer’s choice of vendor(s) for the relevant supporting
systems dictates the technology and processes to use to fulfill the requirement. Unfortunately, in the absence of
pervasive standards, this entails a proprietary approach. Furthermore, since card issuers will select the systems
which offer the best solution for their particular business requirements and existing technology infrastructure,
systems integration work between incompatible systems adds to the workload.
While with static card issuance, the systems integration work is a one time affair, the dynamic character of
multi-application issuance will impact the card issuer with each new application offered or issuer card product
marketed. GlobalPlatform, being a organizational vehicle to facilitate the adoption and propagation of multi-
application smart card implementations, has tasked itself with creating standards to help streamline the card
customization process and for inter-system integration. There are currently two specifications which help
standardize the card customization process, and the latter of these two specifications is also the first step to
setting the stage for inter-system integration. These two specifications are GlobalPlatform Systems Scripting
Language Specification 1.0 [GP_SYS_SCR] and GlobalPlatform Systems Profiles Specification 1.0
[GP_SYS_PRF]
1.2 Scope
The objectives of this document are:
• To describe the card customization process under GlobalPlatform;
• To describe the major customization components required to implement the card customization process
under GlobalPlatform;
• To define the responsibilities for each of the major roles involved in the card customization process
under GlobalPlatform;
• To describe how GP profiles and the GP Scripting Language should be used for card customization
under GlobalPlatform;
• To provide examples of potential card customization implementation scenarios.
Version 1.0 of this document focuses on using
• The GlobalPlatform Card Profiles, Application Profiles, Key Profiles, and Load File Profiles defined in
GlobalPlatform Systems Profiles Specification 1.0 [GP_SYS_PRF].
• The GP Scripting Language defined in the GlobalPlatform Systems Scripting Language Specification
1.0. [GP_SYS_SCR]
1.3 Audience
This document targets a broad audience, including business analysts, project managers, and systems integrators,
because it addresses the core methodology behind facilitating smart card customization in a GlobalPlatform
multi-application smart card implementation.
This document will be particularly useful to:
• Card manufacturers who will create profiles for their smart card products;
• Application developers who will create profiles and scripts for their applications;
• Actors involved in the architecture, design, and implementation of systems supporting card
customization tasks, including smart card software and hardware vendors, personalization bureaus,
application developers, card issuers, or parties providing services to any of these entities;
• Actors who need to utilize and modify profiles and scripts in order to complete card customization
objectives.
GlobalPlatform Systems Scripting Language [GP_SYS_SCR] Defines the language to use to create code
Specification v1.0 to customize multi-application smart cards.
GlobalPlatform Systems Profiles Specification [GP_SYS_PRF] Basic XML data structures used to describe
v1.0 smart cards, applications, and related entities
Application Developer Actor responsible for the development of Smart Card applications
Application Identifier Uniquely identifies an application in a smart card according to ISO 7816-5.
Application Protocol Data Unit Standard communication messaging protocol between a card accepting
(APDU) device and a smart card
The link between the application and the external world during a Card
Application Session Session starting with the Application selection and ending with Application
de-selection or termination of the Card Session
Code and Application information (but not Application data) contained in the
Card Content card that is under the responsibility of the OPEN e.g. Executable Load
Files, Application instances, etc
Card Customization
Entity that owns the card and is ultimately responsible for the behavior of
Card Issuer
the card
Generic term for the 3 card management entities of an Open Platform card
Card Manager i.e. the Open Platform Environment, Issuer Security Domain and the
Cardholder Verification Method Services provider
Term Definition
Role that is responsible for producing (smart) cards on behalf of a Card
Issuer. What services are performed depend on its contractual relationship
(Smart) Card Manufacturer
with the Card Issuer and may include part or all of the card production
process.
The Card Profile describes a smart card. This card could be a singularly
unique card or a card that shares common characteristics, as defined in the
Card Profile
Card Profile, with other cards. Depending on how it is used, it either acts as
a base template for a smart card or represents a single smart card by itself.
The link between the card and the external world starting with the ATR and
Card Session
ending with a subsequent reset or a deactivation of the card
Data that uniquely identifies a card being the concatenation of the Issuer
Card Unique Data
Identification Number and Card Image Number
A message sent by the host to the smart card that initiates an action and
Command
solicits a response from the smart card.
Term Definition
DAP Block Part of the Load File used for ensuring Load File Data Block verification
Data Authentication Pattern Used to authenticate and/or verify the integrity of the data. This can be
(DAP) done using a DES key or Public key mechanism.
The process of gathering and preparing the necessary application data and
Data Preparation keys for input into the personalization device. The process can be driven by
the Data Preparation Scripts provided in the Application Profile.
A logical term used to represent the back end systems that support the
Open Platform system; hosts perform functions such as authorization and
Host
authentication, administration, post-issuance application code and data
downloading, and transactional processing
Copyright 2002 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.
08/13/2002 GlobalPlatform Card Customization Guide v1.0 14
Term Definition
Immutable Persistent Memory Memory that can only be read
The existence of Card Content on an Open Platform card and the various
Life Cycle
stages of this existence where applicable
Life Cycle State A specific state within the Life Cycle of the card or of Card Content
A file transferred to an Open Platform card that contains a Load File Data
Load File
Block and possibly one or more DAP Blocks
Part of the Load File that contains one or more application(s) and libraries
Load File Data Block or support information for the application(s) as required by the specific
platform
Load File Data Block Hash A value providing integrity for the Load File Data Block
A value encompassing the Load File Data Block Hash and providing both
Load File Data Block Signature
integrity and authenticity of the Load File Data Block
One-way hash method to generate a 16 byte digital signature which is, in all
MD5
likelihood, unique
Open Platform Environment The central on-card administrator that owns the Open Platform Registry
Term Definition
Scripts that are created by the scripting process and used for the Card
Personalization process. There are three types of scripts:
• Data Preparation Script (DPS),
• Card Creation Script (CCS),
Personalization Script
• Data Verification Script (DVS),
• And other scripts used for post-issuance personalization activities.
Each script will be unique for each personalization run
Term Definition
Functionality which may be resident in an singular application or
Smart Card Management incorporated into existing card management systems that provides facilities
System (SCMS) for supporting the administration, personalization, and issuance of smart
cards
A cryptographic technique that uses the same secret key for both the
Symmetric Cryptography
originator's and the recipient's transformation
EMV Europay, MasterCard, and Visa; used to refer to the ICC Specifications for Payment Systems
IC Integrated Circuit
LV Length Value
P1 Parameter 1
P2 Parameter 2
P3 Parameter 3
Abbreviation Meaning
ROM Read-only Memory
SW Status Word
2. Overview
This section provides a high level synopsis of how GlobalPlatform Systems Scripting Language Specification
1.0 [GP_SYS_SCR] and GlobalPlatform Systems Profiles Specification 1.0 [GP_SYS_PRF] can be used to
standardize the card customization process. At the most simplest level, the first specification defines a
language to use to write individual scripts for discrete card customization tasks, and the second specification
defines a data interchange format for applications, cards, keys and load files. Together, the GP Scripting
Language and the profiles form a standardized and powerful toolset for the modification of smart cards in every
step of the card customization process, from initial card enablement to the final decommissioning of an issued
smart card.
After understanding this overview, the reader can delve into Section 3 – The Card Customization Process and
reference the two technical documents GlobalPlatform Systems Scripting Language Specification 1.0 and
GlobalPlatform Systems Profiles Specification 1.0 as required. The end goal of this process is to fully
understand how to create and employ profiles and scripts to enable card customization.
The role of scripts and profiles is best appreciated by understanding the roles and responsibilities which can be
undertaken by the actors, and correspondingly, the actors’ systems, in a multi-application smart card
implementation. In the CAMS model defined in [GP SYS_SCMS_REQ], a card issuer will receive an
application from an application provider, who secures the application from an application owner, who in turn,
resorts to an application developer to develop and maintain the application. From the perspective of card
customization, the application developer is the originator of:
• The application code packaged in a load file, and a corresponding Load File Profile for the load file.
• An Application Profile for the application, which includes scripts for how to prepare data for each
different type of installation for their application, and finally, the smart card commands required to
personalize their application onto a smart card.
• Application specific keys required for the preparation of data and the personalization of the application,
along with the corresponding Key Profiles.
• Optional scripts for other customization functions such as post issuance data preparation or
personalization.
• A document summarizing the installation options available for their application, and the resultant
parameters and external data required by the scripts, including parameters to pass to a security domain’s
load and/or install scripts.
After the applications for an issuer’s smart card offering are determined, the card issuer controls:
• The viable smart cards for the application portfolio selected, along with the corresponding Card Profiles.
• Card issuer controlled keys required for the personalization of applications.
• Smart Card Management services to manage smart card offerings.
Profiles are required to both initiate and complete the card customization process. For both card configuration
purposes and card production purposes, the larger role of profiles is to provide enough informational and
process instructions to successfully determine whether a portfolio of applications is viable on a selected smart
card platform, and subsequently supply the instructions required to customize the card.
In concert with the GP Scripting Language defined in GlobalPlatform Systems Scripting Language
Specification 1.0 [GP_SYS_SCR], which offers an open and flexible language for the representation of these
instructions, the ensuing GlobalPlatform card customization architecture offers a solution for each of the
components described above.
Normative References):
• Multi Application Smart Card Management Systems GlobalPlatform Functional Requirements;
• GlobalPlatform Smart Card Management Systems Implementation Guide.
Essential information concerning the selected smart card platform, less formally referred to as the card or smart
card, and the desired application portfolio must continually be interchanged with systems performing data
preparation, personalization, and post-issuance functionality. SCMS will help determine whether a selected
application portfolio and smart card platform is compatible, and whether the intended personalization device
can support the physical personalization requirements, requiring that this data be provisioned to these systems
through agreed upon interfaces and formats. This information, or content, will be provided in the form of
separate collections of data termed GlobalPlatform Profiles for cards, applications, keys, and load files.
It’s also important to distinguish between GlobalPlatform profiles and the messages that will be eventually
transported between the different systems in a GlobalPlatform Smart Card implementation. The profiles as they
are described in GlobalPlatform Systems Profiles Specification 1.0 [GP_SYS_PRF]and the scripts as they are
described in GlobalPlatform Systems Scripting Language Specification 1.0 [GP_SYS_SCR]represent the
format to be used when exchanging them. However, the GlobalPlatform Profiles and Scripts as they are
described in this document may be a component of a message being exchanged between systems. Therefore, in
the future, the GlobalPlatform profiles and scripts as they exist today may be a component of a standardized
message, such as in the response to a request for profile message. For the time being, it is suggested that the
implementer package the profiles and scripts in a manner seen as most suitable for their particular
implementation.
3.2.4 Interface
The Interface component has responsibility for interfacing with other systems in order to exchange profiles and
scripts and support future standardized GlobalPlatform Messages defined in [GP_SYS_MSG]
GP Application Profile +
Application GP Load File Profile
Development
GP Script
GP Card Profile
Card Interpreter
Manufacturer
GP Device Profile
(Future) Personalization
Device
Manufacturer Data
Data Prep. Preparation External
XML Parser
Updated GP Card Configuration Script Data
Card Profile1
and/or Specific SCMS Perso. Data File
Card Information2 (i.e., P3 file)
Interface
Card Creation
Script
Profiles
Updated GP Card
GP Application Profile +
Card Profile1 Personalization
GP Load File Profile Personalized
and/or Specific Smart Cards
Card Information2 GP Card Profile
Data Verification
Script
Personalization
Validation Personalized
Card Customization Smart Cards
Messaging3
Application
Specific Scripts
Post Issuance
Personalization
Personalized
Smart Cards
NOTES:
1. If the Card Profile Unique ID is updated as a result of a card customization activity, then the information
needs to be returned to the SCMS.
2. If the Card Profile associated with the card contains SCMS specific fields that uniquely identify a smart
card, then this information needs to be returned to the SCMS.
3. Card customization messaging represents the interchange of card customization related messages
between system entities in a GlobalPlatform smart card Systems Infrastructure. Several of these
messages are specified in GlobalPlatform work to date. However, a consistent and integrated messaging
infrastructure is the objective going forward. This will be reflected in the GlobalPlatform Messaging
Specification v1.0 under Development [GP_SYS_MSG]
Test Smart
Card
GP Application
XML JS
Profile
Signed Application
GP Scripts Code
XML
Application
Provider
Certificate
Authority
Either an issuer or
application provider
managed database.
Application/Issuer
Database System
Certificates
GP Application
JS
Profile(s)
Data Prep
Script
Conflict Check
Card
Configuration
SCMS
In the Application Profiles, the keys used by each of the scripts are defined. In turn, the card customization
system will reference the appropriate Key Profiles identified by these keys in order to retrieve necessary
information and behavior characteristics of the key. Thus, the Key Profiles enable locating (and using) the
cryptographic keys: examples include a “master” DES key for deriving session keys or an application provider
MAC key for performing MAC operations on personalization APDU commands
The card issuer (or the application provider) provides the personalization (master) keys used by these
cryptographic instructions.
The card creation scripts utilize references to data elements as defined in the Application Profiles. These
references need to be interpreted by the card customization system in order to:
• Import the actual load files containing the different applications code;
• By means of the data elements defined in the Application Profile and implementation dependent data
mapping, import, export, and update where specified, the actual data values defined in:
√ An optional card issuer (or application provider) static data file containing the data values
common to a specific batch of cards: examples include an activation date or key version identifier
that contains the same value for each card in a batch. Such a file would be present when the
personalization data file does not contain all of the required application personalization data;
√ The card issuer (or application provider) personalization data file containing the data values
unique to each card and cardholder: examples include a cardholder name, expiration date, or PAN.
The data mapping is specific to each personalization data file format and each card customization system. The
data mapping of data elements outside of the personalization data file is the implementation dependent
component of smart card customization since there is no way to know from an application developer standpoint
the name of parameters, keys, and data used in actual implementations. However, the application developer
would create scripts that would process the personalization data file, which would have been created with a data
preparation script written by the same application developer. Thus, the application developer always knows
what format the personalization data file will take when writing the personalization script for it.
Application
Development
Either an issuer or
application provider
managed database.
GP Card
JS
Profile
Perso GP Application
Script Profile(s)
SCMS
XML Parser
Interface
Either an issuer or
application provider
managed database.
Personalized
Database System Card(s) to Test
Data requirements in
testing will depend on
the nature of the test
scripts being executed.
Validation/
Test Data File
Testing System
Conflict Check
Card
Configuration
SCMS
XML Parser
Interface
Application
Development
Either an issuer or
application provider
managed database.
Application Personalized
Data requirements in Database System Smart Card
post-issuance will Code
depend on the operation
being performed on the
smart card.
Data Mapping
Static Data Files
GP Script
Interpreter GP Card Profile
Personalization XML Parser
Keys Specific Card
Update
SCMS
XML Parser
Interface
3.4 Responsibilities
The responsibilities of the different roles involved in the smart card customization process are detailed in the
CAMS model defined in [GP SYS_SCMS_REQ] but are summarized below:
• Provides personalization parameters, personalization cardholder data file, and (optional) static data file
for its own applications;
• When agreed with the application provider:
√ Generates itself or via an agent (e.g. a Service Bureau) Card Profile documents reflecting up-to-
date specific cardholder information and personalization scripts for its own applications only;
√ Provides Card Profile documents with up-to-date specific cardholder information to the
Application Provider;
• Otherwise, generates itself or via an agent (e.g. a Personalization Bureau) updated Card Profile and
personalization scripts for all applications.
Load File Profile The Load File Profile describes the application code
file that could contain one or more applications or
describe for an application one of the load files that
may make up that application code.
Card Profile
Smart Card
Referenced
Personalized GP Card
Tag EE 'A' Smart Card Profile 'A'
Personalized GP Card
Tag EE 'B' Smart Card Profile 'B'
Figure 4-1 – Relationship between Card Profile and Card without SCMS
Card Profile
Smart Card
Referenced
Figure 4-2 – Relationship between Card Profile and Cards with SCMS
It is important to remember that only two such usages of the Card Profile are illustrated. GlobalPlatform
Systems Profiles Specification 1.0 [GP_SYS_PRF] provides a means for standardizing information about cards.
How the Card Profile is used is entirely dependent on an implementation and how that implementation decides
to manage individual smart cards.
In addition, depending on the message being used to transport the Card Profile, it can represent different things.
If the message is a request for a Card Profile, then the Card Profile should be returned unaltered. However, if
the message is a request for information regarding a specific card in a card issuer’s smart card population, then
it is conceivable for the message to return a message formatted using the Card Profile schema including the
smart card’s card and application management information. In this case, only the format of the Card Profile is
being used to transport information about a specific card. The destination system will need to be cognizant that
the message being received is not a Card Profile even though it looks like one. The destination system is
receiving, in this case, the standard Card Profile with additional card specific information added. The
GlobalPlatform Messaging Specification [GP_SYS_MSG]will address these issues explicitly. For the time
being, implementers need to be wary of how they are using the Card Profiles.
Figure 4-3 provides examples of how Card Profiles could be used to manage the card as the card progresses
from the Chip Manufacturer to various card issuers. In this diagram, card issuer ABC decides to use only Card
Profiles to manage its customer/card relationships whereas card issuer GHI relies on a combination of the
standard Card Profile and an implementation specific SCMS Field defined in the Card Profile.
Chip Manufacturer
Manufacturer
adds core
software to the Tag EE written
chip and writes Tag EE 'A' to card with
a Tag EE value value 'A'
to the card.
GP Card Profile 'A'
Produced
Manufacturer
sells variants of
the chip to sell Issuer ABC Issuer DEF Issuer GHI
to their
customers. Tag EE 'B' Tag EE 'C' Tag EE 'D'
GP Card Profile 'B' is GP Card Profile 'C' is GP Card Profile 'D' is
GP Card Profile 'A' + GP Card Profile 'A' + GP Card Profile 'A' +
APP1 APP2 APP1 and APP2
Issuers
personalize
Personalized
their cards with GP Card Profile
Smart Cards
additional
applications and Tag EE 'D1' Personalized
Tag EE 'B1' 'B1' Smart Card
issues the cards SCMS Field '1'
to their Tag EE 'B2' 'B2' Tag EE 'D1' Personalized
customers. SCMS Field '2' Smart Card
Tag EE 'B3' 'B3'
GP Card
Issuer ABC uses GP Card Profiles to manage Profile 'D1'
their customer/card relationships. As a result,
each unique card will have an unique card Issuer GHI adds data to the card
profile. in order to manage the card/
customer relationship in their
SCMS. This becomes the SCMS
Field in a newly created card
profile.
SCMS
Step 2 Step 4
Personalized Step 3
Smart Card
Step 1
Device
Tag EE 'D1'
SCMS Field '1'
Step 1.
Chip is accessible by a reader, which reads Tag EE
Step 2.
SCMS looks up Card Profile using the Tag EE value as the identifier
Step 3.
If a SCMS field is defined in the Card Profile, the SCMS requests that that value is read
from the smart card.
Step 4.
The card accessible by the device is uniquely identified. From card and application
lifecycle management capabilities, the SCMS has a complete and accurate card image.
Table 4-2 provides some examples of common rules that may exist.
It is suggested that these minimum rules be included in every Card Profile since there is no guarantee that every
system will implement them. By including them in every card Profile, the rules are guaranteed to be considered
by the system.
1. Card Profile’s Profile Version is the same as Application Profiles’ Profile Version;
2. Card Profile’s Platform Type is the same as Application Profiles’ Platform Type;
3. Card Profile’s Platform Version is the same as Application Profiles’ Platform Version;
4. Card Profile’s OS Platform is the same as Application Profiles’ OS Platform;
5. Card Profile’s OS Version is the same as Application Profiles’ OS Version;
6. If any Application Profiles require a CryptoEngine, then the Card Profile must contain a CryptoEngine
attribute;
7. If any Application Profiles require a Contactless card, then the Card Profile must contain a Contactless
attribute;
8. Card Profile’s RAM remaining must be greater or equal than the Application Profiles’ RAM;
9. Card Profile’s EEPROM remaining must be greater or equal than the Application Profiles’ EEPROM;
10. Any AIDs on the Card (of either Load File, Load Module, or application) currently must not conflict
with any AIDs a new application (regardless of it being for a Load File or Load Module);
a. Card Profile’s Load File AIDs doesn’t conflict with Application Profiles’ AIDs
b. Card Profile’s Module AIDs doesn’t conflict with Application Profiles’ AIDs
c. Card Profile’s Instance AIDs doesn’t conflict with Application Profiles’ AIDs
Resources
Description of Types of Additional Conflict Determination Rules
Involved
Card may have specific business rules which prohibit it from using certain applications
Cards or application portfolios. There exists a minimum set of conflict rules that must exist
in all Card Profiles.
Load Files may indicate some interdependencies on other load files, or applications
Load Files
or cards.
Table 5-1 defines the minimum scripts for every Security Domain Application Profile
INSTALL Install the application from the Load File onto the smart card.
Initialize the application that has been loaded onto the smart
INITIALIZE
card.
Initialize the security domain that has been loaded onto the
INITIALIZE_SD
smart card.
Personalize the application using the data file that has been
PERSONALIZE
created by the PERSOPREP script.
Table 5-1 – Minimum Scripts for every Security Domain Application Profile
(a)
ScriptFragment Name in Application Profile
Table 5-2 defines the minimum scripts for every Application Profile
Personalize the application using the data file that has been
PERSONALIZE
created by the PERSOPREP script.
(a)
ScriptFragment Name in Application Profile
LOADSCMSFIELD Retrieves the SCMS Field for the application from the smart card.
Card Key
Figure 5-1 – Suggested GP Scripting Objects Available for Use by Load/Install Scripts
GP Card
XML The GP Card Profile for the target smart card.
Profile
Load/Install GP Application The GP Application Profile for the Security Domain from which Load/Install will be performed. This
JS XML XML Document will also contain script fragments for general Load/Install operations.
Script Fragments Profile
GP Key
XML GP Key Profiles for all the Keys used for the Load/Install Script Fragment.
Profile(s)
Access to all the Data Elements used for the Load/Install Script Fragment. At a minimum, these are
the ones defined in the ApplicationProfile.ScriptFragment.Declaration branch of the
Data Element XML document. The Load/Install Script Fragment should access Load File Name and application
Mapping install parameters as Data Elements, which will be provided by a SCMS or similar system. The
SCMS can obtain these values from the GP Application Profile and GP Load File Profile as
suggested below.
The GP Load File Profile for the load file as required for Load/
GP Load File Install operations. The Module AID and filename of the load file
XML can be extracted from this file by the SCMS and mapped to the
Profile
data element used by the script fragment.
GP Application
XML The GP Application Profile for the Card Manager (or Issuer Security Domain), if available.
Profile
Figure 5-2 – Minimum Profile and Script Components for Load/Install Script
GPSecurity
Domain
Key objects are created for, at a minimum, the Key
XML elements defined for the ScriptFragment
GPSecurity
element for the script under execution. Additional Key Data Profile Card Crypto
Object1 Object2 Domain
Keys from the Key XML under the root
ApplicationProfile element can be created. Keys are
accessed as this.key.keyname or
this.key[keyname] where keyname is the name
of the Key.
The GPApplication Pointer to a
object contains the Crypto object Pointer to a
Objects (ByteString, Number, and Boolean) are XML elements and used by the GPSecurityDomain
created for, at a minimum, the Declaration XML attributes, application. object created from
elements defined for the ScriptFragment for the script excluding the Key, a GP Application
under execution. Additional DataElements from the DataElement and Pointer to a Profile for the
DataElement XML under the root ApplicationProfile Declaration XML, Card object Security Domain
element can be created. DataElements are accessed as native created from under which this
as this.data.dataname or ECMAScript the GP Card one was installed.
this.data[dataname] where dataname is the objects. Profile.
name of the DataElement. The type of object created
depends on the Type attribute of the DataElement.
Note, however, that since there is not requirement to access the target smart card, no Card object is created or
GPSecurityDomain object is created. The objects that should be created are summarized in Figure 5-6.
[Application,
GPApplication and
GPSecurityDomain
Objects]
Built-in GPError Crypto GPSystem The APDU related
GlobalPlatform methods do not have to
be implemented in a
Scripting Objects Data Preparation
System as no smart
Application GPApplication GPSecurity
card operations should
Domain
be performed.
The GP Application Profile for the application for which data preparation is to be performed. The GP
Data Preparation GP Application Application Profile should include Script Fragments for data preparation; either the mandatory
JS XML PERSOPREP stage for initial personalization or any application specific post-issuance data
Script Fragments Profile
preparation script fragments.
GP Key GP Key Profiles for all the Keys used for the Data Preparation Script Fragment. At a minimum,
XML these are the ones defined in the ApplicationProfile.ScriptFragment.Key branch of the XML
Profile(s)
document.
Data Element Access to all the Data Elements used for the Data Prepration Script Fragment. At a minimum, these
Mapping are the ones defined in the ApplicationProfile.ScriptFragment.Declaration branch of
the XML document.
Figure 5-5 – Minimum Profile and Script Components for Data Preparation Script
Note that this is exactly the same object creation for applications as is mandated in the GlobalPlatform Systems
Scripting Language Specification 1.0, demonstrating that for personalization processes, the entire GP Scripting
Language object library is necessary.
Figure 5-7 –Suggested GP Scripting Objects Available for Use by Personalization Scripts
GP Card
XML The GP Card Profile for the target smart card.
Profile
Personalization GP Application The GP Application Profile for the Application from which the personalization script operation will be
JS XML performed.
Script Fragment Profile
GP Key
XML GP Key Profiles for all the Keys used for the Personalization Script Fragment.
Profile(s)
Access to all the Data Elements used for the Personalization Script Fragment. At a minimum, these
Data Element are the ones defined in the ApplicationProfile.ScriptFragment.Declaration branch of
Mapping the XML document. The Personalization Script Fragment may required parameters supplied by the
SCMS or similar system as Data Elements. These are in addition to Data Elements which contain
the personalization data file.
The GP Application Profile for the Security Domain under which the application was installed. This
GP Application Profile can be identified based on SecurityDomainAID information from the GP
GP Application
XML Card Profile for the target smart card. Alternatively, this can be identified by information held in the
Profile
SCMS in cases where the GP Card Profile provides only a partial image of the card (i.e., where a
SCMSField is used).
GP Application The GP Application Profile for the Card Manager (or Issuer Security Domain), if available. This may
XML be the same as the Security Domain under which the application was installed.
Profile
Figure 5-8 – Minimum Profile and Script Components for Personalization Script
GPSecurity
Domain
Key objects are created for, at a minimum, the Key
XML elements defined for the ScriptFragment
GPSecurity
element for the script under execution. Additional Key Data Profile Card Crypto
Object1 Object2 Domain
Keys from the Key XML under the root
ApplicationProfile element can be created. Keys are
accessed as this.key.keyname or
this.key[keyname] where keyname is the name
of the Key.
The GPApplication Pointer to a
object contains the Crypto object Pointer to a
Objects (ByteString, Number, and Boolean) are XML elements and used by the GPSecurityDomain
created for, at a minimum, the Declaration XML attributes, application. object created from
elements defined for the ScriptFragment for the script excluding the Key, a GP Application
under execution. Additional DataElements from the DataElement and Pointer to a Profile for the
DataElement XML under the root ApplicationProfile Declaration XML, Card object Security Domain
element can be created. DataElements are accessed as native created from under which this
as this.data.dataname or ECMAScript the GP Card one was installed.
this.data[dataname] where dataname is the objects. Profile.
name of the DataElement. The type of object created
depends on the Type attribute of the DataElement.
UniversalChip
Chip Manufacturer
OID: None
Bleinheim
ACME Corporation Reliable Systems
SoftwareWorks UK Card Manufacturer Application Loader
Application Developer Bleinheim develops GP The GP Card Profile
OID: EEEEEEEEEE Application Profiles and OID:
RID: FFFFFFFFFF for the MegaCard Personalization
potentially sends to 1.0.0 is sent to both
Card Manufacturer. Device Issuance
bureau and issuer.
However, ACME is at
least made aware of the
platform and application Yellow will send GP Scripts and GP Profiles.
details and Other personalization data will be encapsulated in
requirements needed GlobalPlatform standard outlined in SCMS to
for the GP Card Profile Personalizatoin Bureau Interface specification.
it will construct.
Reliable Systems will execute the Personalization
Script Fragment for the PERSONALIZE stage.
GP Card
ACME MegaCard
Profile
1.0.0
'FFFFFFFFFF0000000001'
Tag EE
Tag 6 contains 'FFFFFFFFFF0000000001'
Figure A- 2 - Smart Cards and GP Card Profile for ACME MegaCard 1.0.0
ACME Corporation decides to place a value for Tag EE onto the card corresponding to this particular card
product. It constructs the UniqueID for the Card Profile that will be placed in Tag EE using its OID (Hex
FFFFFFFFFF) and a five-byte field that it sets as Hex 0000000002. Therefore, the UniqueID value for this card
Profile is Hex FFFFFFFFFF0000000002. On the smart card, this is stored in Tag 6, which is then placed in Tag
EE. This is illustrated in Figure A- 2.
Note that this differentiates this specialized card product from ACME Corporation’s standard ACME
MegaCard1.0.0 product.
The XML documents supplied by ACME Corporation for the ACME MegaCard1.0.0 are comprised of a Card
Profile for the ACME MegaCArd1.0.0, an Application Profile for Security Domain or Card Manager, and an
Application Profile for the payment application EasyChipPay. These latter two profiles are not necessarily
created by ACME Corporation, but they must be made available to the end customer.
ACME Corporation Adds
ACME Corporation Provides the
EasyChipPay application to the
GP Card Profile
ACME MegaCard 1.0.0
GP Card
ACME MegaCard 1.0.0
Profile
with EasyChipPay added
'FFFFFFFFFF0000000002'
Tag EE
Tag 6 contains 'FFFFFFFFFF0000000002'
Figure A- 3 –Card and Card Profile for ACME MegaCard 1.0.0 with EasyChipPay
GP Card Profile
(with info known by Chip
Manufacturer)
GP Card Profile The GP Card Profile for the target ACME MegaCard1.0.0 with EasyChipPay preloaded from ACME
XML Corporation.
'FFFFFFFFFF0000000002'
The GP Application Profile from Bleinheim SoftwareWorks UK for the Security Domain from which
Load/Install GP Application Profile Load/Install will be performed. This XML Document will also contain script fragments for general
JS XML Load/Install operations. This Security Domain happens to be the Issuer Security Domain (Card
Script Fragments 'EEEEEEEEEE0000112233'
Manager) for the ACME MegaCard1.0.0 as well.
GP Key GP Key Profiles for all the Keys used for the Load/Install Script Fragment as specified in the GP
XML
Profile(s) Application Profile provided by Bleinheim SoftwareWorks UK.
Access to all the Data Elements used for the Load/Install Script Fragment. The Load/Install Script
Data Element Fragment should access Load File Name and application install parameters as Data Elements,
Mapping which will be provided by Yellow Industries' SCMS. The SCMS can obtain these values from the GP
Application Profile and GP Load File Profile for LoyaltyApp as suggested below.
GP Application The GP Application Profile provided by Loyalty Applications Company for the
XML LoyaltyApp application to Load/Install. The GP Application should be used to
Profile
point to the correct GP Load File Profile.
The GP Load File Profile provided by JavaMan's Application Hut for the load file
GP Load File as required for Load/Install operations. The Module AID and filename of the load
XML
Profile file can be extracted from this file by Yellow Industries' SCMS and mapped to the
data element used by the script fragment.
The card issuer will also have the Application Profile for the LoyaltyApp on hand in addition to the Application
Profile for EasyChipPay. This will be necessary to personalize the application using the scripts supplied with the
Application Profile, and also to perform any post-issuance or re-issuance personalization necessary for smart
cards with the application loaded.
The XML documents supplied by Yellow Industries include a new P Card Profile for the ACME MegaCard1.0.0
containing the reference to the SCMS Field used to manage the card in Yellow Industries’ SCMS.
Figure A- 7 illustrates four different smart cards issued by Yellow Industries in this example. The diagram also
shows only one GP Card Profile that is associated with all four cards. In this GP Card Profile, their would be a
SCMSField element with the Name attribute set to ‘FUD’.
Yellow Industries Adds LoyaltyApp and
Personalizes Smart Cards for their Customers
Tag EE 'AAAA0000000002'
SCMS Field 'FUD' '0001'
Tag EE 'AAAA0000000002'
SCMS Field 'FUD' '0002'
Tag EE 'AAAA0000000002'
SCMS Field 'FUD' '0003'
Tag EE 'AAAA0000000002'
SCMS Field 'FUD' '0004'
GP Card Profile
XML 'AAAA0000000002'
The Application Provider, JavaMan's Application Hut, supplies the application's Load File and Load File Profile.
However the UniqueIDs of the Application Profile doesn’t change from what Payment Systems Corporation
specified since JavaMan will not have changed the application at all. In this scenario, however, there is
communication between JavaMan and Payment Systems Corporation in order to include the correct ModuleID
and Module AID in each of the Application and Load File Profiles.
Payment Systems Corporation Provides the GP
Application Profile for EasyChipPay Application
Data Preparation
GP Application Profile
and Personalization JS XML
'DDDDDDDDDD0000001010'
Script Fragments
Payment Systems Corporation Supplies Application Profile for New Release of an Application
Suppose that Payment System Corporation releases a new version of their EasyChipPay application that
incorporates several new features into it. A new Application Profile with new UniqueID for the
ApplicationProfile component would be released. This could be a revision on the previous version of the
Application Profile for EasyChipPay. As well, JavaMan will need to construct a new Load File (since it would
have changed to include the new application functionality) and a new Load File Profile.
(d) Tag APPLICATION 6 contains any proprietary identifiers. Implementers and issuers may put one or
more Object Identifiers in this data object to identify the exact implementation and/or behaviour of the
card platform, including any extensions or proprietary features. The presence of this data object depends
on the rules of the card issuer or card scheme.
GlobalPlatform may assign further application tags on request, for additional data that organisations may wish to
include. However, GlobalPlatform takes no responsibility for the information included, and does not guarantee its
interoperability. (Note that tags 1, 2 and 15 will not be assigned, as they are reserved by ISO.)
The first byte is coded as 40a+b = 40*1+2 = 42 = hexadecimal ‘2A’, the remaining bytes code the other values,
as summarized in Table B-2:
And so the binary coding of the object identifier {GlobalPlatform 1} or { 1 2 840 114283 1 } is
‘2A864886FC6B01’.
B.6 Example of the Coding of Card Data with Card Recognition Data
Taking an example of a Joe Doe card, the example assumes a simple case where Joe Doe’s Object Identifiers are
summarized in Table B-3:
Assuming that Joe Doe Inc does not mandate the use of any of the optional tags, Card Data might then be coded
on 30 bytes as summarized in Table B-4: