UICC Profiles v1.0 Dec2010 2011112312532964

2011 EMVCo, LLC (EMVCo). All rights reserved.
Any and all uses of these

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

Configuration
Version 1.0
December 2010
2009-2010 EMVCo, LLC (EMVCo). All rights reserved. Any and all uses of the EMV Specifications (Materials)
shall be permitted only pursuant to the terms and conditions of the license agreement between the user and EMVCo
found at http://www.emvco.com/specifications.aspx.
EMVCo
Contactless Mobile Payment
EMV Profiles of GlobalPlatform UICC

Configuration
Version 1.0
December 2010
EMVCo Contactless Mobile Payment

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

Contents
1
General .................................................................................................................1
1.1
Scope............................................................................................................1
1.2
Underlying Standards ...................................................................................2
1.3
Audience.......................................................................................................2
1.4
Overview.......................................................................................................2
References ...........................................................................................................3
2.1
EMV Documents...........................................................................................3
2.2
Standards .....................................................................................................3
Notations, Terminology, and Conventions .......................................................5

3.1
Notations.......................................................................................................5
3.2
Terminology ..................................................................................................5
3.3
Conventions..................................................................................................6
3.3.1
Functional Requirements....................................................................................7
4.1
Profiles..........................................................................................................8
4.2
Security Domains..........................................................................................9
Communication Interface..................................................................................11
5.1
Contactless Interface Communication ........................................................11
5.2
Contact Interface Communication ..............................................................12
Security Principles ............................................................................................13

6.1
Payment Applet Executable Load File........................................................13
6.2
Other Content Management Commands....................................................14
6.3
Ciphered Load File .....................................................................................14
6.4
Security Domains........................................................................................15
6.4.1
6.4.2
6.4.3
Requirement Numbering...................................................................6
All Profiles .......................................................................................15

Basic Profiles ..................................................................................15
Advanced Profiles ...........................................................................18
Data Requirements ............................................................................................23

7.1
Security Domain Image Number.................................................................23
7.2
Security Domain AID ..................................................................................24
7.3
Key Derivation Data....................................................................................25
December 2010
Page iii

Key Requirements .............................................................................................27
Annex A
Page iv
Glossary ................................................................................................29
December 2010

Figures
Figure 6.1:
Figure 6.2:
Figure 6.3:
Figure 6.4:
Figure 6.5:
Figure 6.6:
Example 1 of Basic Profile .....................................................................16

Example 2 of Basic Profile Supplementary Security Domains ............17
Example 1 of Advanced Profile ..............................................................19
Example 2 of Advanced Profile Supplementary Security Domains .....20
Example 3 of Advanced Profile Delegated Management ....................21
Example 4 of Advanced Profile Delegated Management and
Supplementary Security Domains ..........................................................22
December 2010
Page v

Tables
Table 4-1: Highlighted Profiles Characteristics...........................................................8
Table 7-1: KEYDATA................................................................................................25
Page vi
December 2010

General
This specification, EMVCo Contactless Mobile Payment EMV Profiles of

GlobalPlatform UICC Configuration, defines the requirements for UICCs intended to
host a payment systems mobile payment application within mobile consumer
devices (hereafter referred to as handsets).
This document provides the UICC configuration profiles acceptable to be used in a
mobile proximity payment program based on EMV1 requirements. These profiles are
based on the GlobalPlatform UICC Configuration version 1.0.
The core enabler of the proximity payment functionality is the presence of a payment
system contactless mobile payment application, customer account data, and
confidential/secret bank information on the UICC. In order to actually enable
contactless payment another key component of the mobile device is the presence of
an antenna that operates according to the EMV Contactless Communication Protocol
Specification. This connection between this antenna and the UICC can be a direct
connection or a connection through a Near Field Communication (NFC) chip or some
other module with similar functionality.
1.1 Scope
The focus of this document is to lay out the features and functionalities specified in
the GlobalPlatform UICC Configuration that are required for a contactless mobile
payment programs.
Other Secure Element types are out of scope of this document.
EMV is a registered trademark in the U.S. and other countries and an unregistered
trademark elsewhere. The EMV trademark is owned by EMVCo.
December 2010
Page 1
1 General
1.2 Underlying Standards

1.2 Underlying Standards

