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

2

3

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

4

5

6

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

7

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



8

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



1

General

This specification, EMVCo Contactless Mobile Payment – EMV Profiles of GlobalPlatform UICC Configuration, defines the requirements for UICCs intended to host a payment system’s 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 EMV®1 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.

1

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



2

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



3

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

The Security Domain with Content Management privilege within the certified TSM hierarchy shall support Secure Channel Protocol '02' implementation option '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 requirement’s number.

Page 6

December 2010



4

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


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



5

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 EMVCo’s standpoint the primary reason for the UICC’s existence is to host the payment system’s 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

The APDU communication shall be able to flow over the contactless protocol as defined in the EMV Contactless Communication Protocol Specification, version 2.0.

5.1.1.2

When the contactless protocol (analog and digital) is implemented directly by the UICC it shall adhere to the EMV Contactless Communication Protocol Specification, version 2.0.

5.1.1.3

In order to determine the source of the communication an implementation shall be able to identify communication received over the contactless interface by interrogating the transfer protocol type (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

The APDU communication shall be able to flow over the basic logical channel as well as logical channels 1, 2, and 3.

5.2.1.2

In order to determine the source of the communication an implementation shall be able to identify communication received from the mobile device by interrogating the transfer protocol type (T=0 or T=1).

Page 12

December 2010



6

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

If the contactless mobile payment application’s executable load file resides in Immutable Persistent Memory or resides in Mutable Persistent Memory prior to delivery of the UICC to the MNO, then the associated Security Domain shall initially be either of the following:  The Issuer Security Domain for the Basic Profile. As the MNO is a certified TSM it can extradite the contactless mobile payment application’s executable load file to another Security Domain as per the rules imposed by the application owner.  A Security Domain with Authorized Management privilege located within a TSM hierarchy for the Advanced Profile. The TSM can extradite the contactless mobile payment application’s executable load file to another Security Domain as per the rules imposed by the application owner.  A certified TSM’s Security Domain with Delegated Management privilege. The TSM can extradite the contactless mobile payment application’s executable load file to another Security Domain as per the rules imposed by the application owner.

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

All Content Management commands performed OTA on a contactless mobile payment application’s executable load file – including post issuance downloading – and its application instances shall be secured using secure channel SCP02 with a security level of '03' (MAC and APDU command data field encryption). Commands may be further encapsulated using SCP80 with or without security.

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 application’s 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

The targeted Application Provider Security Domain of the confidential load operation shall have the Ciphered Load File Data Block privilege and the DAP Verification privilege.

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

6.4.2

A Supplementary Security Domain assigned to an issuing bank or used to secure personalization of a contactless mobile payment application shall support and exclusively use Secure Channel Protocol '02' implementation option '55' for personalization.

Basic Profiles

Requirements – Security Domains, Basic Profiles

6.4.2.1

The Issuer Security Domain shall support Secure Channel Protocol '02' implementation option '55'.

6.4.2.2

The Issuer Security Domain shall be the associated security domain for the executable load files of all contactless mobile payment applications.

6.4.2.3

Instances of the contactless mobile payment application shall be created by the Issuer Security Domain.

December 2010

Page 15




One example of a Basic Profile where the payment application’s 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 bank’s 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

Any Security Domain within a certified TSM hierarchy that has the Content Management privilege shall support Secure Channel Protocol '02' implementation option '55'.

6.4.3.2

A Security Domain with the Content Management privilege shall be the associated security domain for the executable load file of a contactless mobile payment application.

6.4.3.3

A Security Domain with the Authorized Management privilege that is the associated security domain for an executable load file of a contactless mobile payment application shall reject extradition requests from a Security Domain located outside of the certified TSM hierarchy.

6.4.3.4

A Security Domain with the Delegated Management privilege that is the associated security domain for an executable load file of a contactless mobile payment application shall reject extradition 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 TSM’s 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 bank’s 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 TSM’s 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 bank’s 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



7

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

The Security Domain Image Number (SDIN) shall uniquely identify the certified TSM’s Security Domain for each individual UICC.

7.1.1.2

To ensure the uniqueness across UICCs and their manufacturer the SDIN shall consist of the OID (or IIN) of the manufacturer ending (or concatenated) with 4 bytes of a sequential binary digit.

7.1.1.3

The SDIN shall be contained in the ISO/IEC 7816‐6 specified tag of '45' and the DGI of '0070' shall be used by the STORE DATA command to populate this tag.

7.1.1.4

The SDIN shall be retrieved using the GET DATA command.

7.1.1.5

The mechanism to identify the Master Key (KMCID) shall be the combination of the SDIN and the Key Set version. The entity that loads the keys to the certified TSM’s Security Domain and the corresponding certified TSM shall be able to retrieve the identifier of the Master key shared between them.

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

For implementations configured according to an Advanced Profile the AID for a single certified TSM’s Security Domain with the Authorized Management privilege shall be 'A0 00 00 01 51 54 41 00 00 00 00 00 B2 02 10 00'.

7.2.1.2

If more than one such Authorized Management Security Domain needs to be created, then the second to last byte shall be incremented by one for each additional instance; i.e. 'A0 00 00 01 51 54 41 00 00 00 00 00 B2 02 11 00', etc., and up to 'A0 00 00 01 51 54 41 00 00 00 00 00 B2 02 1F 00', for a maximum of 16 possible Authorized Management Security Domains.

7.2.1.3

For implementations configured according to an Advanced Profile the AID for a single certified TSM’s Security Domain with the Delegated Management privilege shall be 'A0 00 00 01 51 54 44 00 00 00 00 00 B2 02 20 00'.

7.2.1.4

If more than one such Delegated Management Security Domain needs to be created, then the second to last byte shall be incremented by one for each additional instance; i.e. 'A0 00 00 01 51 54 44 00 00 00 00 00 B2 02 21 00', etc., and up to 'A0 00 00 01 51 54 41 00 00 00 00 00 B2 02 2F 00', for a maximum of 16 possible instances.

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 TSM’s Security Domain static keys (KENC, KMAC, KDEK).

Requirements – Key Derivation Data

7.3.1.1

This data shall be stored in a tag of 'CF' of the Security Domain. The DGI of '00CF' shall be used by the STORE DATA command to populate the Key Derivation Data to a Security Domain.

7.3.1.2

The certified TSM shall not update the content of the tag 'CF' once it is set by the entity that loaded the 10 Secure Channel Key Sets. However the certified TSM can rotate its assigned Key Set using a new Master Key.

7.3.1.3

KEYDATA must be set as shown in Table 7‐1. KEYDATA is composed of Security Domain Image Number (SDIN) and Chip Serial Number (CSN). The leftmost 6 bytes of the SDIN and the rightmost 4 bytes of the physical identifier of the card (CSN) shall be used as 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.

2

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 7.3 Key Derivation Data

Page 26


December 2010



8

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

For each Security Domain to be assigned to a certified TSM, 10 Secure Channel Protocol '02' Key Sets shall be generated and be loaded as Key Set versions ‘20’ to ‘29’ prior to submission of the product to the UICC Issuer. Note: The disclosure of a key set from UICC manufacturer to a TSM shall follow the rules defined by each individual payment system.

8.1.1.2

The derivation mechanism described in this section shall be used to generate the keys.  A distinct Master Key (KMC) shall be used to derive each Key Set.  The KEYDATA is used to derive the 3 Secure Channel keys (the KENC, the KMAC and the KDEK) from the corresponding Master Key.

December 2010

Page 27


8 Key Requirements


Requirements – Key Requirements

8.1.1.3

A derived key KENC must be generated for each Key Set. The KENC will be derived in the following way: KENC := DES3(KMC)[Six least significant bytes of the KEYDATA || 'F0 ' || '01']|| DES3(KMC)[ Six least significant bytes of the KEYDATA || '0F' || '01']

8.1.1.4

A derived key KMAC must be generated for each Key Set. The KMAC will be derived in the following way: KMAC := DES3(KMC)[Six least significant bytes of the KEYDATA || 'F0' || '02'] || DES3(KMC)[ Six least significant bytes of the KEYDATA || '0F' || '02']

8.1.1.5

A derived key KDEK must be generated for each Key Set. The KDEK will be derived in the following way: KDEK := DES3(KMC)[Six least significant bytes of the KEYDATA || 'F0' || '03'] || DES3(KMC)[ Six least significant bytes of the KEYDATA || '0F' || '03']

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

Recommend Documents