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 1.2 1.3 1.4 2 Scope............................................................................................................1 Underlying Standards ...................................................................................2 Audience.......................................................................................................2 Overview.......................................................................................................2
References ...........................................................................................................3 2.1 2.2 EMV Documents...........................................................................................3 Standards .....................................................................................................3
Notations, Terminology, and Conventions .......................................................5 3.1 3.2 3.3 Notations.......................................................................................................5 Terminology ..................................................................................................5 Conventions..................................................................................................6 3.3.1 Requirement Numbering...................................................................6
Functional Requirements....................................................................................7 4.1 4.2 Profiles..........................................................................................................8 Security Domains..........................................................................................9
Communication Interface..................................................................................11 5.1 5.2 Contactless Interface Communication ........................................................11 Contact Interface Communication ..............................................................12
Security Principles ............................................................................................13 6.1 6.2 6.3 6.4 Payment Applet Executable Load File........................................................13 Other Content Management Commands....................................................14 Ciphered Load File .....................................................................................14 Security Domains........................................................................................15 6.4.1 6.4.2 6.4.3 All Profiles .......................................................................................15 Basic Profiles ..................................................................................15 Advanced Profiles ...........................................................................18
Data Requirements ............................................................................................23 7.1 7.2 7.3 Security Domain Image Number.................................................................23 Security Domain AID ..................................................................................24 Key Derivation Data....................................................................................25
December 2010
Page iii
Key Requirements .............................................................................................27 Glossary ................................................................................................29
Annex A
Page iv
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.
1
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 Java Card Virtual Machine Specification v2.2.2, 15 March 2006 Identification cards Integrated circuit(s) cards with contacts Part 6: Inter-industry data elements. 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. 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. 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.
GlobalPlatform Card Specification v2.2, March 2006 GlobalPlatform Mapping Guidelines of existing GlobalPlatform 2.1.1 implementation on 2.2 v1, February 2007
December 2010
Page 3
2 References 2.2 Standards
GlobalPlatform UICC Configuration v1, 28 October 2008 GlobalPlatform Card Confidential Card Content Management Card Specification v2.2Amendment A v1.0 ETSI TS 101 220 Smart Cards; ETSI numbering system for telecommunication application providers
Specifies configuration requirements for implementing GlobalPlatform Specifications on the UICC platform specified in ETSI specifications. 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.
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' AND nb, nnb, nnnb, ... xx 16 hexadecimal characters Logical AND Binary values Any value
3.2 Terminology
proprietary Not defined in this specification and/or outside the scope of this specification Denotes an optional feature Denotes a mandatory requirement Denotes a recommendation
may shall Should
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 Profile Advanced Two (or more)
Functionality Number of Security Domains with Content Management Additional Security Domain Additional Logical Channels One
Basic
Optional Mandatory
Mandatory Mandatory
Page 8
December 2010
EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config version 1.0
4 Functional Requirements 4.2 Security Domains
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
4 Functional Requirements 4.2 Security Domains
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. Whenthecontactlessprotocol(analoganddigital)isimplemented directlybytheUICCitshalladheretotheEMVContactless CommunicationProtocolSpecification,version2.0. Inordertodeterminethesourceofthecommunicationan implementationshallbeabletoidentifycommunicationreceived overthecontactlessinterfacebyinterrogatingthetransfer protocoltype(T=CL).
5.1.1.2
5.1.1.3
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 5.2.1.2
TheAPDUcommunicationshallbeabletoflowoverthebasic logicalchannelaswellaslogicalchannels1,2,and3. 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
ThetargetedApplicationProviderSecurityDomainofthe confidentialloadoperationshallhavetheCipheredLoadFileData BlockprivilegeandtheDAPVerificationprivilege.
Page 14
December 2010
6 Security Principles 6.4 Security Domains
6.4 Security Domains