This specification is based on the GlobalPlatform Card Specification, the
GlobalPlatform Mapping Guidelines and the GlobalPlatform UICC Configuration and
should be read in conjunction with those documents. However, if any of the
provisions or definitions in this specification differs from those standards, the
provisions herein shall take precedence.
1.3 Audience
This specification is intended for use for suppliers of UICC for contactless mobile
payment and entities deploying one or more EMV contactless mobile payment
applications to a UICC enabled mobile device.
1.4 Overview
This volume includes the following chapters and annexes:
Chapter 1 contains general information that helps the reader understand and use
this specification.
Chapter 2 lists related specifications and standards.
Chapter 3 defines notations, terminology, and conventions used in this specification.
Chapter 4 describes required configuration features: profiles and security domains.
Chapter 5 includes requirements for contactless interface communication and
contact interface communication.
Chapter 6 discusses security principles and requirements and illustrates various
configurations employing Basic Profiles and Advanced Profiles.
Chapter 7 provides data requirements.
Chapter 8 provides key requirements.
Annex A is a glossary of terms and abbreviations used in this specification.
Page 2
December 2010

References
The following standards contain provisions that are referenced in these

specifications. The latest version shall apply unless a publication date is explicitly
stated.
2.1 EMV Documents

EMV documents are available on the EMVCo website:
http://www.emvco.com/specifications.aspx
EMV Contactless
Communication Protocol
Specification, v2.0,
August 2007
Describes the minimum functionality required of

Proximity Integrated Circuit Cards and Proximity
Coupling Devices to ensure correct operation and
interoperability independent of the application to be
used.
2.2 Standards
ISO/IEC 7816-6,
15 May 1996
Identification cards Integrated circuit(s) cards with

contacts Part 6: Inter-industry data elements.
Java Card Virtual Machine

Specification v2.2.2,
15 March 2006
Describes the required behavior of the virtual machine

(VM) for the Java Card platform (Java Card virtual
machine or Java Card VM), version 2.2.2, that
developers should adhere to when creating an
implementation.
GlobalPlatform Card
Specification v2.2,
March 2006
Defines a flexible and powerful specification for Card

Issuers to create single- and multi-Application chip card
systems to meet the evolution of their business needs.
GlobalPlatform Mapping
Guidelines of existing
GlobalPlatform 2.1.1
implementation on 2.2 v1,
February 2007
Provides implementation guidelines for mapping a

GlobalPlatform card based on Card Specification
version 2.1.1 to one based on version 2.2. This
guideline defines a subset of features specified in the
GlobalPlatform Card Specification version 2.1.1.
December 2010
Page 3
2 References
2.2 Standards

GlobalPlatform UICC
Configuration v1,
28 October 2008
Specifies configuration requirements for implementing

GlobalPlatform Specifications on the UICC platform
specified in ETSI specifications.
GlobalPlatform Card
Confidential Card Content
Management
Card Specification v2.2Amendment A v1.0
Defines a mechanism for an Application Provider to

confidentially manage its application; i.e. to load,
install, and personalize using a third party
communication network.
ETSI TS 101 220

Smart Cards;
ETSI numbering system for
telecommunication
application providers
Defines the administration and the managed allocation

of identifiers of shared name space in use by
applications on the UICC.
Page 4
December 2010

Notations, Terminology, and Conventions
3.1 Notations
'0' to '9' and 'A' to 'F'
16 hexadecimal characters
AND
Logical AND
nb, nnb, nnnb, ...
Binary values
xx
Any value
3.2 Terminology
proprietary
Not defined in this specification and/or outside the scope of

this specification
may
Denotes an optional feature
shall
Denotes a mandatory requirement
Should
Denotes a recommendation
December 2010
Page 5
3 Notations, Terminology, and Conventions

3.3 Conventions

3.3 Conventions
The following conventions apply.
3.3.1
Requirement Numbering
Requirements in this document are uniquely numbered with a 4 digit identifier

appearing next to each requirement. For example:
3.3.1.1
TheSecurityDomainwithContentManagementprivilegewithinthe
certifiedTSMhierarchyshallsupportSecureChannelProtocol'02'
implementationoption'55'.
A requirement may have different numbers in different versions of the specification.

Hence, all references to a requirement must include the version of the document as
well as the requirements number.
Page 6
December 2010

Functional Requirements
This document provides a description of the GlobalPlatform UICC Configuration

