EMVCo Mobile Contactless – EMV® Profiles of GlobalPlatform UICC Configuration

2010-12-22T00:00:00+00:00 v1.0 Specifications

Mobile

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

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GlobalPlatform UICC Configuration Version 1.0 December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1. 1. 1. 1. 1. 2. 2. 3. 3. 3. 3.3. 4. 4. 5. 5. 6. 6. 6. 6. 6.4.1 6.4.2 6.4. 7. 7. 7. December 2010

http://www.emvco.com/specifications.aspx.

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

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 Figures Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. December 2010 Page v

http://www.emvco.com/specifications.aspx.

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

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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

http://www.emvco.com/specifications.aspx.

1 General 1.2 Underlying Standards EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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.

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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 Java Card Virtual Machine Specification v2.2.2, 15 March 2006 GlobalPlatform Card Specification v2.2, March 2006 GlobalPlatform Mapping Guidelines of existing GlobalPlatform 2.1.1 implementation on 2.2 v1, February 2007 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. December 2010

http://www.emvco.com/specifications.aspx.

2 References 2.2 Standards EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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.

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 3 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 may shall Should Not defined in this specification and/or outside the scope of this specification Denotes an optional feature Denotes a mandatory requirement Denotes a recommendation December 2010

http://www.emvco.com/specifications.aspx.

3 Notations, Terminology, and Conventions 3.3 Conventions EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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.

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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

http://www.emvco.com/specifications.aspx.

4 Functional Requirements 4.1 Profiles EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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 Number of Security Domains with Content Management Profile Basic Advanced One Two (or more) Additional Security Domain Optional Mandatory Additional Logical Channels Mandatory Mandatory

December 2010

http://www.emvco.com/specifications.aspx.

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

http://www.emvco.com/specifications.aspx.

4 Functional Requirements 4.2 Security Domains EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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

http://www.emvco.com/specifications.aspx.

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 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).

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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

http://www.emvco.com/specifications.aspx.

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 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 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

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config version 1.0 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 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.

6.4.2 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

http://www.emvco.com/specifications.aspx.

6 Security Principles 6.4 Security Domains EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config version 1.0 6 Security Principles 6.4 Security Domains 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

http://www.emvco.com/specifications.aspx.

6 Security Principles 6.4 Security Domains EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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.

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config version 1.0 6 Security Principles 6.4 Security Domains 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

http://www.emvco.com/specifications.aspx.

6 Security Principles 6.4 Security Domains EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config version 1.0 6 Security Principles 6.4 Security Domains 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

http://www.emvco.com/specifications.aspx.

6 Security Principles 6.4 Security Domains EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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

http://www.emvco.com/specifications.aspx.

7 Data Requirements 7.2 Security Domain AID EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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.

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config version 1.0 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. Data Element KEYDATA Table 7-1: 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

http://www.emvco.com/specifications.aspx.

7 Data Requirements 7.3 Key Derivation Data EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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

http://www.emvco.com/specifications.aspx.

8 Key Requirements EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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']

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 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

http://www.emvco.com/specifications.aspx.

Annex A Glossary EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 DM EMV EMVCo ENC ETSI Handset IEC Immutable Persistent Memory ISD ISO Issuer Security Domain (ISD) KMC KMCID Link Platform Operator (LPO) Logical Channel LPO 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

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 Annex A Glossary MAC Master Key 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 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. December 2010

http://www.emvco.com/specifications.aspx.

Annex A Glossary EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 SIM Subscriber Identification Module (SIM)/UICC TLV Toolkit Application Reference (TAR) TS TSM TSM hierarchy UICC Universal Integrated Circuit Card VM 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

December 2010

http://www.emvco.com/specifications.aspx.

EMVCo Contactless Mobile Payment EMV Profiles of GP UICC Config v1.0 Annex A Glossary << END OF DOCUMENT >> December 2010

http://www.emvco.com/specifications.aspx.