6.4.1 All Profiles
Requirements Security Domains, All Profiles
6.4.1.1
ASupplementarySecurityDomainassignedtoanissuingbankor usedtosecurepersonalizationofacontactlessmobilepayment applicationshallsupportandexclusivelyuseSecureChannel Protocol'02'implementationoption'55'forpersonalization.
6.4.2
Basic Profiles
Requirements Security Domains, Basic Profiles
6.4.2.1 6.4.2.2
TheIssuerSecurityDomainshallsupportSecureChannelProtocol '02'implementationoption'55'. TheIssuerSecurityDomainshallbetheassociatedsecuritydomain fortheexecutableloadfilesofallcontactlessmobilepayment applications. Instancesofthecontactlessmobilepaymentapplicationshallbe createdbytheIssuerSecurityDomain.
6.4.2.3
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'. ASecurityDomainwiththeContentManagementprivilegeshall betheassociatedsecuritydomainfortheexecutableloadfileofa contactlessmobilepaymentapplication. ASecurityDomainwiththeAuthorizedManagementprivilegethat istheassociatedsecuritydomainforanexecutableloadfileofa contactlessmobilepaymentapplicationshallrejectextradition requestsfromaSecurityDomainlocatedoutsideofthecertified TSMhierarchy. ASecurityDomainwiththeDelegatedManagementprivilegethat istheassociatedsecuritydomainforanexecutableloadfileofa contactlessmobilepaymentapplicationshallrejectextradition requests.
6.4.3.2
6.4.3.3
6.4.3.4
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. The instances of the contactless mobile payment application are created and 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. The instances of the contactless mobile payment application are created and 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 7.1.1.2
TheSecurityDomainImageNumber(SDIN)shalluniquelyidentify thecertifiedTSMsSecurityDomainforeachindividualUICC. ToensuretheuniquenessacrossUICCsandtheirmanufacturerthe SDINshallconsistoftheOID(orIIN)ofthemanufacturerending (orconcatenated)with4bytesofasequentialbinarydigit. TheSDINshallbecontainedintheISO/IEC78166specifiedtagof '45'andtheDGIof'0070'shallbeusedbytheSTOREDATA commandtopopulatethistag. TheSDINshallberetrievedusingtheGETDATAcommand. ThemechanismtoidentifytheMasterKey(KMCID)shallbethe combinationoftheSDINandtheKeySetversion.Theentitythat loadsthekeystothecertifiedTSMsSecurityDomainandthe correspondingcertifiedTSMshallbeabletoretrievetheidentifier oftheMasterkeysharedbetweenthem.
7.1.1.3
7.1.1.4 7.1.1.5
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'. IfmorethanonesuchAuthorizedManagementSecurityDomain needstobecreated,thenthesecondtolastbyteshallbe incrementedbyoneforeachadditionalinstance;i.e.'A0000001 5154410000000000B2021100',etc.,andupto'A0000001 5154410000000000B2021F00',foramaximumof16 possibleAuthorizedManagementSecurityDomains. ForimplementationsconfiguredaccordingtoanAdvancedProfile theAIDforasinglecertifiedTSMsSecurityDomainwiththe DelegatedManagementprivilegeshallbe'A000000151544400 00000000B2022000'. IfmorethanonesuchDelegatedManagementSecurityDomain needstobecreated,thenthesecondtolastbyteshallbe incrementedbyoneforeachadditionalinstance;i.e.'A0000001 5154440000000000B2022100',etc.,andupto'A0000001 5154410000000000B2022F00',foramaximumof16 possibleinstances.
7.2.1.2
7.2.1.3
7.2.1.4
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
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. ThecertifiedTSMshallnotupdatethecontentofthetag'CF'once itissetbytheentitythatloadedthe10SecureChannelKeySets. HoweverthecertifiedTSMcanrotateitsassignedKeySetusinga newMasterKey. KEYDATAmustbesetasshowninTable71.KEYDATAiscomposed ofSecurityDomainImageNumber(SDIN)andChipSerialNumber (CSN).Theleftmost6bytesoftheSDINandtherightmost4bytes ofthephysicalidentifierofthecard(CSN)shallbeusedas KEYDATA.
Table 7-1: KEYDATA
7.3.1.2
7.3.1.3
Data Element KEYDATA
Description Key derivation data: SDIN (6 bytes) CSN (4 bytes) 2 10
Length
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.
2
December 2010
Page 25
7 Data Requirements 7.3 Key Derivation Data
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 willbederivedinthefollowingway: KMAC:= DES3(KMC)[SixleastsignificantbytesoftheKEYDATA|| 'F0'||'02']||DES3(KMC)[Sixleastsignificantbytesofthe KEYDATA||'0F'||'02']
8.1.1.5
AderivedkeyKDEKmustbegeneratedforeachKeySet.TheKDEK willbederivedinthefollowingway: KDEK:= DES3(KMC)[SixleastsignificantbytesoftheKEYDATA|| 'F0'||'03']||DES3(KMC)[Sixleastsignificantbytesofthe KEYDATA||'0F'||'03']
Page 28
December 2010
Annex A Glossary
This is a glossary of terms and abbreviations used in this specification.
AID AM API APDU Application Protocol Data Unit (APDU)
Application Identifier Authorized Management Application Program Interface Application Protocol Data Unit 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. Controlling Authority Security Domain 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. 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. Chip Serial Number Data Authentication Pattern Data Encryption Key Data Encryption Standard Data Grouping Identifier
CASD Certified TSM
Controlling Authority Security Domain
CSN DAP DEK DES DGI
December 2010
Page 29
Annex A Glossary
DM EMV
Delegated Management 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 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. Encryption Key European Telecommunications Standards Institute 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. International Electrotechnical Commission Memory that can only be read. Issuer Security Domain International Organization for Standardization ISD is the Security Domain representing the issuer of Secure Element and enforcing its security and functional policies. Master Key for personalisation Identifier of the Master Key for personalisation LPO is an entity operating an OTA platform providing a link to UICC. Communication interface available between a UICC and an external entity. Link Platform Operator
EMVCo
ENC ETSI Handset
IEC Immutable Persistent Memory ISD ISO Issuer Security Domain (ISD)
KMC KMCID Link Platform Operator (LPO) Logical Channel
LPO
Page 30
December 2010
Annex A Glossary
MAC Master Key
Message Authentication Code A Master Key is a static double length DES key which is used to derive a Secure Channel Key Set. MAC is a symmetric cryptographic transformation of data that provides data origin authentication and data integrity. Mobile Network Operator Memory that can be modified 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. Near Field Communication Object Identifier Over-the-Air Over-the-air programming is a method of distributing software to mobile phones and provisioning handsets with the settings necessary to access messaging services. Secure Channel Protocol Security Domain Image Number 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. A secure communication protocol and set of security services. A collection of applications that all trust a common security token for authentication, authorization, or session management.
Message Authentication Code (MAC)
MNO Mutable Persistent Memory Near Field Communication (NFC)
NFC OID OTA Over the Air (OTA)
SCP SDIN Secure Channel Key Set
Secure Channel Protocol
Security Domain
December 2010
Page 31
Annex A Glossary
SIM Subscriber Identification Module (SIM)/UICC
Subscriber Identification Module 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. Tag Length Value Data that identifies an application in the toolkit mechanisms as defined in ETSI TS 101 220. Technical Specification Trusted Service Manager Trusted Service Manager hierarchy is herein referred to a hierarchy of Security Domains within a UICC and assigned to a TSM. Universal Integrated Circuit Card The physical integrated circuit card which hosts the USIM and other applications. Virtual Machine
TLV Toolkit Application Reference (TAR) TS TSM TSM hierarchy
UICC Universal Integrated Circuit Card VM
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.