features required by EMV. These implementations shall be based on the Java
Card 2.2.2 specifications and implement the Java Card 2.2.2 API.
Based on the configuration listed in the following sections the UICC may be
instantiated with one or two (and possibly more) Security Domains with Content
Management capability prior to submission to the issuer typically an MNO.
The UICC based on these profiles will be tested to the required features that are a
subset of the GlobalPlatform UICC Configuration. If the UICC is compliant to the
GlobalPlatform UICC Configuration, then the only additional tests needed will consist
of the EMV-defined test cases associated with these requirements.
The profiles defined in this document depend on the manner in which the UICC
issuing entity and Trusted Service Manager(s) manage the Security Domains with
Content Management capability.
December 2010
Page 7
4 Functional Requirements
4.1 Profiles

4.1 Profiles
A GlobalPlatform UICC shall be implemented according to one of the following
profiles. These profiles have been defined to allow card issuers and MNOs to choose
products that match their business and security requirements.
EMV GlobalPlatform UICC Basic Profile: This implementation requires only an

Issuer Security Domain to be initialized and applies when all Content
Management of the UICC is performed by the issuing MNO.
EMV GlobalPlatform UICC Advanced Profile: This implementation requires

instantiation of two (or more) Security Domains with Content Management
capability (for example an Issuer Security Domain and an additional Security
Domain with Authorized Management Capability). This profile is intended for
cases where Content Management of the UICC is performed by the MNO and
other certified TSMs. To ensure the correct separation, additional Security
Domain(s) shall be installed and set into the PERSONALIZED state prior to
delivery of the UICC to the MNO.
Table 4-1 highlights the main characteristics of the two profiles.

Table 4-1: Highlighted Profiles Characteristics
Functionality
Basic
Profile
Advanced
Number of Security Domains with Content

Management
One
Two (or more)
Additional Security Domain
Optional
Mandatory
Additional Logical Channels
Mandatory
Mandatory
Page 8
December 2010

EMV Profiles of GP UICC Config version 1.0
4.2 Security Domains

There are three types of Security Domains:
The Security Domains with Content Management capability. That is, the Issuer
Security Domain, the Security Domain(s) with the Authorized Management
privilege and the Security Domain(s) with Delegated Management privilege.
Supplementary Security Domains assigned to an Application Provider for the

purposes of personalization.
A Controlling Authority Security Domain to allow the confidential personalization

of a Security Domain as defined in the GlobalPlatform UICC Configuration.
Support for the Controlling Authority Security Domain is not currently required.
December 2010
Page 9
Page 10

December 2010

Communication Interface
In mobile devices the ability to determine the origin of communication with the UICC
is achieved through support of multiple communications protocols.
5.1 Contactless Interface Communication

From EMVCos standpoint the primary reason for the UICCs existence is to host the
payment systems mobile contactless payment application, thus the mobile device
incorporating the UICC shall be able to conduct a contactless communication
initiated by a contactless payment terminal.
EMVCo has defined the EMV Contactless Communication Protocol Specification,
which is composed of two main parts. The analog part describes the radio frequency
characteristics and the digital part describes the conversion of the radio frequency to
digital signals. The analog protocol is mostly handled by the contactless antenna
(refer to zone C as defined in the EMVCo Contactless Mobile Payment Architecture
Overview document) which can be connected directly to the UICC or to a contactless
module such as an NFC Controller (refer to zone B as defined in the EMVCo
Contactless Mobile Payment Architecture Overview document). The digital protocol
can be implemented directly by the UICC if there is a direct connection to the
contactless antenna or can be implemented by the contactless module.
The implementation shall provide the following features:
Requirements Contactless Interface Communication
5.1.1.1
TheAPDUcommunicationshallbeabletoflowoverthe
contactlessprotocolasdefinedintheEMVContactless
CommunicationProtocolSpecification,version2.0.
5.1.1.2
Whenthecontactlessprotocol(analoganddigital)isimplemented
directlybytheUICCitshalladheretotheEMVContactless
CommunicationProtocolSpecification,version2.0.
5.1.1.3
Inordertodeterminethesourceofthecommunicationan
implementationshallbeabletoidentifycommunicationreceived
overthecontactlessinterfacebyinterrogatingthetransfer
protocoltype(T=CL).
December 2010
Page 11
5 Communication Interface
5.2 Contact Interface Communication

5.2 Contact Interface Communication

Requirements Contact Interface Communication
5.2.1.1
TheAPDUcommunicationshallbeabletoflowoverthebasic
logicalchannelaswellaslogicalchannels1,2,and3.
5.2.1.2
Inordertodeterminethesourceofthecommunicationan
implementationshallbeabletoidentifycommunicationreceived
fromthemobiledevicebyinterrogatingthetransferprotocoltype
(T=0orT=1).
Page 12
December 2010

Security Principles
The following sections describe requirements and security principles as envisaged by

EMV for the possible entities on a GlobalPlatform UICC.
6.1 Payment Applet Executable Load File

Requirements Payment Applet Executable Load File
6.1.1.1
Ifthecontactlessmobilepaymentapplicationsexecutableload
fileresidesinImmutablePersistentMemoryorresidesinMutable
PersistentMemorypriortodeliveryoftheUICCtotheMNO,then
theassociatedSecurityDomainshallinitiallybeeitherofthe
following:
TheIssuerSecurityDomainfortheBasicProfile.AstheMNOis
acertifiedTSMitcanextraditethecontactlessmobilepayment
applicationsexecutableloadfiletoanotherSecurityDomainas
pertherulesimposedbytheapplicationowner.
ASecurityDomainwithAuthorizedManagementprivilege
locatedwithinaTSMhierarchyfortheAdvancedProfile.The
TSMcanextraditethecontactlessmobilepayment
applicationsexecutableloadfiletoanotherSecurityDomainas
pertherulesimposedbytheapplicationowner.
AcertifiedTSMsSecurityDomainwithDelegatedManagement
privilege.TheTSMcanextraditethecontactlessmobile
paymentapplicationsexecutableloadfiletoanotherSecurity
Domainaspertherulesimposedbytheapplicationowner.
December 2010
Page 13
6 Security Principles
6.2 Other Content Management Commands

6.2 Other Content Management Commands

Requirements Other Content Management Commands
6.2.1.1
AllContentManagementcommandsperformedOTAona
contactlessmobilepaymentapplicationsexecutableloadfile
includingpostissuancedownloadinganditsapplication
instancesshallbesecuredusingsecurechannelSCP02witha
securitylevelof'03'(MACandAPDUcommanddatafield
encryption).CommandsmaybefurtherencapsulatedusingSCP80
withorwithoutsecurity.
6.3 Ciphered Load File

For a platform that is not capable of receiving an executable load file secured as per
requirement 6.2.1.1, a contactless mobile payment applications executable load file
may be directly secured using secure channel SCP80 as long as confidential card
content management as defined in the GlobalPlatform Card Specification v2.2,
Amendment A is used. The following requirement applies.
Requirements Ciphered Load File
6.3.1.1
Page 14
ThetargetedApplicationProviderSecurityDomainofthe
confidentialloadoperationshallhavetheCipheredLoadFileData
BlockprivilegeandtheDAPVerificationprivilege.
December 2010


6.4.1
All Profiles
Requirements Security Domains, All Profiles
6.4.1.1
6.4.2
ASupplementarySecurityDomainassignedtoanissuingbankor
usedtosecurepersonalizationofacontactlessmobilepayment
applicationshallsupportandexclusivelyuseSecureChannel
Protocol'02'implementationoption'55'forpersonalization.
Basic Profiles
Requirements Security Domains, Basic Profiles
6.4.2.1
TheIssuerSecurityDomainshallsupportSecureChannelProtocol
'02'implementationoption'55'.
6.4.2.2
TheIssuerSecurityDomainshallbetheassociatedsecuritydomain
fortheexecutableloadfilesofallcontactlessmobilepayment
applications.
6.4.2.3
Instancesofthecontactlessmobilepaymentapplicationshallbe
createdbytheIssuerSecurityDomain.
December 2010
Page 15

One example of a Basic Profile where the payment applications executable load files
and all instances are associated to the ISD is shown in Figure 6.1. In this scenario
the MNO would be a certified TSM and possibly certified by multiple payment
schemes and trusted by one or more issuing banks.
In this scenario:
The ISD is responsible of the personalization of each instance.
The support for Supplementary Security Domains is not required.

Figure 6.1: Example 1 of Basic Profile
Page 16
December 2010

Another example of a Basic Profile is an expansion of Example 1 where a

Supplementary Security Domain is created for each issuing bank and instances of a
contactless mobile payment application are associated to the banks Security Domain
as shown in Figure 6.2.
The instances of the contactless mobile payment application are created and
extradited to the corresponding Supplementary Security Domain of the issuing bank
by the ISD. The issuing bank is responsible of the personalization of the contactless
mobile payment application instance through its own Security Domain.
Figure 6.2: Example 2 of Basic Profile Supplementary Security Domains
December 2010
Page 17
6.4.3