EMV Profiles of GlobalPlatform UICC Configuration

Version 1.0 December 2010

EMV Profiles of GlobalPlatform UICC Configuration

Version 1.0 December 2010

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

Key Requirements .............................................................................................27 Glossary ................................................................................................29

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

1 General 1.2 Underlying Standards

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

1.2 Underlying Standards

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

2.1 EMV Documents

EMV Contactless Communication Protocol Specification, v2.0, August 2007

2 References 2.2 Standards

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

Notations, Terminology, and Conventions

may shall Should

3 Notations, Terminology, and Conventions 3.3 Conventions

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

TheSecurityDomainwithContentManagementprivilegewithinthe certifiedTSMhierarchyshallsupportSecureChannelProtocol'02' implementationoption'55'.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

4 Functional Requirements 4.1 Profiles

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

4 Functional Requirements 4.2 Security Domains

4.2 Security Domains

4 Functional Requirements 4.2 Security Domains

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

5.1 Contactless Interface Communication

Requirements Contactless Interface Communication

5 Communication Interface 5.2 Contact Interface Communication

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

5.2 Contact Interface Communication

TheAPDUcommunicationshallbeabletoflowoverthebasic logicalchannelaswellaslogicalchannels1,2,and3. Inordertodeterminethesourceofthecommunicationan implementationshallbeabletoidentifycommunicationreceived fromthemobiledevicebyinterrogatingthetransferprotocoltype (T=0orT=1).

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

6.1 Payment Applet Executable Load File

6 Security Principles 6.2 Other Content Management Commands

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

6.2 Other Content Management Commands

6.3 Ciphered Load File

Requirements Ciphered Load File

ThetargetedApplicationProviderSecurityDomainofthe confidentialloadoperationshallhavetheCipheredLoadFileData BlockprivilegeandtheDAPVerificationprivilege.

6 Security Principles 6.4 Security Domains

6.4 Security Domains

Requirements Security Domains, All Profiles

ASupplementarySecurityDomainassignedtoanissuingbankor usedtosecurepersonalizationofacontactlessmobilepayment applicationshallsupportandexclusivelyuseSecureChannel Protocol'02'implementationoption'55'forpersonalization.

Requirements Security Domains, Basic Profiles

6 Security Principles 6.4 Security Domains

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

6 Security Principles 6.4 Security Domains

6 Security Principles 6.4 Security Domains

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

Requirements Security Domains, Advanced Profiles

6 Security Principles 6.4 Security Domains

Authorized Management Advanced Profile

6 Security Principles 6.4 Security Domains

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0