Advanced Profiles
Requirements Security Domains, Advanced Profiles
6.4.3.1
AnySecurityDomainwithinacertifiedTSMhierarchythathasthe
ContentManagementprivilegeshallsupportSecureChannel
Protocol'02'implementationoption'55'.
6.4.3.2
ASecurityDomainwiththeContentManagementprivilegeshall
betheassociatedsecuritydomainfortheexecutableloadfileofa
contactlessmobilepaymentapplication.
6.4.3.3
ASecurityDomainwiththeAuthorizedManagementprivilegethat
istheassociatedsecuritydomainforanexecutableloadfileofa
contactlessmobilepaymentapplicationshallrejectextradition
requestsfromaSecurityDomainlocatedoutsideofthecertified
TSMhierarchy.
6.4.3.4
ASecurityDomainwiththeDelegatedManagementprivilegethat
istheassociatedsecuritydomainforanexecutableloadfileofa
contactlessmobilepaymentapplicationshallrejectextradition
requests.
Page 18
December 2010

Authorized Management Advanced Profile

An example of creating an Advanced Profile including a Security Domain with
Authorized Management privilege is provided in Figure 6.3.
In this scenario the Authorized Management Security Domain is assigned to a
certified TSM and is the associated security domain of the executable load file of
the contactless mobile payment application.
All instances of the contactless mobile payment application are associated to the
certified TSMs Security Domain which is responsible of the personalization of
each instance. In this scenario the creation of Supplementary Security Domains
under the Security Domain with Authorized Management privilege is not required.
Note that existence of a Link Platform Operator (LPO) Security Domain is at the
discretion of the MNO. For operators who do not use any OTA platform the
presence of this Security Domain is unnecessary and therefore the Security
Domain with the Authorized Management privilege becomes the root of the
independent hierarchy by being extradited to itself.
Figure 6.3: Example 1 of Advanced Profile
December 2010
Page 19

Another example of an Advanced Profile is an expansion of example 1 where a

Supplementary Security Domain is created for each issuing bank and instances
of a contactless mobile payment application are associated to the banks Security
Domain as shown in Figure 6.4.
extradited to the corresponding Supplementary Security Domain of the issuing
bank by the Authorized Management Security Domain. The issuing bank is
responsible of the personalization of the contactless mobile payment application
instance through its own Security Domain.
Figure 6.4: Example 2 of Advanced Profile Supplementary Security Domains
Page 20
December 2010

Delegated Management Advanced Profile

An example of setting an Advanced Profile including a Security Domain with the
Delegated Management privilege is provided in Figure 6.5.
In this scenario the Delegated Management Security Domain is assigned to a
certified TSM and is the associated security domain of the executable load file of
the contactless mobile payment application.
All instances of the contactless mobile payment application are associated to the
certified TSMs Security Domain which is responsible of the personalization of
each instance. In this scenario the creation of Supplementary Security Domains
under the Security Domain with Delegated Management is not required.
Figure 6.5: Example 3 of Advanced Profile Delegated Management
December 2010
Page 21

Another example of an Advanced Profile is an expansion of example 1 where a

Supplementary Security Domain is created for each issuing bank and instances
of a contactless mobile payment application are associated to the banks Security
Domain as shown in Figure 6.6.
extradited to the corresponding Supplementary Security Domain of the issuing
bank by the Delegated Management Security Domain. The issuing bank is
responsible of the personalization of the contactless mobile payment application
instance through its own Security Domain.
Figure 6.6: Example 4 of Advanced Profile Delegated Management and
Supplementary Security Domains
Page 22
December 2010

Data Requirements
The following sections describe the data requirements for the possible entities on a
GlobalPlatform UICC.
7.1 Security Domain Image Number

Requirements Security Domain Image Number
7.1.1.1
TheSecurityDomainImageNumber(SDIN)shalluniquelyidentify
thecertifiedTSMsSecurityDomainforeachindividualUICC.
7.1.1.2
ToensuretheuniquenessacrossUICCsandtheirmanufacturerthe
SDINshallconsistoftheOID(orIIN)ofthemanufacturerending
(orconcatenated)with4bytesofasequentialbinarydigit.
7.1.1.3
TheSDINshallbecontainedintheISO/IEC78166specifiedtagof
'45'andtheDGIof'0070'shallbeusedbytheSTOREDATA
commandtopopulatethistag.
7.1.1.4
TheSDINshallberetrievedusingtheGETDATAcommand.
7.1.1.5
ThemechanismtoidentifytheMasterKey(KMCID)shallbethe
combinationoftheSDINandtheKeySetversion.Theentitythat
loadsthekeystothecertifiedTSMsSecurityDomainandthe
correspondingcertifiedTSMshallbeabletoretrievetheidentifier
oftheMasterkeysharedbetweenthem.
December 2010
Page 23
7 Data Requirements
7.2 Security Domain AID

7.2 Security Domain AID

Requirements Security Domain AID
7.2.1.1
ForimplementationsconfiguredaccordingtoanAdvancedProfile
theAIDforasinglecertifiedTSMsSecurityDomainwiththe
AuthorizedManagementprivilegeshallbe'A0000001515441
0000000000B2021000'.
7.2.1.2
IfmorethanonesuchAuthorizedManagementSecurityDomain
needstobecreated,thenthesecondtolastbyteshallbe
incrementedbyoneforeachadditionalinstance;i.e.'A0000001
5154410000000000B2021100',etc.,andupto'A0000001
5154410000000000B2021F00',foramaximumof16
possibleAuthorizedManagementSecurityDomains.
7.2.1.3
ForimplementationsconfiguredaccordingtoanAdvancedProfile
theAIDforasinglecertifiedTSMsSecurityDomainwiththe
DelegatedManagementprivilegeshallbe'A000000151544400
00000000B2022000'.
7.2.1.4
IfmorethanonesuchDelegatedManagementSecurityDomain
needstobecreated,thenthesecondtolastbyteshallbe
incrementedbyoneforeachadditionalinstance;i.e.'A0000001
5154440000000000B2022100',etc.,andupto'A0000001
5154410000000000B2022F00',foramaximumof16
possibleinstances.
Note: Bytes 13 to 15 of the AID constitute the Toolkit Application Reference (TAR)
for these Security Domains.
Page 24
December 2010

7 Data Requirements
7.3 Key Derivation Data

The Key Derivation Data is used to derive the certified TSMs Security Domain static
keys (KENC, KMAC, KDEK).
Requirements Key Derivation Data
7.3.1.1
Thisdatashallbestoredinatagof'CF'oftheSecurityDomain.
TheDGIof'00CF'shallbeusedbytheSTOREDATAcommandto
populatetheKeyDerivationDatatoaSecurityDomain.
7.3.1.2
ThecertifiedTSMshallnotupdatethecontentofthetag'CF'once
itissetbytheentitythatloadedthe10SecureChannelKeySets.
HoweverthecertifiedTSMcanrotateitsassignedKeySetusinga
newMasterKey.
7.3.1.3
KEYDATAmustbesetasshowninTable71.KEYDATAiscomposed
ofSecurityDomainImageNumber(SDIN)andChipSerialNumber
(CSN).Theleftmost6bytesoftheSDINandtherightmost4bytes
ofthephysicalidentifierofthecard(CSN)shallbeusedas
KEYDATA.
Table 7-1: KEYDATA
Data Element
KEYDATA
Description
Key derivation data:
SDIN (6 bytes)
CSN (4 bytes) 2
Length
10
Format
Binary
Key Derivation Data is always 10 bytes and can be retrieved using the Get Data
command and is also returned as the first 10 bytes in the response to the Initialize
Update command.
If the CSN does not ensure the uniqueness of KEYDATA across different batches of cards,
then other unique data (e.g. 2 rightmost bytes of IC serial number and 2 bytes of IC batch
identifier) should be used instead.
December 2010
Page 25
7 Data Requirements
Page 26

December 2010

Key Requirements
This section describes the requirements for the support of keys within the Security
Domains to be assigned to the certified TSMs for an Advanced Profile.
For the Basic profile as they are intended to be used by the UICC Issuers which are
certified as TSMs, there are no requirements other than those applying to a certified
TSM.
Requirements Key Requirements
8.1.1.1
ForeachSecurityDomaintobeassignedtoacertifiedTSM,10
SecureChannelProtocol'02'KeySetsshallbegeneratedandbe
loadedasKeySetversions20to29priortosubmissionofthe
producttotheUICCIssuer.
Note:ThedisclosureofakeysetfromUICCmanufacturertoa
TSMshallfollowtherulesdefinedbyeachindividualpayment
system.
8.1.1.2
Thederivationmechanismdescribedinthissectionshallbeused
togeneratethekeys.
AdistinctMasterKey(KMC)shallbeusedtoderiveeachKey
Set.
TheKEYDATAisusedtoderivethe3SecureChannelkeys
(theKENC,theKMACandtheKDEK)fromthecorrespondingMaster
Key.
December 2010
Page 27
8 Key Requirements

Requirements Key Requirements
8.1.1.3
AderivedkeyKENCmustbegeneratedforeachKeySet.TheKENC
willbederivedinthefollowingway:
KENC:= DES3(KMC)[SixleastsignificantbytesoftheKEYDATA||
'F0'||'01']||DES3(KMC)[Sixleastsignificantbytesofthe
KEYDATA||'0F'||'01']
8.1.1.4
AderivedkeyKMACmustbegeneratedforeachKeySet.TheKMAC
KMAC:= DES3(KMC)[SixleastsignificantbytesoftheKEYDATA||
8.1.1.5
AderivedkeyKDEKmustbegeneratedforeachKeySet.TheKDEK
KDEK:= DES3(KMC)[SixleastsignificantbytesoftheKEYDATA||
Page 28
December 2010

Annex A Glossary
This is a glossary of terms and abbreviations used in this specification.
AID
Application Identifier
AM
Authorized Management
API
Application Program Interface
APDU
Application Protocol Data Unit
Application Protocol Data

Unit (APDU)
A packet of data exchanged between a smart card and

an application across a network. A single packet may
actually be transmitted as several packets as well as
having extra information (headers) added for routing.
CASD
Controlling Authority Security Domain
Certified TSM
Certified Trusted Service Manager is an entity that has

been certified by one or more EMVCo payment system
members to manage content and keys related to
contactless mobile payment.
Controlling Authority
Security Domain
CASD is Security Domain that holds the Secure

Element public and private keys (secret if a symmetric
cryptographic scheme is implemented), Secure
Element certificate and the Controlling Authority public
key. An API is provided to enforce the Confidential Key
Loading as defined in GlobalPlatform Card
Specification v2.2 Amendment A.
CSN
Chip Serial Number
DAP
Data Authentication Pattern
DEK
Data Encryption Key
DES
Data Encryption Standard
DGI
Data Grouping Identifier
December 2010
Page 29
Annex A Glossary

DM
Delegated Management
EMV
A global standard for credit and debit payment cards

based on chip card technology. The EMV Integrated
Circuit Card Specifications for Payment Systems are
developed and maintained by EMVCo.
EMVCo
EMVCo LLC is the organization of payment systems

that manages, maintains, and enhances the EMV
specifications. EMVCo is currently operated by
American Express, JCB, MasterCard, and Visa.
ENC
Encryption Key
ETSI
European Telecommunications Standards Institute
Handset
Any mobile consumer device used by the cardholder

for mobile face-to-face payment that is compliant with
the EMVCo Level 1 (see EMV Contactless
Communication Protocol Specification) and Level 2
contactless specifications for payment systems.
IEC
International Electrotechnical Commission
Immutable Persistent
Memory
Memory that can only be read.
ISD
Issuer Security Domain
ISO
International Organization for Standardization
Issuer Security Domain

(ISD)
ISD is the Security Domain representing the issuer of

Secure Element and enforcing its security and
functional policies.
KMC
Master Key for personalisation
KMCID
Identifier of the Master Key for personalisation
Link Platform Operator

(LPO)
LPO is an entity operating an OTA platform providing a

link to UICC.
Logical Channel
Communication interface available between a UICC

and an external entity.
LPO
Link Platform Operator
Page 30
December 2010

Annex A Glossary
MAC
Message Authentication Code
Master Key
A Master Key is a static double length DES key which

is used to derive a Secure Channel Key Set.
Message Authentication
Code (MAC)
MAC is a symmetric cryptographic transformation of

data that provides data origin authentication and data
integrity.
MNO
Mobile Network Operator
Mutable Persistent
Memory
Memory that can be modified
Near Field
Communication (NFC)
A short range contactless proximity technology based

on ISO/IEC 18092, which provides for ISO/IEC 14443
compatible communications and enables wireless
devices to communicate with each other when brought
into close range.
NFC
Near Field Communication
OID
Object Identifier
OTA
Over-the-Air
Over the Air (OTA)
Over-the-air programming is a method of distributing

software to mobile phones and provisioning handsets
with the settings necessary to access messaging
services.
SCP
Secure Channel Protocol
SDIN
Security Domain Image Number
Secure Channel Key Set
A Secure Channel Key Set consists of 3 static double

length DES keys identified by the key set identifier and
used to establish a secure communication between a
UICC and an external entity.
Secure Channel Protocol
A secure communication protocol and set of security

services.
Security Domain
A collection of applications that all trust a common

security token for authentication, authorization, or
session management.
December 2010
Page 31
Annex A Glossary

SIM
Subscriber Identification Module
Subscriber Identification
Module (SIM)/UICC
A SIM is a smart card that securely stores the key

identifying a mobile phone service subscriber, as well
as subscription information, phone numbers,
preferences, etc. It can also be used to securely store
a contactless mobile payment application.
TLV
Tag Length Value
Toolkit Application
Reference (TAR)
Data that identifies an application in the toolkit

mechanisms as defined in ETSI TS 101 220.
TS
Technical Specification
TSM
Trusted Service Manager
TSM hierarchy
Trusted Service Manager hierarchy is herein referred

to a hierarchy of Security Domains within a UICC and
assigned to a TSM.
UICC
Universal Integrated Circuit Card
Universal Integrated
Circuit Card
The physical integrated circuit card which hosts the

USIM and other applications.
VM
Virtual Machine
Page 32
December 2010

Annex A Glossary
<< END OF DOCUMENT >>
December 2010
Page 33

UICC Profiles v1.0 Dec2010 2011112312532964

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UICC Profiles v1.0 Dec2010 2011112312532964

Uploaded by

Copyright:

Available Formats

2011 EMVCo, LLC (EMVCo). All rights reserved.

Any and all uses of these

EMV Profiles of GlobalPlatform UICC

EMV Profiles of GlobalPlatform UICC

EMVCo Contactless Mobile Payment

EMVCo Contactless Mobile Payment

Underlying Standards ...................................................................................2

Notations, Terminology, and Conventions .......................................................5

Contactless Interface Communication ........................................................11

Contact Interface Communication ..............................................................12

Security Principles ............................................................................................13

Payment Applet Executable Load File........................................................13

Other Content Management Commands....................................................14

Ciphered Load File .....................................................................................14

All Profiles .......................................................................................15

Data Requirements ............................................................................................23

Security Domain Image Number.................................................................23

Security Domain AID ..................................................................................24

Key Derivation Data....................................................................................25

EMVCo Contactless Mobile Payment

Key Requirements .............................................................................................27

EMVCo Contactless Mobile Payment

Example 1 of Basic Profile .....................................................................16

EMVCo Contactless Mobile Payment

EMVCo Contactless Mobile Payment

This specification, EMVCo Contactless Mobile Payment EMV Profiles of

EMVCo Contactless Mobile Payment

1.2 Underlying Standards

EMVCo Contactless Mobile Payment

The following standards contain provisions that are referenced in these

2.1 EMV Documents

Describes the minimum functionality required of

Identification cards Integrated circuit(s) cards with

Java Card Virtual Machine

Describes the required behavior of the virtual machine

Defines a flexible and powerful specification for Card

Provides implementation guidelines for mapping a

EMVCo Contactless Mobile Payment

Specifies configuration requirements for implementing

Defines a mechanism for an Application Provider to

ETSI TS 101 220

Defines the administration and the managed allocation

EMVCo Contactless Mobile Payment

Notations, Terminology, and Conventions

nb, nnb, nnnb, ...

Not defined in this specification and/or outside the scope of

Denotes an optional feature

Denotes a mandatory requirement

3 Notations, Terminology, and Conventions

EMVCo Contactless Mobile Payment

Requirements in this document are uniquely numbered with a 4 digit identifier

A requirement may have different numbers in different versions of the specification.

EMVCo Contactless Mobile Payment

This document provides a description of the GlobalPlatform UICC Configuration

EMVCo Contactless Mobile Payment

EMV GlobalPlatform UICC Basic Profile: This implementation requires only an

EMV GlobalPlatform UICC Advanced Profile: This implementation requires

Table 4-1 highlights the main characteristics of the two profiles.

Number of Security Domains with Content

Two (or more)

Additional Security Domain

Additional Logical Channels

EMVCo Contactless Mobile Payment