mobile NFC technical guidelines

mobile NFC technical guidelines Version 2.0 November 2007

Disclaimer and Legal Notices Every care has been taken in the preparation of this report to ensure that the information provided is accurate, factual and correct to the best of our knowledge. The GSMA accepts no liability for any loss or damage or unforeseen consequential loss or damage arising from the use of the information contained within this document. All Rights Reserved. No part of this document can be copied, shared, redistributed, transmitted, displayed in the public domain, stored or displayed on any internal or external company or private network or electronic retrieval system, nor reprinted, republished or reconstituted in any way without the express permission of the GSMA. 2007, GSMA. GSM and the GSM logo are the registered property of the GSM Association. i 2007, GSMA. All Rights Reserved

Table of Contents SECTION PAGE 1. EXECUTIVE SUMMARY 1 2. INTRODUCTION 8 2.1 External Reference Documents 8 2.1 Project Deliverable Documents 9 3. PURPOSE OF THE DOCUMENT 10 3.1 Document Structure 11 4. PROJECT DEFINITION 12 4.1 GSMA 12 4.2 Stakeholders 12 4.3 Approach 12 5. HOST CONTROLLER INTERFACE 14 5.1 Support of contactless systems 14 5.2 Selection of the secure element in a multiple SE architecture 15 5.3 Compatibility between ETSI HCI specification and NFC-Forum HCI specification 18 6. UICC RUN-TIME ENVIRONMENT 19 6.1 Introduction 19 6.2 UICC environment 20 6.3 Java Card API 24 6.4 User Interface 26 7. OTA PROVISIONING 29 7.1 OTA Infrastructure description 29 7.2 Technical issues 38 7.3 Proprietary system issues 45 2007, GSMA. All Rights Reserved ii

8. MOBILE NFC DEVICE SECURITY 47 8.1 Introduction: Security considerations 47 8.2 Secure display on the Screen and secure entry on the Keyboard 49 8.3 User Interface Authentication 49 8.4 Enhance security by using OTA capability 50 8.5 NFC Application Approval 51 9. ERRATA TO MOBILE NFC TECHNICAL GUIDELINES, VERSION 1.0 (Released April 2007) 52 10. ACRONYMS 53 11. APPENDIX A: NFC TECHNICAL GUIDELINES VERSION 1.0 WHITE PAPER 55 TABLE OF FIGURES FIGURE 1: Reference OTA Provisioning Architecture 4 FIGURE 2: Option 1 Single SE visible to reader at any given time 15 FIGURE 3: Option 2.1 - Multiple SEs visible to reader as a merged SE 16 FIGURE 4: Option 2.2 - Multiple SEs visible to reader as multiple SEs 17 FIGURE 5: Generic overall transaction time in a contactless interaction 20 FIGURE 6: Overall transaction time in a mobile NFC device 21 FIGURE 7: UICC architecture 23 FIGURE 8: mobile NFC device architecture overview 26 FIGURE 9: Reference OTA Provisioning Architecture 29 FIGURE 10: Initialisation Sequence Diagram 33 FIGURE 11: OTA NFC Service Delivery 34 FIGURE 12: OTA Functional Separation 35 FIGURE 13: Issuer Centric Model 36 FIGURE 14: TSM Centric Model 37 FIGURE 15: Mobile NFC Device Security Architecture 48 iii 2007, GSMA. All Rights Reserved

Section 1: Executive Summary Twenty of the largest Mobile Network Operators (MNOs) have been working together, in a GSM Association (GSMA) initiative, to develop a common vision on Mobile Near Field Communications (NFC) services, promoting the development of a stable and efficient ecosystem and to prevent market fragmentation. In February 2007, the GSMA NFC initiative released a Mobile NFC Services White Paper [1]. That white paper was produced from an analysis of the mobile NFC ecosystem and related business requirements. In April 2007, the GSMA NFC initiative released a Mobile NFC Technical Guidelines White Paper version 1.0 [2]. That white paper was produced from an analysis of:. The Universal Integrated Circuit Card (UICC) to NFC Chip interface (lower Open Systems Interconnection [OSI] layers). The Mobile to Contactless reader interface. The Multi-application UICC framework In this Mobile NFC Technical Guidelines White Paper version 2.0 MNOs have performed an analysis of:. The UICC to NFC Chip interface (Host Controller Interface [HCI]);. UICC Run-Time Environment;. Over-The-Air (OTA) Provisioning;. Mobile NFC Device Security This white paper presents the results of the above analysis as a series of technical guidelines intended to support NFC standardisation and technology implementation activities. These technical guidelines are provided as input to standardisation bodies and fora, to support their standardisation of NFC technology. This white paper should also provide valuable information to other third parties who are defining and developing in their roles within the Mobile NFC ecosystem. These guidelines are intended to provide the MNO vision for mobile NFC solutions, identifying technical options and providing recommendations. The participating MNOs expect that the detailed requirements and specifications will be either developed by the relevant standardisation bodies and / or issued by MNOs as required to meet their specific market and deployment requirements. These guidelines are not intended to be used by other parties as final technical requirements - that is not the purpose of this white paper. 2007, GSMA. All Rights Reserved 1

The use of 'shall' and 'must' do not imply the content should be interpreted as final specifications or requirements, which are the responsibilities of standardisation bodies and individual MNOs requirements. The technical guidelines presented in this white paper have been prepared with information that was available as at September 2007. UICC to NFC Chip Interface (Host Controller Interface [HCI]) Support of contactless systems It is recommended that the technical solution currently under review in the European Telecommunications Standards Institute Technical Committee Smart Card Platform (ETSI TC SCP) the reference of which is: "UICC-CLF interface: Host Controller Interface"(draft in progress) is adopted. This technical solution is compatible with any standard system (i.e. system compliant with layers 2, 3 and 4 of ISO/14443 type A and type B). This technical solution enables the support of proprietary protocols based on type B as well. Secure Element (SE) selection It is recommended that only one secure element is made visible to the contactless reader at any given time. Furthermore, it is recommended that the SE selection is under the user s control hence the SE selection has to be done manually by the user. Compatibility between ETSI HCI specification and NFC-Forum HCI specification It is highly recommended that the NFC Forum specification is defined in such a way that no compatibility issues arise when the NFC Forum specification is implemented in addition to the ETSI specification. UICC Run-Time Environment UICC Environment a) Performance MNOs recommend the following:. Mobile NFC device manufacturers should comply with a maximum transaction time delay caused by introducing the mobile NFC device into the system. This maximum transaction time delay could be different for each contactless mode (Java Card mode, legacy mode, NFC peer-to-peer mode etc). The development of a set of reference UICC Java Card applications to help certify and evaluate products. Define a reference reader. The control of reader sleep modes should be adapted to the polling loop algorithm in the mobile phone to reduce delay. 2 2007, GSMA. All Rights Reserved

b) Memory management It is recommended that the mechanisms defined in the Global Platform (GP) version 2.1 specifications for memory control during installation and resource allocation during runtime (quota) are adopted. c) Multi-tasking. The UICC shall support the concurrent execution of multiple applications (multi-tasking). Multi-tasking should be pre-emptive.. Telecom applications (e.g. Universal Subscriber Identity Module [USIM]) must be handled with adequate priority. The Card Operating System (CardOS) shall be able to handle concurrent events on all available UICC interfaces. The CardOS shall support multiple logical channels on each interface. Java Card Application Programmer Interface (API) Although Java Card specification release 7 defines how a Java card applet can start a Java midlet in the mobile phone, this interface should be extended to include parameters for the Java midlet. Furthermore, the mobile NFC device needs to ensure that it starts the application which the Java card applet intended to start so as to avoid phishing attacks. Java Card applets should be able to access telecommunication network functions, such as:. Short Messaging Service (SMS). Internet Protocol (IP). Phone Calls For efficient network access a high speed interface is recommended (e.g. Bearer Independent Protocol [BIP], Universal Serial Bus [USB] etc) In order to have a common set of APIs for the UICC, it is recommended that UICC ETSI specifies all contactless related APIs for mobile NFC services. Those APIs should address the following topics:. Control the NFC controller and its modes. User Interface. Smart Card Web Server/Browser. Control and communication of Java Midlets. Telecommunication Network access. Access to legacy contactless technologies such as Mifare or Felica. Security mechanisms to limit access of Java Card Applets to different sets of APIs It is recommended that different levels of certification are defined for Java Card Applets dependent upon the granted access rights of those applets. For example detailed certification rules are required for Java Card applets which require full network access functionality. 2007, GSMA. All Rights Reserved 3

OTA Provisioning Figure 1 presents the high level architecture for OTA provisioning: Figure 1 : Reference OTA Provisioning Architecture The following recommendations are made regarding OTA provisioning: Security Domain (SD) creation UICCs shall support SD creation as specified by Global Platform including SD installation, and personalisation using the Issuer Security Domain (ISD). The install commands addressed to the oncard SD shall have the same format as the GP Install commands (Install for Install, make selectable, for personalisation etc) addressed to any on-card application. OTA infrastructure and UICCs should also support the same mechanisms after the UICC is manufactured in order to create new SDs via OTA. 4 2007, GSMA. All Rights Reserved

Applet issuance It is recommended to use standard GP commands to install Applets. Update of Applet code shall not be permitted by the Applet. If the code is updated, then it is considered as a new version of the application and thus needs to go through certification, registration and installation processes. Operation of Applet (like Ticket issuance, counter reset etc) is not an Applet code update, and so it can be performed independently of the MNO. Transport protocol For Applet management (lock/unlock) or personalisation, the most relevant bearer is the SMS. For Applet download, Bearer Independent Protocol Card Application Toolkit Transmission Protocol (BIP CAT_TP) or Transmission Control Protocol/Internet Protocol (TCP/IP) is recommended since it is standardised, faster and more reliable than SMS, and does not require any Midlet proxy in the Mobile phone. OTA platforms shall support at least SMS and BIP (CAT_TP or TCP/IP) bearers. Token mechanism In a Trusted Services Manager (TSM) Centric model, where the TSM has Delegated Management rather than Authorised Management privileges (see below), the TSM shall be able to ask for a Token from the MNO OTA platforms prior to any operation requiring a Token. The MNO must decide on the list of operations requiring a Token and must be able to deliver these tokens to the TSM through its OTA platform. Data Authentication Pattern (DAP) mechanism In Issuer Centric model (excluding Confidential loading), MNO OTA platform shall be able to ask for DAP from the TSM or Service Provider (SP) prior any installation of Applet under SP SD if required by the SP. Authorised management MNOs do not recommend implementing Authorised Management unless there is a high trust relationship between the MNO and a TSM. In the case where there is not such a trust relationship, MNOs recommend to use the Delegated Management to load applications that are required by the SP. Applet personalisation The most standard mechanisms, GP based, are recommended for applet personalisation. It is also recommended to have an interoperable personalisation method, meaning that for a given 2007, GSMA. All Rights Reserved 5

NFC Applet, it will use the same personalisation commands, whatever the UICC on which it is installed. Mifare Where Mifare emulation is supported, the UICC shall be fully compliant with Global Platform and ETSI standards so that any OTA platform compliant with these standards can manage Mifare applications. A Mifare Application running in the UICC shall have the possibility to be hosted and run under any Security Domain, in either the Issuer Centric model or TSM centric model. Felica Further study and investigation are recommended for the FeliCa system to be compliant with GP and ETSI standards. Mobile NFC Device Security The following recommendations are made regarding mobile NFC device security: Secure display on the Screen and secure entry on the Keyboard In the case where the mobile NFC device manages the presentation of information to the user (via the mobile NFC device keyboard and screen), MNOs recommend equipment manufacturers and application developers to investigate methods which would ensure data integrity and nonrepudiation of the information (i.e. the screen and keyboard device drivers and hardware should be secure). User Interface Authentication Only applications authorised and authenticated by the UICC should be allowed to exchange information with the UICC. Mobile Information Device Profile (MIDP) related Operator certificates should be stored in the UICC and should be managed by the handset s Java Virtual Machine as specified in MIDP2.1 specification. Enhance security by using the Handset connectivity MNOs recommend that NFC Service providers make full use of the enhanced security benefits which can be provided leveraging the OTA connectivity inherent with mobile NFC devices (i.e. mobile phones), such as:. Remote Application Management (Activation/ Inhibition/ Lock/ Deletion/ Update). Remote update of security algorithms. Information Upload from the mobile NFC device to the SP 6 2007, GSMA. All Rights Reserved

NFC Application Approval MNOs make the following recommendations for any NFC application developed to operate within any Mobile NFC device: 1. The NFC application should be assessed and approved by the NFC Service provider or an agreed entity. 2. The Application should also be assessed and approved by MNOs or an agreed entity (e.g. the Trusted Services Manager [TSM]). 2007, GSMA. All Rights Reserved 7

Section 2: Introduction Twenty of the worlds largest Mobile Network Operators (MNOs), have been working together, in a GSMA initiative, to create and define a global approach to enable Near Field Communications (NFC) services on mobile phones. This initiative will serve to answer key customer requirements for new NFC services on mobile phones. Furthermore, it aims to provide a common MNO viewpoint, which is key to enable the development of a new market and to prevent market fragmentation. In February 2007, the GSMA NFC initiative released a Mobile NFC Services White Paper [1]. That white paper was produced from an analysis of the mobile NFC ecosystem and related business requirements. In April 2007, the GSMA NFC initiative released a Mobile NFC Technical Guidelines White Paper version 1.0 [2]. That white paper was produced from an analysis of:. The Universal Integrated Circuit Card (UICC) to NFC Chip interface (lower Open Systems Interconnection [OSI] layers). The Mobile to Contactless reader interface. The Multi-application UICC framework It is assumed that the reader has familiarity with Smart Card terminology. 2.1 External Reference Documents # Document Title Document Reference E1 Global Platform Card Specification 2.1.1 Global Platform Card Specification 2.1.1, March 2003 E2 Confidential Card Content Management v0.5 Confidential Card Content Management v0.5, GPC_SPE_006, April 2007 8 2007, GSMA. All Rights Reserved

2.2 Project Deliverable Documents # Document Title Document Reference 1 GSMA Mobile NFC Services White Paper 2 3 GSMA Mobile NFC Technical Guidelines White Paper V1.0 GSMA Mobile NFC Technical Guidelines White Paper V2.0 GSMA_153_WP510_001, February 2007. (Available for download from: http://www.gsmworld.com/news/press_2 007/index.shtml) GSMA_153_WP510_002, April 2007. (Available for download from: http://www.gsmworld.com/news/press_2 007/press07_34.shtml) GSMA_153_WP510_003, August 2007 (Available for download from: http://www.gsmworld.com/news/press_2 007/) 2007, GSMA. All Rights Reserved 9

Section 3: Purpose of the Document This white paper is produced as a result of technical analysis performed by the MNOs in the GSMA initiative regarding:. UICC to NFC Chip interface (HCI);. UICC Run-Time Environment;. Over-The-Air (OTA) Provisioning;. Mobile NFC Device Security This version 2.0 of the GSMA Mobile NFC Technical Guidelines White Paper serves to augment the version 1.0 of the White Paper [2]. The purpose of this document also applies to the version 1.0 of the White Paper. This white paper presents a series of technical guidelines intended to support NFC standardisation and technology implementation activities. These technical guidelines are provided as input to standardisation bodies and fora, to support their standardisation of NFC technology. This white paper should also provide valuable information to other third parties who are defining and developing in their roles within the Mobile NFC ecosystem. These guidelines are intended to provide the MNO vision for mobile NFC solutions, identifying technical options and providing recommendations. The participating MNOs expect that the detailed requirements and specifications will be either developed by the relevant standardisation bodies and / or issued by MNOs as required to meet their specific market and deployment requirements. These guidelines are not intended to be used by other parties as final technical requirements - that is not the purpose of this white paper. The use of 'shall' and 'must' do not imply the content should be interpreted as final specifications or requirements, which are the responsibilities of standardisation bodies and individual MNOs requirements. The GSMA NFC initiative promotes and recommends the UICC (Universal Integrated Circuit Card) as the most appropriate NFC 'Secure Element' in mobile phones, offering many unique advantages for mobile users, including: universal deployment, portability, remote management, standards based solution and a long operational lifecycle. The scope of this White Paper is focussed on an NFC architecture where the UICC is the preferred Secure Element. This initiative acknowledges however, that other architectures exist and have already been deployed. 10 2007, GSMA. All Rights Reserved

3.1 Document Structure This version of the white paper is structured as follows:. Host Controller Interface (see section 5). UICC Run-Time Environment (see section 6). OTA Provisioning (see section 7). Mobile NFC Device Security (see section 8) 2007, GSMA. All Rights Reserved 11

Section 4: Project Definition 4.1 GSMA The GSMA is the global trade association representing over 721 GSM mobile phone operators across 218 countries of the world. The primary goals of the GSMA are to ensure mobile and wireless services work globally and are easily accessible, enhancing their value to individual customers and national economies, while creating new business opportunities for operators and their suppliers. Hence the GSMA provides the ideal forum to represent the MNO community for the purposes of defining mobile NFC services. MNO collaboration in this area ensures a consistent approach in the development of mobile NFC services among mobile operators and other involved parties in the industry. This promotes interoperability, leading to standardisation on a global scale and prevents market fragmentation. 4.2 Stakeholders Twenty of the largest MNOs are working together to develop a common vision on mobile NFC services, promoting MNO capabilities and value add for the mobile NFC ecosystem. The MNOs involved in this mobile NFC initiative are: AT&T, Bouygues Telecom, Elisa, KPN, KTF, Mobilkom Austria, NTT DoCoMo Inc., Orange, Rogers, SFR, SKTelecom, Telefonica Móviles España, Telenor Mobile, TeliaSonera, Telecom Italia Mobile, TMN, Turkcell, Vodafone and 3. They represent about 45% of the worldwide GSM market, which addresses over 800 million customers. 4.3 Approach The following approach has been adopted in this project: 1. Analyse the key mobile NFC use cases 2. Analyse the mobile NFC ecosystem and perform an end-to-end value chain analysis 3. Analyse the MNO s role within this ecosystem 4. Extract the mobile NFC business requirements needed to make mobile NFC a success and deliver value to all entities in the value chain 5. Assess the impact of the business requirements to the standards relevant to the NFC ecosystem (specifically European Telecommunications Standards Institute (ETSI), Global Platform (GP) and the NFC forum) 12 2007, GSMA. All Rights Reserved

Several Work Packages (WPs) have been defined in this project. These are summarised below:. Mobile NFC Use Case Analysis and Business Requirements. Architecture Definition UICC-NFC Chip (Lower OSI layers). Architecture Definition Mobile-Reader. Architecture Definition Multi-application UICC framework. Architecture Definition HCI. Architecture Definition UICC run-time environment. Architecture Definition OTA provisioning. Architecture Definition Mobile NFC Device Security 2007, GSMA. All Rights Reserved 13

Section 5: Host Controller Interface The UICC Contactless Front-end (CLF) logical Interface defines the protocol on top of the data link layer. It defines how the messages are transmitted between the UICC and the CLF. This logical interface is also extended to enable the exchange of messages between the UICC or the CLF and the mobile phone. It is theoretically independent from the underlying interface which carries the messages (physical and data link interface). In the context of the GSMA NFC Project, it is assumed that the Single Wire Protocol (SWP) is the physical interface linking the UICC and the CLF. In order to fulfill the business requirements defined by the GSMA NFC project, the interface between the CLF and the UICC shall enable the support of most of the legacy contactless infrastructure. This targeted infrastructure is composed of standard systems (compliant with ISO/14443 type A & B) and proprietary system extensions referred to as Mifare (NXP product) and proprietary protocols based on type B. It is expected that both physical and logical interfaces are flexible enough to enable the support of FeliCa in the UICC. 5.1 Support of contactless systems This issue relates to card emulation mode. The interface between the UICC and the CLF shall support the aforementioned contactless systems. This interface combines the physical link and the logical interface protocol 5.1.1 Solution A technical solution is under review in ETSI TC SCP the reference of which is: "UICC-CLF interface: Host Controller Interface"(draft in progress). This technical solution is compatible with any standard system (i.e. system compliant with layers 2, 3 and 4 of ISO/14443 type A and type B). This technical solution enables the support of proprietary protocols based on type B as well. The physical data link (i.e. Single Wire Protocol) is under review in ETSI the reference of which is: "UICC-CLF interface: physical and logical characteristics"(draft in progress). In this document, chapter entitled CLT Protocol defines a special operation mode enabling the support of Mifare system. 5.1.2 Recommendation The recommended solution shall be based on the aforementioned solution. 14 2007, GSMA. All Rights Reserved

5.2 Selection of the secure element in a multiple SE architecture The GSMA NFC project recommends the UICC as the most appropriate secure element (SE) in mobile phones. It is foreseen that other secure elements (removable and non removable) may be implemented in mobile phones. As a consequence, applications may be hosted in secure elements other than the UICC. The selection of the secure element hosting the targeted application shall be solved. This case only applies in card emulation mode. 5.2.1 Solutions Three solutions are considered: Option 1: Only one secure element is made visible to the contactless reader at a given time (as shown in Figure 2). In order to ensure the user's awareness of which SE issuer's service portfolio is currently used, the user has to know which physical SE is selected. The SE selection is under the user s control, hence the SE selection has to be done manually by the user. At the manufacturing time, a default SE is selected depending on the buyer's requirements (e.g. operators will ask for the UICC as the default selected SE, other mobile buyers may require other settings). When the contactless transaction occurs, the system looks for the targeted application in the selected secure element. It should be noted that if the application is not hosted in the selected SE, the contactless transaction will fail (since the reader cannot find the application). Mobile Phone Choose the card (SE) 1. SIM CARD 2. SD CARD 3. Other CARDS SD Card Select User action Choice of the SE Other SE Figure 2 : Option 1 Single SE visible to reader at any given time 2007, GSMA. All Rights Reserved 15

Option 2: From the end-user's standpoint, there is no distinction between the secure elements and the services are aggregated in a uniform manner. The search of the targeted application is carried out on all secure elements. Two options are possible: Option 2.1: The secure elements are made visible to the contactless reader as one merged secure element (as shown in Figure 3). The whole contactless protocol is handled by the CLF for all the connected secure elements and according to the targeted application, the selection of the SE is automatically handled by the NFC system embedded in the mobile phone (e.g. by implementing a software component in the CLF). There is no user action whichever the secure element (hosting the application) is. This solution is based on the application selection command sent by the contactless reader. A table indicates which SE hosts the application; this mechanism is based on the application identifier (AID). There is no user control of the selected secure element, so the user may be not aware of which secure element is used. The secure elements connected to the CLF shall disclose the application identifiers in order to enable the external software component to run the routing procedure. Several concerns are related to this option, such as security, liability and privacy. Mobile Phone Select AID AID 1. 2. 3. 4. SE Identifier 1. 2. 3. 4. SD Card Software Component Other SE Figure 3 : Option 2.1 - Multiple SEs visible to reader as a merged SE Option 2.2: The secure elements are made visible to the contactless reader as if they were physical contactless cards put simultaneously in front of the contactless reader (as shown in Figure 4). As a consequence, the secure element selection is performed at the anti-collision phase. In this case, no user action is needed. The contactless reader selects one secure element after the other until it finds the application it is looking for. It should be noted that some legacy infrastructure does not manage multiple cards selection. Managing multiple instances of the same application scattered across various secure elements is considered to be very difficult in this context. 16 2007, GSMA. All Rights Reserved

Mobile Phone Select SE Scanning of one SE after the other until the application is found Step 2 SD Card * there is no scanning order Software Component Other SE Figure 4 : Option 2.2 - Multiple SEs visible to reader as multiple SEs 5.2.2 Recommendation The recommended solution shall be based on option 1. This is because the user has to be aware which secure element is selected. Furthermore, SE issuers may provide different levels of customer care and Quality of Service (QoS) in addition to different hotlines and customer support policies. 2007, GSMA. All Rights Reserved 17

5.3 Compatibility between ETSI HCI specification and NFC-Forum HCI specification The ETSI TC SCP committee is in charge of defining the interface between the UICC and the CLF. NFC Forum is currently looking at defining a logical interface between the CLF and any host which can be, for example, a secure element or a device host, except the UICC (which is out of scope). Some compatibility issues may arise from the two specifications since the mobile phone could implement the NFC Forum specification in addition to the ETSI specification (e.g. ETSI standard for connecting the UICC to the CLF and NFC Forum specification for connecting the CLF and any other secure element). 5.3.1 Recommendation It is highly recommended that the NFC Forum specification is defined in such a way that no compatibility issues arise when the NFC Forum specification is implemented in addition to the ETSI specification. 18 2007, GSMA. All Rights Reserved

Section 6: UICC Run-Time Environment 6.1 Introduction The telecom industry has chosen Java Card as the execution platform for the UICC. In contrast to the telecom industry, which has its main focus on efficient memory management to keep memory usage low, the contactless industry focus is on transaction performance and has not moved, so far, to mass rollout of Java Card. To limit market fragmentation and to support upcoming NFC services this chapter will point out the following main issues for the UICC run-time environment:. UICC environment. Performance. Memory Management. Multitasking. Management of multiple interfaces. Java Card API. Contactless related services. User Interface. Network access. User Interface. SIM Tool Kit (STK). Smart Card Web Server (SCWS). Java 2 Platform Micro Edition (J2ME) Although legacy systems such as Mifare will not be covered in this chapter, it is important for industry to agree on common standards to support those systems. 2007, GSMA. All Rights Reserved 19

6.2 UICC environment 6.2.1 Performance Performance in contactless systems is mainly measured in transaction speed. This is particularly important in mass transportation services, where the customer must be able to rapidly swipe the card over the contactless reader to guarantee the necessary throughput of passengers during rush hours. Although the mobile phone can emulate a contactless card it has additional contactless functionality which influences the overall transaction speed. The following entities have the biggest influence on the transaction speed. UICC. NFC chip. mobile phone. Contactless Reader Note that adapting mobile contactless devices to have the same behaviour as contactless cards will take some time (due to various mobile device constraints). Moving forward, industry is invited to adapt their infrastructure to accommodate the mobile phone use case. Statement of the problem: The relevant parameter for the service provider is the overall transaction time (as shown in Figure 5). In card only systems the transaction time is mainly defined by the duration of the processing of the contactless protocol and the processing of the application itself. Card Reader Card is moved close to Reader Initialization, anticollision, select application Overall transaction time Transaction Figure 5 : Generic overall transaction time in a contactless interaction 20 2007, GSMA. All Rights Reserved

In case the contactless card is emulated by the mobile phone, the overall transaction time will increase (as shown in Figure 6):. The phone has to switch and poll different contactless modes (card emulation, peer 2 peer, reader/writer). UICC has to leave sleep mode and handle multitasking events. Legacy closed systems typically employ a limited set of cards and readers and hence their interworking and performance can be optimised with a reasonable amount of effort. In mobile contactless systems a large number of different phone manufacturers, NFC chipset manufacturers and UICC manufacturer have to provide equipment that needs to inter-work and guarantee a certain level of performance. Mobile Phone Reader Phone is moved close to Reader polling loop, mode switch, UICC wake-up Overall transaction time Initialization, anticollision, application select Transaction Figure 6 : Overall transaction time in a mobile NFC device Solutions: The overall transaction time can be split into two domains:. UICC transaction time (start-up time and transaction time). Mobile NFC device (reduced operating range and polling loop) For the majority of contactless applications the UICC will contribute the most significant proportion of the transaction time. Therefore it is of utmost importance that the UICC run-time environment is 2007, GSMA. All Rights Reserved 21

highly optimised so as to achieve similar performance levels as those in closed legacy systems. Service Providers will have expectations on the required performance of mobile NFC devices. MNOs will need means to test and qualify these expectations. Therefore MNOs recommend the following:. Mobile NFC device manufacturers should comply with a maximum transaction time delay caused by introducing the mobile NFC device into the system. This maximum transaction time delay could be different for each contactless mode (Java Card mode, legacy mode, NFC peer-topeer mode, etc). The development of a set of reference UICC Java Card applications to help certify and evaluate products. Define a reference reader. The development of a set of reference applications should be worked out in order to test the UICC reference Java card applications. NFC-Forum and ETSI could be the standardisation bodies that define the required certification procedures. 6.2.2 Memory Management Statement of the problem: In a multi-application Java Card environment, strong memory management is needed to avoid denial of service that could potentially be triggered by a single application. The following steps can ensure that the required amount of memory is available for an application:. Application memory control during installation of Java Card applet. Memory control at run-time of application Recommendation: It is recommended that the mechanisms defined in the Global Platform version 2.1 specifications for memory control during installation and resource allocation during run-time (quota) are adopted. 6.2.3 Multitasking Multiple Interfaces The NFC-UICC platform, shown in Figure 7, will introduce new functions, many with their own strict timing requirements. The combination of multiple interfaces and multi-tasking functionality in the UICC will require careful analysis and design decisions to be made in order to guarantee the correct operation of legacy applications (e.g. Universal Subscriber Identity Module [USIM]) and to fulfil the strict timing requirements for contactless applications. 22 2007, GSMA. All Rights Reserved

Figure 7 : UICC architecture Statement of the problem: The UICC will have three different physical interfaces:. ISO 7816. USB. SWP/Contactless Events can occur on all interfaces simultaneously and need to be handled with the appropriate priorities. For example if the mobile communications stack is querying the USIM at the same time the user is using the mobile NFC device in a contactless transport application, then this will pose a large burden on meeting transaction time requirements of the transport service. Therefore the Card Operating system (CardOS) not only has to support concurrent events occurring on physical UICC interfaces but also has to support multi-tasking of the following software applications:. USIM. Multi-application Java Card. OTA Transfer 2007, GSMA. All Rights Reserved 23

Recommendations:. The UICC shall support the concurrent execution of multiple applications (multi-tasking). Multi-tasking should be pre-emptive. This will guarantee that no application can block another one for too long.. Telecom applications (e.g. USIM) must be handled with adequate priority. The CardOS shall be able to handle concurrent events on all available UICC interfaces. The CardOS shall support multiple logical channels on each interface 6.3 Java Card API The definition of a common Java Card API is the most crucial part to fulfil the promise for NFC applications; namely: write once and run many times. Originally the Java Card Platform was specified to provide a secure environment for applications running on a smart card including the support for cryptographic functions. The advent of NFC requires the following new functionality to be supported:. Card Emulation - the UICC has to behave like a normal smartcard including provision of support for legacy systems like Mifare or Felica. Reader/Writer - the UICC needs to be able to read contactless cards and perform secure transactions (e.g. interaction with banking cards or transportation ticketing systems) or reading smart poster tags. Display events on the Man Machine Interface (MMI) (e.g. statement of recent contactless transactions). Smart Card Web Server. Interaction with the network The following sections list in more detail which kind of APIs are necessary to provide rich NFC applications on the UICC 6.3.1 Contactless related services The Java Card and Global Platform specifications define classic APIs needed for Card Emulation applications. A mobile NFC device, with its UICC, will require applications with functionality that goes beyond pure Card Emulation. This is especially true where hardware that is not available in pure Java Cards has to be controlled:. The NFC controller is responsible for switching and routing between different NFC modes. When the UICC needs to start a transaction it has to be switched into the correct mode. The Baseband Controller is the core of a mobile NFC device. It controls all network access and provides the interface to the customer by controlling the display, keypad and additional hardware like audio. 24 2007, GSMA. All Rights Reserved

6.3.2 User Interface API Independent of which technology is used for the user interface, the UICC has to offer new functions and APIs to enable the following functionality:. To start a web browser in the mobile NFC device. To interact with the smart card web server. To start a java midlet in the terminal. To start communication with the Java midlet Although Java Card specification release 7 defines how a Java card applet can start a Java midlet in the mobile phone, this interface should be extended to include parameters for the Java midlet. Furthermore, the mobile NFC device needs to ensure that it starts the application which the Java card applet intended to start so as to avoid phishing attacks. 6.3.3 Network Access Java Card applets should be able to access telecommunication network functions, such as:. Short Messaging Service (SMS). Internet Protocol (IP). Phone Calls For efficient network access a high speed interface is recommended (e.g. Bearer Independent Protocol [BIP], Universal Serial Bus [USB] etc). 6.3.4 Recommendation In order to have a common set of APIs for the UICC, it is recommended that ETSI-SCP specifies all contactless related APIs for mobile NFC services. Those APIs should address the following topics:. Control the NFC controller and its modes. User Interface. Smart Card Web Server/Browser. Control and communication of Java Midlets. Telecommunication Network access. Access to legacy contactless technologies such as Mifare or Felica. Security mechanisms to limit access of Java Card Applets to different sets of APIs 2007, GSMA. All Rights Reserved 25

It is recommended that different levels of certification are defined for Java Card Applets dependent upon the granted access rights of those applets. For example detailed certification rules are required for Java Card applets which require full network access functionality. 6.4 User Interface Figure 8 shows a block diagram of some of the key components within a mobile NFC device. Figure 8 : mobile NFC device architecture overview The user interface is one of the value propositions of mobile NFC to the customer in comparison to card only systems. Although the NFC enabled UICC promises very good software portability, the user interface software has to cope with the following factors across different mobile devices:. different screen resolutions (i.e. number of pixels and colour). different implementations of Java Virtual Machines (JVMs) or web browsers (features). different interpretation ( flavours ) of APIs. different start-up time and performance 26 2007, GSMA. All Rights Reserved

Currently there are three main approaches being considered by industry to develop a user interface for mobile NFC services:. SIM Tool Kit (STK). Smart Card Web Server (SCWS). Java 2 Platform Micro-Edition (J2ME) The pros and cons of each of these are listed below. 6.4.1 SIM Tool Kit Pros Proven and tested technology Highly interoperable between different mobile terminals Cons Only text based user interace User experience is different between mobile terminals OTA provision of user interface Java Card Applet and UI is on the same media. Hence changing terminals is very easy for the customer. 6.4.2 Smart Card Web Server Pros Uses built-in browser of mobile NFC device to render data For simple web server content quite high interoperability OTA provision of user interface Java Card Applet and UI is on the same media. Changing terminals is very easy for the customer Cons New technology in UICC It is difficult to define the exact look and feel of the interface since the browser s rendering engine finally controls the exact layout Interactive user interaction with typical browsers is bad: Many key clicks necessary to input information Different versions of web pages have to be stored to adapt for UI for different browsers and screen resolution in the terminal. 2007, GSMA. All Rights Reserved 27

6.4.3 J2ME Unlike SIM Tool Kit and Smart Card Web Server, J2ME applets are not directly controlled by the UICC. They are typically installed and executed by the baseband controller or application CPU of the mobile phone. Therefore additional security steps need to be taken to guarantee secure and trustworthy operation of the application. For example, the following measures are required:. Authentication mechanism between Java midlet and Java Card applet. Code Signing Certificate should be stored on the UICC and this needs to be supported by the mobile NFC device. JSR should only access the UICC when Java midlet is signed. The UICC should restrict access to certain Java Card applets: e.g. banking card Java Card applets should only communicate with signed banking Java midlets. Pros User interface is fully customisable User interaction can be perfectly adapted to service provider needs Expensive UICC memory is not used Cons API is not the same or does not work in the same way on different mobile phones Test effort quite high: NFC services have to be tested or even adapted for new terminals coming to the market Changing the phone requires reinstallation of the UI on the new phone. OTA process is more complex: Java Card applet and the correct Java Midlet have to be installed. Any of the above options (or combinations thereof) are possible; the choice is left to the operator implementation. 28 2007, GSMA. All Rights Reserved

Section 7: OTA Provisioning 7.1 OTA Infrastructure description OTA infrastructure is made of several functional components that are likely to be developed and managed by different entities. Since all these components have to interface with each other, there is an interoperability issue that can arise. In order to reduce this risk, MNOs have worked together to come up with a common high level architecture with a clear split of responsibilities and a clear definition of interfaces between actors and their associated platforms. OTA platform and infrastructure providers and managers are thus invited to use this description as a guideline and reference for the design of their technical solutions. Figure 9 shows the reference architectural diagram, the interfaces are described in 7.1.3.3. Figure 9 : Reference OTA Provisioning Architecture 2007, GSMA. All Rights Reserved 29

It is also assumed that the system is initialised after UICC creation by UICC manufacturers. It consist of providing the UICC and Issuer Security Domain (ISD) information to the MNO (or Card Issuer), and in some cases it might also include providing pre-created SDs or pre-loaded applications details to the relevant Service Providers (SPs)/TSMs/Certification Authorities. 7.1.1 Functional architecture In this chapter it is assumed that relationship between TSMs, MNO and SPs are already established, and that all their platforms are correctly connected and configured. If required by SP and/or MNO, the TSM might be constrained to go through a certification process. The following functions will be distributed amongst MNOs (or Card issuers), Trusted third parties acting as TSMs and SPs, with different splits possible depending on the model agreed between these actors (mapping of functions and actors is presented in section 7.1.3). The main functionalities that shall be covered by the OTA infrastructure are listed below, sorted by high level functional roles: SP management SP Registration (privileges, interfacing etc) Service approval (Applet and Midlet approval) TSM management TSM Registration (privileges, interfacing etc) Service approval (Applet and Midlet approval) End user management User request for OTA operation management (includes user privileges verification, and user data exchange between Service Provider, TSM and MNO) Associate UICC to MNO customer in MNO server User authentication (mutual authentication) User identifier management (aliasing for privacy) Black list management User registration and churn Customer care Personalisation data management 30 2007, GSMA. All Rights Reserved

UICC management UICC data management (ISD keys, UICC profile etc NFC data management (installed service list on UICC etc) UICC capability verification (NFC, memory, applets already installed etc) SD creation (temporary SD keys creation) SD keys update SD allocation to SP (owner) and link to TSM (potential manager) SD Keys transfer to TSM or SP (optional) SD keys provisioning from SP/TSM on server and on UICC Secure channel creation between server and ISD (data ciphering and data signature) Ensure MNO control on all operations in Delegated Management model (for security reasons and to update the installed services list) Lifecycle management (loss, re-issuance etc) Applet deletion (including SD deletion) Midlet signature/certificate issuance and delivery Access Control Policy (ACP)/ Access Control File (ACF) creation and loading on UICC Applet issuance Applet loading Applet installation Applet extradition Applet activation Applet deletion Token request (in TSM Centric/delegated management model) Data Authentication Pattern (DAP) request (in Issuer centric model) MMI application issuance SCWS applications installation (servlets) Midlet installation Midlet signature/certificate management 2007, GSMA. All Rights Reserved 31

Service management Manage NFC services (=set of applets, midlets and data) Manage Applet and Midlet provisioning and versioning Ensure SP control on the Applets installed under its SD in Issuer Centric model NFC data management (installed service list on SD etc) Service administration (Applet lock/unlock) Mobile device management Device compatibility (NFC, JVM etc) verification Lifecycle management (loss, re-issuance etc) Applet personalisation Configuration of personalisation method (depends on SP Applet implementation) Applet personalisation with SP keys and SP data Applet personnalisation with user data Secure personalisation using SD features Security Domain management Secure channel creation between server and SD (data ciphering and data signature) SD Keys update with final keys Certificate management for key update SD data provisioning (SD initial keys, privileges etc) Ensure SP control on all operation in Issuer Centric model Applet transport management Selection of fastest bearer available Command formatting depending of the bearer (SMS, BIP, Hyper Text Transfer Protocol HTTP/ HTTP(s), Over Internet Protocol [OIP] etc) Ensure correct command delivery Inform Applet Issuer on command execution status 32 2007, GSMA. All Rights Reserved

7.1.2 Flow diagram The following flow diagrams are for descriptive purpose only and are not exhaustive. They present 7 of the main functions of the NFC Services OTA provisioning: Service Provider registration TSM registration Service provisioning/creation End user management (subscription) SD Creation Applications Download/ Installation Applet Personalisation Notes: 1. The SD creation can be performed during UICC manufacturing with SD keys unknown by the MNO. Applet and Midlet can also be pre-installed before UICC and mobile issuance. 2. The Service ID introduced in this diagram is an identifier shared between the Service Provider and the TSM. It is a proprietary parameter that does not need to be standardised. Figure 10 presents a possible implementation for initialisation of the OTA infrastructure. Initialisation is required before delivering NFC Services to end users. End-User SP TSM Card-Issuer *Service Approval request (Applets and Midlets and list of AIDs, Service Name) 1. Service Provider provisioning Ack (Applets and Midlets approved by card-issuer) Verify/generate AIDs, inocuity of applications Store application/commands hash TSM registration request 2. TSM Registration SP connection request (SP ID) Ack (TSM ID) SD creation request Register TSM Ack (SD AID) Reserve SD for SP Ack (SP SD AID) Service Registration (Approved Applet(s) and Midlet(s) and list of instanciation data) Ack (Service ID) Create Service 3. Service provisioning/creation Figure 10 : Initialisation Sequence Diagram * Note: Some of the service approval functions performed by the TSM can also be performed by the MNO. 2007, GSMA. All Rights Reserved 33

Figure 11 presents a possible scenario (TSM centric scenarios as in 7.1.3, case 3 and 4) with the main steps to go through in order to deliver an NFC Service on an end user NFC mobile device and UICC. End-User SP TSM Card-Issuer End-user subcription to NFC service Process subcription Aliasing 4. End user subscription Service Installation Request (User ID, Service ID) Check if SD already created? SD creation request (User ID, SD AID) SD creation Ack (SD temporary keys) Update SD keys(sd final keys) Ack 5. SD creation (if not created in factory) End-user acceptance and/or authentication Token request (Applet AID,list of commands) might be required prior Applet Ack (Tokens) installation Applet installation Token verification PoR Retrieve Applet and ACP file and prepare installation commands 6a. Applet installation (if not pre-installed) Get perso data Ack (Perso Data) Applet personalisation Ack Perso commands preparation 7. Applet personalization Push Wap (Midlet URL) Retrieve Midlet User acceptance Request Midlet Download signed Midlet Retrieve Midlet Signature verification and Midlet installation under a Protection Domain Ack Inform SP that NFC Service is operational Send SMS: Service is operational Inform on installation status 6b. Midlet installation (if not pre-installed) Figure 11 : OTA NFC Service Delivery 7.1.3 Roles description Figure 12 presents the split of two main set of functions (applet load/install/delete and applet lock/personalisation) between actors, depending on the model. General assumptions are as follows: The UICC contains an issuer security domain (ISD) The UICC contains one additional SD per SP The TSM does not by itself have an SD The TSM may in some cases manage the keys for an SPs SD There are other models possible, for instance where a TSM has an SD in its own right. Such models are not considered further in this document, however, technically they are quite similar to the models that are considered. 34 2007, GSMA. All Rights Reserved

UICC MNO Network TSM SP #1 SP #1 Card Issuer encryption Storage ISD Control & encryption SP #2 SP #2 SP #3 Token Generation Policy Appli Tokens (optional) Delegated Management SP #3 SP #4 Token Generation Policy Appli Tokens (optional) Storage SP #4 Delegated Management encryption SP Load/install data Lifecycle Management SP Pesonalization data (SCP) Figure 12 : OTA Functional Separation Case 1 (SP#1 in diagram): Issuer centric loading with separate TSM In this configuration, the Card Issuer will load, install, activate and delete the applet. The TSM, acting as a single point of entry for all card issuers, will manage the Applet lock, unlock and personalisation (using its own OTA server but the network of the MNO) and if required will provide the DAP signature, for all Card issuers. TSM will act as a proxy, managing the SD on behalf of the SP. Case 2 (SP#2 in diagram): Issuer centric loading with SP acting as its own TSM It is the same case as above except that here the SP will have to connect to all Card Issuers, so there is not the advantage of a single point of entry. Case 3 (SP#3 in diagram): TSM centric loading (Delegated Management) Here the SP acts as its own TSM Same as Case 4 with SP required connecting to all Card Issuers. Case 4 (SP#4 in diagram): TSM centric loading with separate TSM In this model, the TSM can issue the Applet. Card Issuer can require or not the use of a Token for the load and installation commands (it depends on its Token policy). TSM will act as a proxy managing the SD on behalf of the SP. 2007, GSMA. All Rights Reserved 35

The high level set of functions to be covered by the OTA infrastructure (see section 7.1.1 for detail) is encompassed in the following roles: SP manager TSM manager End user manager UICC manager Applet issuer MMI application issuer Service manager Mobile device manager Applet personalisation manager Security Domain manager Transport protocol manager These roles are dispatched between the different actors identified (MNO, TSM and SP) in the following sub-sections. 7.1.3.1 Issuer Centric Model Figure 13 represents the mapping between actors and roles in Issuer Centric Model introduced in Case 1 and 2 above (in Case 2 the Service Provider and the TSM are simply merged as shown in the diagram below): Figure 13 : Issuer Centric Model 36 2007, GSMA. All Rights Reserved

7.1.3.2 TSM Centric (Delegated Management) model Figure 14 represents the mapping between actors and roles in the TSM Centric (Delegated Management) Model introduced in Case 3 and 4 above (in Case 3, the Service Provider and the TSM are simply merged as shown in the diagram below): Figure 14 : TSM Centric Model 7.1.3.3 Interfaces description The high level interfaces between actors (as presented in Figure 9) expose different functions that are listed but not detailed below: Interface 1: MNO => TSM Service Provider management This interface allows the MNO to provision (after service validation) and to manage service providers and their NFC services Device loss management It allows the MNO to inform the TSM of device loss New Device delivery notification It allows to inform TSM that end user has received its new UICC TSM => MNO Token request This interface will allow the TSM to retrieve a token when required in case of Delegated Management Installation request It allows the TSM to request applet installation through ISD in case of Issuer centric model 2007, GSMA. All Rights Reserved 37

Interface 2: TSM => SP Device loss management - This interface allows the TSM to inform the SP of device loss (after MNO request) New Device delivery notification It allows to inform SP that end user has received its new UICC (after MNO request) SP => TSM NFC Service end user subscription request This interface allows the SP to request to the TSM to install its NFC service after end user subscription Interface 3: MNO customer => TSM No functional interface (there is, however, a technical interface). TSM => MNO customer NFC Service installation This interface allows TSM to send load, installation, personalisation and device management commands to the end user's NFC mobile phone and UICC. 7.2 Technical issues There are a large number of available specifications that define the different tools used for the OTA provisioning of NFC Services, and many possible implementations for such specifications. This leads to a high complexity and represents a risk for interoperability if different actors of the NFC Service provisioning chain have incompatible implementations of their OTA platforms. That is why MNOs want to provide technical recommendations on OTA provisioning mechanisms. 7.2.1 Confidential OTA SD creation 7.2.1.1 Statement of the problem OTA SD creation is required in order to be able to host multiple new Service Providers on MNOs UICCs after card issuance. Fully confidential OTA SD creation would be required for some Service Providers like banks. Current specifications do not comply with this requirement. 38 2007, GSMA. All Rights Reserved

7.2.1.2 Solutions A simple approach is for the MNO to order cards with a number of pre-installed SDs, which are loaded at card production; the card manufacturer then stores the domain keys. The MNO later instructs the card manufacturer to pass the domain keys to TSMs and Service Providers, for example once the intended owner of the Security Domain (i.e. either TSM or SP) has been decided. In this scenario, the MNO never sees any domain keys except for its own ISD on the card. A drawback to that approach is that it limits the number of TSMs or Service Providers that can be supported, which is an argument for allowing creation of SDs via OTA as well. In the current implementation of OTA SD creation, the Card issuer, that is the MNO, will create the SD with temporary keys, and then will provide the temporary keys to the SP or TSM which will have the possibility to update the SD keys with the final keys. This mechanism is already specified by Global Platform (see [1]). For confidential OTA SD creation, GP is currently working on a new mechanism (see [2]), presented to MNOs, which still raises a few questions: In order to communicate with his newly created SD, a service provider has to obtain a signature from a trusted third party. This feature obliges the establishment of a commercial relation between the Trusted Third party and the Service Provider. The mechanism defined in this new GP document relies on the On Board Key Generation. The implementation of this feature increase complexity of the SIM card. Moreover, to prove to the service provider that the keys that he has received form the card has really been created on the card, a certification of the card will be needed. These two features are seen as brakes to contactless deployment by MNOs. 7.2.1.3 Recommendation UICCs shall support SD creation as specified by Global Platform including SD installation, and personalisation using the Issuer Security Domain (ISD). The install commands addressed to the oncard SD shall have the same format as the GP Install commands (Install for Install, make selectable, for personalisation etc) addressed to any on-card application. OTA infrastructure and UICCs should also support the same mechanisms after the UICC is manufactured in order to create new SDs via OTA. For fully confidential OTA SD creation, the new mechanism proposed by GP shall be improved to resolve the concerns listed previously before being implemented on UICCs. 2007, GSMA. All Rights Reserved 39

7.2.2 Applet issuance 7.2.2.1 Statement of the problem In order to install NFC Services on all end user mobile whatever the MNO or TSM, there is a need to have an interoperable Applet installation process 7.2.2.2 Solutions Applet issuance requires the use the following GP commands: Load Install for load Install for install Install for personalization Install for make selectable Install for extradition Delete command Application loading, installation and activation shall be completely interoperable, whatever the UICC on which these operations are run. 7.2.2.3 Recommendation It is recommended to use standard GP commands to install Applets. Update of Applet code shall not be permitted by the Applet. If the code is updated, then it is considered as a new version of the application, and thus need to go through certification, registration and installation processes. Operation of Applet (for example: Ticket issuance, counter reset, etc) is not an Applet code update, then it can be performed independently of the MNO. 7.2.3 Transport protocol 7.2.3.1 Statement of the problem The NFC Service OTA provisioning shall be as fast as possible and must rely on widely deployed solutions. 40 2007, GSMA. All Rights Reserved

7.2.3.2 Solutions SMS: This bearer is suitable for small amount of data to send to the UICC. More precisely, one SMS can contain 140 bytes of data. So it is not suitable for the loading of heavy application (above 1kb). Commands such as Install for install, install for make selectable and Install for personalisation can be easily encapsulated in SMS. BIP in Push mode (connection at the initiative of a Server) require the use of a SMS Push BIP sent to the UICC. Midlet installation in Push mode (request from a Server) requires the use of a SMS Push Wap (containing the URL of the Midlet to download). In conclusion, the SMS bearer shall be supported by the TSM. BIP CAT_TP over User Datagram Protocol (UDP) or BIP TCP/IP: TSM should support this standard and interoperable way to communicate with the UICC. It can be used for any command, but might prove itself a bit heavy to set up for very small payloads of data (like Applet locking command, for which the SMS bearer is more relevant). Mobile devices and UICC shall support BIP over CAT_TP and TCP/IP. Midlet Proxy: In case the handset would not support the BIP CAT_TP (or TCP/IP), the other solution (not recommended) is to use a midlet proxy to forward the command to the UICC. The cons are that it requires developing and installing a dedicated Midlet for each type of mobile. Then the user experience will be degraded because the user will be asked at least twice to approve the service installation (once for the Midlet and once for the Applet because the Midlet proxy needs user approval-, and possibly a third time to install the Midlet proxy). Through NFC reader: The use of this transport channel is based on the same process as OTA management. In that case, the commands are encapsulated in HTTP, send to a Proxy application in an NFC reader, then sent over Radio Frequency (RF) field to the UICC where the Application Protocol Data Units (APDUs) are retrieved and addressed to the right application. 7.2.3.3 Recommendations For Applet management (lock/unlock) or personalisation, the most relevant bearer is the SMS. For Applet download, BIP CAT_TP or TCP/IP is recommended since it is standardised, faster and more reliable than SMS, and does not require any Midlet proxy in the Mobile phone. OTA platforms shall support at least SMS and BIP (CAT_TP or TCP/IP) bearers. 2007, GSMA. All Rights Reserved 41

7.2.4 Token mechanism 7.2.4.1 Statement of the problem MNO must ensure security and consistency of its UICC. The Delegated management offers the possibility to third parties to install applets on MNOs UICCS, which might threaten consistency and security if MNOs do not know what is installed on its UICC. 7.2.4.2 Solutions In order for MNOs to keep track of all management operations occurring on their UICCs in case they decide to delegate the application management for some Service Providers, UICCs and OTA infrastructure shall support the Token mechanism for all management operations as specified in GP 2.2 specification. The required Tokens shall be configurable by each MNO and independently for each UICC model. Once the UICCs are configured and issued, the TSM and MNOs must be informed of the UICCs Token configuration, and thus the TSM shall require a Token for each operation that requires one, and MNO shall provide it after command verification and logging. The Token will be verified by the Issuer Security Domain on the UICC before any operation requiring a Token, using a Token key managed by the ISD. Uniqueness of the token (one different token shall be delivered for each operation on each UICC) shall be guarantied. Otherwise a TSM or SP might reuse a Token provided once per the MNO for a given end user (and so for a given UICC) on any other end user UICC, which means that the MNO would lose control of its UICCs in the case of the TSM Centric (delegated management) model. This uniqueness can be ensured by mandating the use of the Card Identification Number for the token calculation, which implies that this field is present and not null in all NFC UICCs. In this case, MNO can use the same key for token calculation on all its UICCs. Another solution is to have one keyset per card used for token calculation, but this is not a cost effective solution and it is more complex to manage. Global Platform specifies Public Key Infrastructure (PKI) based and Data Encryption Standard (DES) tokens. Should the UICCs do not support PKI, MNOs would then recommend using DES Token since the security achieved is similar to PKI based mechanism. 7.2.4.3 Recommendations In a TSM Centric model, where the TSM has Delegated Management rather than Authorised Management privileges, the TSM shall be able to ask for a Token from the MNO OTA platforms prior to any operation requiring a Token. The MNO must decide on the list of operations requiring a Token and must be able to deliver these tokens to the TSM through its OTA platform. 42 2007, GSMA. All Rights Reserved

7.2.5 Data Authentication Pattern (DAP) mechanism 7.2.5.1 Statement of the problem In Issuer Centric model, MNO will be able to install Applets under SP SD. The risk for the SP is that the MNO installs an Applet without notifying the SP, and thus without the SP consent. 7.2.5.2 Solutions Global Platform specifies the DAP mechanism to ensure that any Applet installation under a Secondary SD has been approved by a SP. The Data Authentication Pattern verification mechanism is used when an Application Provider requires checking their Application code to be loaded on the card for integrity and authenticity. The DAP Verification privilege of the Application Provider's Security Domain detailed in Global Platform 2.1.1 specification provides this service on behalf of an Application Provider. The key and algorithm to be used for DAP Verification are implicitly known by the corresponding Security Domain. The flow control and runtime behaviour are the same that applies to Card Content Loading Process. 7.2.5.3 Recommendations In Issuer Centric model (excluding Confidential loading), MNO OTA platform shall be able to ask for DAP from the TSM or SP prior any installation of Applet under SP SD if required by the SP. 7.2.6 Authorised management 7.2.6.1 Statement of the problem The UICC is currently owned by the MNO (i.e. the card issuer), so it is the MNO s responsibility to provide secure storage and execution area to Service Providers (e.g. via TSMs). Should the MNO share privileged management privileges with an SP or TSM, then the MNO might not be able to guarantee memory space on the UICC. The implementation of Authorised Management in GP 2.2 (no Token required for Card content management operations like loading ) for other on-card entities than the ISD requires a strong trust relationship between the MNO and the party that has such Authorised Management privilege. It might be the case that the MNO owns a TSM, or has a tight commercial relationship with a TSM, in which case the TSM could have Authorised Management privileges. MNOs might also deploy additional solutions to ensure correct memory management and security by a TSM (including having the power to delete the TSM s Security Domain in the worst case). Alternatively, a TSM might represent an SP or consortium of SPs that is not fully trusted by the MNO to safely manage applications on the UICC. The TSM might be a Trusted Third Party from the point of view of the Service Providers, but not entirely trusted from the point of view of MNOs. In that case, Authorised Management would likely reduce optimisation of the UICC management, 2007, GSMA. All Rights Reserved 43

and the MNO could lose control of the UICC. MNOs might not be able to guarantee the secure storage and execution of Service Provider applications on the UICC. 7.2.6.2 Solutions The use of Delegated Management can provide the same confidentiality level as the Authorised management for the SP, and can provide tight overall security control on the UICC since Applet installation on the UICC can be controlled by both the MNO and the SP/TSM. There could still need to be a means to confidentially vet applications that the SP wishes to load, before the MNO creates Load Tokens for those applications. It would not in general be acceptable for the SP to provide a confidential application to the MNO for approval, or for the MNO to blindly sign a Load Token for a confidential application without knowing the content of the application. But confidential vetting could be performed by a Trusted Third Party (TTP). 7.2.6.3 Recommendations MNOs do not recommend implementing Authorised Management unless there is a high trust relationship between the MNO and a TSM. In the case where there is not such a trust relationship, MNOs recommend to use the Delegated Management to load applications that are required by the SP. 7.2.7 Applet personalisation 7.2.7.1 Statement of the problem Different mechanisms are available for application personalisation, and it is up to the application developer to decide which one the application should support. Proprietary mechanisms might increase Applet OTA personalisation complexity and cost. 7.2.7.2 Solutions Depending on the way the application is implemented, personalisation can be done either by: selecting the application and sending applicative commands through NFC or wired interface or OTA using either a midlet proxy or directly with BIP or SMS passing the personalisation data during the installation (in the install for install command) using standard GP command after application installation and before application activation (sending install for personalisation and store data commands to the SD Personalisation Support) using standard GP command after application activation (sending secured -with SD keysapplicative commands to the application that needs to implement the GP API - Runtime Messaging) 44 2007, GSMA. All Rights Reserved

7.2.7.3 Recommendations The most standard mechanisms, GP based, are recommended for applet personalisation. It is also recommended to have an interoperable personalisation method, meaning that for a given NFC Applet, it will use the same personalisation commands, whatever the UICC on which it is installed. 7.3 Proprietary system issues Where there is a business requirement to support legacy systems, it is important to provide guidelines on OTA management for such existing infrastructures to ensure Mobile NFC is easily deployable by Service Providers using these technologies. In this chapter are introduced two of the leading proprietary systems in deployment around the world. 7.3.1 Mifare 7.3.1.1 Statement of the problem Mifare is not yet integrated into a mono-chip UICC but there are some on going work to do so. Mifare system is not yet manageable using Global Platform and ETSI standards. 7.3.1.2 Solutions NFC mobile handsets in card emulation mode should be compatible with existing Mifare reader infrastructure. Most commonly used Mifare cards (Mifare classic and DESFire) are integrated modules that combine an RF module with a microprocessor. Thus Mifare classic and DESFire can be emulated in a mobile handset with NFC module and UICC playing the RF part and processor part respectively. However, a software only emulation is preferred without hardware alterations, as long as there is satisfactory performance (e.g low enough transaction time). Even for the software based case, emulation based on post-installed applications is preferred over pre-installed Operating System (OS) level modules. It is required to have an API available to the applications on the handset or on a remote server exposing the Mifare emulation in the UICC. 7.3.1.3 Recommendation Where Mifare emulation is supported, the UICC shall be fully compliant with Global Platform and ETSI standards so that any OTA platform compliant with these standards can manage Mifare applications. A Mifare Application running in the UICC shall have the possibility to be hosted and run under any Security Domain, in either the Issuer Centric model or TSM centric model. 2007, GSMA. All Rights Reserved 45

7.3.2 Felica 7.3.2.1 Statement of the problem The Felica system is not manageable using Global Platform and ETSI standards. 7.3.2.2 Recommendation Further study and investigation are recommended for the FeliCa system to be compliant with GP and ETSI standards. 46 2007, GSMA. All Rights Reserved

Section 8: Mobile NFC Device Security 8.1 Introduction: Security considerations This section describes, from an MNO perspective, the key issues related to NFC security as applied in the Mobile environment. End-to-End NFC service security is not addressed here, as it is assumed this will be addressed on a service-by-service basis by the respective Service Providers and will require inputs from the key ecosystem players involved in service provision. This section addresses the security issues associated with using a Mobile NFC device (i.e. NFC handset) as part of the overall end-to-end NFC service provisioning infrastructure. From the perspective of the Mobile NFC device, the following security issues need to be considered, when deploying Mobile NFC services: The Mobile NFC device environment needs to provide a storage area where files and applications can be securely managed The NFC Application environment has to enable NFC applications to run without the risk of sensitive data being intercepted by other applications Where NFC services need to exchange information with external entities, all necessary security measures need to be implemented to ensure data integrity, confidentiality and non-repudiation of the data exchanged Any impact on Telecommunication functionality, such as SMS, Internet access, call set-up etc, must be evaluated Before exploring some of the key security issues of the Mobile NFC device, a brief description of the Mobile NFC device architecture is given. 2007, GSMA. All Rights Reserved 47

8.1.1 Mobile NFC Device Architecture A Mobile NFC device provides a combination of NFC services with mobile telephony services. With this definition, a mobile phone employing a UICC as the Secure Element and an NFC controller can provide an ideal platform for NFC service applications. Within this context, the UICC hosts and manages the NFC service files and applications, while the NFC controller manages the NFC interface (i.e. to the contactless reader) (see Figure 15).. External Environment UICC (Secure Element) APPLICATION Handset CPU NFC Controller External Environment Figure 15 : Mobile NFC Device Security Architecture The remainder of this section addresses the following security issues: Handset 1. Secure display on the screen and secure entry on the keyboard 2. User Interface Authentication NFC services 3. Enhancing security by employing handset connectivity 4. NFC Application Approval 48 2007, GSMA. All Rights Reserved

8.2 Secure display on the Screen and secure entry on the Keyboard 8.2.1 Statement of the problem From a user s perspective, for NFC payment services, a key requirement is: the price I see is the price I pay. This means that Service Provider needs to ensure the integrity of the information presented to the user and the information processed by the NFC application. The information presented to the user could be displayed either on the mobile NFC device (i.e. handset screen) or on the NFC/Contactless reader. The following options are possible: 1. The NFC/Contactless reader can have a keyboard and a screen, which are used to display and manage the user data. In which case, data security needs to be ensured by the legacy system. 2. The Mobile NFC device keyboard and screen are used to display and manage the user data. 8.2.2 Recommendations In the case where the mobile NFC device manages the presentation of information to the user (via the mobile NFC device keyboard and screen), MNOs recommend equipment manufacturers and application developers to investigate methods which would ensure data integrity and nonrepudiation of the information (i.e. the screen and keyboard device drivers and hardware should be secure). 8.3 User Interface Authentication 8.3.1 Statement of the problem In some Mobile NFC device designs, it is possible for the user interface software to be located in the handset, rather than in the UICC. In such cases, Java based signed applications need to be used to interface with the NFC applications running in the UICC. Digital certificates can be used to sign applications which can be stored either in the UICC or in the handset. The Mobile Information Device Profile (MIDP) version 2.0 specification requires that a Java Virtual Machine (JVM) must be able to read digital certificates in the phone memory. Digital certificates stored in the UICC can also be supported by the JVM since it is a requirement of MIDP2.1. 2007, GSMA. All Rights Reserved 49

8.3.2 Recommendations and Solution Only applications authorised and authenticated by the UICC should be allowed to exchange information with the UICC. MIDP related Operator certificates should be stored in the UICC and should be managed by the handset s Java Virtual Machine as specified in MIDP2.1 specification. 8.4 Enhance security by using OTA capability 8.4.1 Statement of the problem A Contactless card is a device which is predominantly not connected to a Service Provider. Such a device only becomes connected to the SP when it is physically placed near a contactless reader. This connected state typically occurs only during an NFC transaction. Hence if any potential security threat occurred in this un-connected state (for example if the contactless card was lost or stolen etc.) it could not be managed by the SP. In summary, contactless card security is managed at a service and contactless reader level; not at the card level. This problem can be further exacerbated by the fact that contactless readers are not always connected. For example, contactless readers on a public transport bus are generally not able to perform online authentication for each contactless transaction. This could result in unauthorized/fraudulent transactions being performed. 8.4.2 Solution A mobile phone is a device which is predominantly connected to the MNO. Hence, integrating NFC services into a mobile phone can enhance the end-to-end security of the Mobile NFC service. If the mobile NFC device were lost or stolen, then the customer would need to make just one call to his service provider (this could be the NFC SP, MNO or TSM). If the mobile NFC device is connected to the network, this would result in OTA disablement of the lost or stolen mobile NFC device and all the NFC applications residing in the UICC of that device. For example, the following services can be enhanced by utilising the connected state of the mobile NFC device by allowing the SP to perform network security checks at periodic intervals: Transport applications Banking applications 50 2007, GSMA. All Rights Reserved

8.4.3 Recommendations MNOs recommend that NFC Service providers make full use of the enhanced security benefits which can be provided leveraging the OTA connectivity inherent with mobile NFC devices (i.e. mobile phones), such as: Remote Application Management (Activation/ Inhibition/ Lock/ Deletion/Update) Remote update of security algorithms Information Upload from the mobile NFC device to the SP 8.5 NFC Application Approval 8.5.1 Statement of the problem Depending upon the service type, applications may need to comply with coding rules and standards as defined by NFC services provider. Since the existing UICC environment does not provide an API filtering mechanism, applications need to comply with coding rules as defined by the MNO (e.g. for memory management or exchange information by sms). These coding rules are dependent upon the specific MNO market. One of the objectives of these rules are to protect user and other applications from unexpected behaviour. 8.5.2 Recommendations MNOs make the following recommendations for any NFC application developed to operate within any Mobile NFC device: 1. The NFC application should be assessed and approved by the NFC Service provider or an agreed entity. 2. The Application should also be assessed and approved by MNOs or an agreed entity (e.g. TSM). 2007, GSMA. All Rights Reserved 51

Section 9: Errata to Mobile NFC Technical Guidelines, Version 1.0 (Released April 2007) Section Original Description Modification Reason for Modification 7.2.2 [NFC-WI (S2C)] Supports Type A, (and also Type C, but the latter was not considered within the scope of the project). Type B is theoretically supported. [NFC-WI (S2C)] Supports Type A and Type C. Type B is theoretically supported. The FeliCa RF (Type C), which is standardized under ISO18092, is included in the Work Package scope as part of this NFC standard. 7.3 [T=X] Renumber Section 7.3 to Section 7.2.3 Section numbering error 7.4 [DIOCTL] Renumber Section 7.4 to Section 7.2.4 Section numbering error 7.5 [Solutions] Renumber Section 7.5 to Section 7.3 Section numbering error 7.6 [Recommendations] Renumber Section 7.6 to Section 7.4 Section numbering error 52 2007, GSMA. All Rights Reserved

Section 10: Acronyms Acronym ACF ACP AID APDU BIP Card Issuer CAT TP CLF DAP ETSI ETSI-SCP GP GSM GSMA HCI HTTP IP ISD ISO J2ME JVM MIDP MNO NFC OIP OS OTA QoS RF SCWS SD SE SIM SMS SP STK TCP/IP TSM TTP Meaning Access Control File Access Control Policy Application Identifier Application Protocol Data Unit Bearer Independent Protocol Issues Cards and optionally configures card security domains Card Application Toolkit Transmission Protocol ContactLess Front-end Data Authentication Pattern European Telecommunications Standards Institute European Telecommunications Standards Institute-Smart Card Platform Global Platform Global System for Mobiles GSM Association Host Controller Interface Hyper Text Transfer Protocol Internet Protocol Issuer Security Domain International Standards Organisation Java 2 Platform Micro Edition Java Virtual Machine Mobile Information Device Profile Mobile Network Operator Near Field Communication Over Internet Protocol Operating System Over The Air Quality of Service Radio Frequency Smart Card Web Server Security Domain Secure Element Subscriber Identity Module Short Message Service Service Provider SIM Tool Kit Transmission Control Protocol/Internet Protocol Trusted Services Manager Trusted Third Party 2007, GSMA. All Rights Reserved 53

Acronym UICC USB USIM Meaning Universal Integrated Circuit Card The UICC is a smart card which contains account information and memory that is used to enable GSM cellular telephones. One of the applications running on the smart card is the SIM, or Subscriber Identity Module. In common parlance the term "UICC" is not used but the phrase "SIM" is used to describe the smart card itself. Universal Serial Bus Universal Subscriber Identity Module 54 2007, GSMA. All Rights Reserved

Section 11: Appendix A: NFC Technical Guidelines Version 1.0 White Paper 2007, GSMA. All Rights Reserved 55

mobile NFC technical guidelines Version 1.0 April 2007

Mobile NFC Technical Guidelines vs1 Disclaimer and Legal Notices Every care has been taken in the preparation of this report to ensure that the information provided is accurate, factual and correct to the best of our knowledge. The GSMA accepts no liability for any loss or damage or unforeseen consequential loss or damage arising from the use of the information contained within this document. All Rights Reserved. No part of this document can be copied, shared, redistributed, transmitted, displayed in the public domain, stored or displayed on any internal or external company or private network or electronic retrieval system, nor reprinted, republished or reconstituted in any way without the express permission of the GSMA. 2007, GSMA. All Rights Reserved Appendix i 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 Table of Contents SECTION PAGE 1. EXECUTIVE SUMMARY 1 2. INTRODUCTION 4 2.1 Reference Documents 4 3. PURPOSE OF THE DOCUMENT 5 4. GENERAL ARCHITECTURE FOR MOBILE NFC SERVICES 6 5. PROJECT DEFINITION 7 5.1 GSMA 7 5.2 Stakeholders 7 5.3 Approach 7 5.4 Deliverables 9 6. SECURITY ISSUES 10 7. UICC TO NFC CHIP INTERFACE 11 7.1 Introduction 11 7.2 Technical Propositions 12 7.3 T=X 13 7.4 DOCTL 14 7.5 Solutions 14 7.6 Recommendations 14 8. MOBILE TO READER INTERFACE 15 2007, GSMA. All Rights Reserved Appendix ii

Mobile NFC Technical Guidelines vs1 8.1 Radio-frequency compatibility of NFC mobile phone 16 8.2 "Battery Low" use case 17 8.3 Operational range 19 8.4 Transaction duration 20 8.5 Application selection 21 8.6 RF Layer Privacy Issues 24 8.7 Automatic Switching between the different NFC Modes 25 8.8 Automatic Enabling of the NFC Module 26 9. MULTI-APPLICATION UICC FRAMEWORK 28 9.1 General Issues 28 9.2 Proposed Solutions 28 9.3 Recommendations 30 10. ACRONYMS 31 FIGURES FIGURE 1: Reference Mobile NFC Architecture 6 FIGURE 2: Power Levels within a Mobile NFC Device 17 FIGURE 3: Operational Range between two NFC Devices 19 FIGURE 4: Application Selection Problem 22 FIGURE 5: Explicit Selection 23 FIGURE 6: Implicit Selection 23 FIGURE 7: Mobile NFC Device Functional Architecture 29 TABLES TABLE 1: SWP Pros and Cons 12 TABLE 2: S2C Pros and Cons 13 TABLE 3: T=X Pros and Cons 13 TABLE 4: DIOCTL Pros and Cons 14 Appendix iii 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 Section 1: Executive Summary Twenty of the largest Mobile Network Operators (MNOs) have been working together, in a GSM Association (GSMA) initiative, to develop a common vision on Mobile NFC services, promoting the development of a stable and efficient ecosystem and to prevent market fragmentation. In this GSMA initiative, MNOs have performed an analysis of the UICC to NFC Chip interface, the Mobile to reader interface and the multi-application UICC framework. This White Paper presents the results of that analysis as a series of technical guidelines intended to support NFC standardisation and technology implementation activities. These technical guidelines are provided as input to standardisation bodies and fora, to support their standardisation of NFC technology. This White Paper should also provide valuable information to other third parties who are defining and developing in their roles within the Mobile NFC ecosystem The technical guidelines presented in this White Paper have been prepared with information that was available as at March 2007. Versions of this White Paper will subsequently be augmented and include technical guidelines covering:. The Host Controller Interface (HCI). The UICC run-time environment. Over-The-Air (OTA) provisioning UICC to NFC Chip Interface (lower OSI layers) The GSMA NFC Project endorses ETSI TC SCP TEC to focus on the Single Wire Protocol (SWP) proposal. Mobile to contactless reader interface It is recommended that ISO-JTC1/SC17/WG8 standards address the specification for the field load effects due to NFC mobile phones. It is recommended that a specific class should be defined accordingly. Operation of the mobile NFC device with low battery power Two solutions are considered: Solution 1: Operation with power supplied by the low-battery in the mobile device Solution 2: Operation with power supplied by an external field 2007, GSMA. All Rights Reserved Appendix 1

Mobile NFC Technical Guidelines vs1 For power down mode, Solution 2 is recommended. Solution 2 can be achieved in two ways: a) Partially upgrading existing contactless readers, or b) Restricting the UICC-NFC Power consumption The latter option (b) is recommended. It is recognised however that this solution will not be available in the short term and therefore it is recommended that solution 1 is desirable at this time. Operational range The operational range between two NFC devices was analysed. For NFC Device 1 and 2 operating in Peer-to-Peer mode or Reader mode, an operational range of 0 to 4 cm is targeted. In card emulation mode, the choice of operating range is currently manufacturer specified. Depending on the application, contactless reader manufacturers are encouraged to define a minimal operating range (e.g. 0 to 4cm range). Transaction duration Regarding transaction duration, in battery-on mode, the targeted transaction duration between an NFC mobile device and Reader shall be less than or equal to 250ms to meet Service Provider requirements. Application selection For new contactless infrastructure, it is recommended that explicit (i.e. reader based) application selection mechanisms are employed. An initial analysis is included in section 8.5.2 of this document. A further analysis of the application selection mechanisms will be part of a next version of this technical guidelines White Paper. Radio Frequency layer privacy issues Radio Frequency (RF) layer privacy issues were analysed. It is recommended that the card identifier (termed UID in ISO 14443 type A and PUPI in ISO 14443 type B) is randomly computed in order to avoid privacy issues. Automatic mode switching Automatic switching between different NFC modes (reader, card emulation, P2P) was analysed. It is recommended that an NFC enabled mobile automatically alternates between poll sequence and listen sequence modes. Furthermore, it is recommended that the user can override the automatic selection between modes, thus resulting in a manual selection between modes. In that case, it is recommended that listen mode is the default mode. Appendix 2 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 Automatic NFC mode enablement Automatic enabling of the NFC module (in a mobile NFC device) was analysed. It is recommended that the user can activate/deactivate the NFC module. The activation/deactivation mechanism for the user needs to be as simple and accessible as possible, for example via a physical button or soft key. In order to inform the user it is recommended that a status icon (active, non active) is displayed on the mobile phone main screen. Multi-application UICC framework The multi-application UICC framework was analysed. The following features for existing or future technologies and standards should be implemented in the UICC developed for NFC services: ETSI SCP. NFC Application Programmer Interface (API) in the UICC: The on-card application shall have different levels of access to the API depending on Security Domain (SD) privileges.. NFC API shall allow UICC applications to use the NFC Controller in Peer-to-Peer mode and Reader/Writer mode. OTA application management Global Platform. Interoperable Security Domain creation. Application management 2007, GSMA. All Rights Reserved Appendix 3

Mobile NFC Technical Guidelines vs1 Section 2: Introduction Twenty of the worlds largest Mobile Network Operators (MNOs), have been working together, in a GSMA initiative, to create and define a global approach to enable Near Field Communications (NFC) services on mobile phones. This initiative will serve to answer key customer requirements for new NFC services on mobile phones. Furthermore, it aims to provide a common MNO viewpoint, which is key to enable the development of a new market and to prevent market fragmentation. In February 2007, the GSMA NFC initiative released a Mobile NFC Services White Paper [1]. That White Paper was produced from an analysis of the mobile NFC ecosystem and related business requirements. 2.1 Reference Documents No. Document Title Document Reference 1 GSMA Mobile GSMA_153_WP510_001, February 2007. NFC Services White Paper (Available for download from: http://www.gsmworld.com/news/press_2007/index.shtml) Appendix 4 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 Section 3: Purpose of the Document This White Paper is produced as a result of technical analysis performed by the MNOs in the GSMA initiative regarding:. The Universal Integrated Circuit Card (UICC) to NFC Chip interface. The Mobile to Contactless reader interface. The Multi-application UICC framework This White Paper presents a series of technical guidelines intended to support NFC standardisation and technology implementation activities. These technical guidelines are provided as input to standardisation bodies and fora, to support their standardisation of NFC technology. This White Paper should also provide valuable information to other third parties who are defining and developing in their roles within the Mobile NFC ecosystem. This version of the White Paper only addresses the UICC to NFC Chip interface, the Mobile to Reader interface and the Multi-application UICC framework. Future versions will subsequently be augmented and include technical guidelines covering:. The Host Controller Interface (HCI) to Single Wire Protocol (SWP) interface. The UICC run-time environment. Over-The-Air (OTA) provisioning This document has been prepared with information that was available as at March 2007. 2007, GSMA. All Rights Reserved Appendix 5

Mobile NFC Technical Guidelines vs1 Section 4: General Architecture for Mobile NFC Services Figure 1: Reference Mobile NFC Architecture BB Celular Mobile Station Holder Service Provider Application Owner App SIM OS Contactless Interface Contactless Merchant POS Application Provider Information System Application Owner Information System OTA NFC Service Manager Contactless Service Management Platform Trusted Service Manager (performed by MNO or Trusted Third Party) SIM Card Management System (CMS) Card Issuer (MNO) SIM Card Preconfiguration System SIM Card Manufacturer (Smart Cards Provider) Local Connection (via Contactless Reader) Appendix 6 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 Figure 1 shows the reference Mobile NFC architecture. The roles of the various entities in the Mobile NFC ecosystem are described in the GSMA s Mobile NFC Services White Paper (see Section 2.1 for reference). This version of the White Paper focuses on:. The UICC to NFC Chip interface (see section 7). The Mobile to Contactless reader interface (see section 8). The Multi-application UICC framework (see section 9) As stated in the Mobile NFC Services White Paper, the preferred secure element for NFC services is the UICC. Furthermore, for portability reasons the preferred location for NFC applications is also the UICC. 2007, GSMA. All Rights Reserved Appendix 7

Mobile NFC Technical Guidelines vs1 Section 5: Project Definition 5.1 GSMA The GSMA is the global trade association representing over 700 GSM mobile phone operators across 215 countries of the world. The primary goals of the GSMA are to ensure mobile and wireless services work globally and are easily accessible, enhancing their value to individual customers and national economies, while creating new business opportunities for operators and their suppliers. Hence the GSMA provides the ideal forum to represent the MNO community for the purposes of defining mobile NFC services. MNO collaboration in this area ensures a consistent approach in the development of mobile NFC services among mobile operators and other involved parties in the industry and hence promotes interoperability, leading to standardisation on a global scale and prevents market fragmentation. 5.2 Stakeholders Twenty of the largest MNOs are working together to develop a common vision on mobile NFC services, promoting MNO s capabilities and value add for the mobile NFC ecosystem. The MNOs involved in this mobile NFC initiative are: Bouygues Telecom, China Mobile, Cingular Wireless, Elisa, KPN, KTF, Mobilkom Austria, NTT DoCoMo Inc., Orange, Rogers, SFR, SKTelecom, Telefonica Móviles España, Telenor Mobile, TeliaSonera, Telecom Italia Mobile, TMN, Turkcell, Vodafone and 3. They represent about 45% of the worldwide GSM market, which addresses over 800 million customers. 5.3 Approach The following approach has been adopted in this project:. Analyse the key mobile NFC use cases. Analyse the mobile NFC ecosystem and perform an end-to-end value chain analysis. Analyse the MNO s role within this ecosystem. Extract the mobile NFC business requirements needed to make mobile NFC a success and deliver value to all entities in the value chain Appendix 8 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1. Assess the impact of the business requirements to the standards relevant to the NFC ecosystem (specifically ETSI, Global Platform and the NFC forum) Several Work Packages (WPs) have been defined in this project. These are summarised below:. Mobile NFC Use Case Analysis and Business Requirements. Architecture Definition UICC-NFC Chip. Architecture Definition Mobile-Reader. Architecture Definition Multi-application UICC framework. Architecture Definition UICC run-time environment. Architecture Definition OTA provisioning 5.4 Deliverables The project started in early September 2006 and aims to deliver several outputs in early 2007. The deliverables from this project are a series of White Papers, which are:. An Ecosystem White Paper derived from the NFC Ecosystem analysis and related Business Requirements, which was released in February 2007 (see [1]).. A Technical Guidelines White Paper including the architectural vision of the MNOs for a Mobile NFC Solution, - this document; This release of the technical guidelines White Paper focuses on the following interfaces:. The UICC to NFC Chip interface. The Mobile to Contactless reader interface. The Multi-application UICC framework Subsequent releases of the technical guidelines will cover the following interfaces:. The HCI to SWP interface. The UICC run-time environment. Over-The-Air provisioning 2007, GSMA. All Rights Reserved Appendix 9

Mobile NFC Technical Guidelines vs1 Section 6: Security Issues Security is an important issue. Although end-to-end security has not been analysed in this White Paper, it is addressed in the following individual cases:. UICC-NFC Chip interface. Multi-application UICC framework. OTA Provisioning. Run-time environment Security aspects regarding OTA provisioning and run-time environment will be addressed in future versions of this White Paper. Appendix 10 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 Section 7: UICC to NFC Chip Interface 7.1 Introduction Since the UICC has been identified as the recommended secure element (SE) for NFC services, a dedicated link between the UICC and the NFC chip is required. The objective of that link will be to allow the UICC control of the NFC Chip and data exchanges, even if the handset is off. At the time of the study, several technical propositions were proposed at the ETSI-SCP level. The methodology employed in the analysis of theses propositions was as follows:. Assessment of each known ETSI-SCP technical propositions against the ecosystem and business requirements as provided by the MNOs involved in this initiative. Selection and recommendation of a preferred solution. In a first approach, the following propositions were considered to be within scope: 1. SCPt060718 : Single Wire Protocol (SWP) [Gemalto] 2. SCPt060582 : NFC-WI (formerly known as S_C) [NXP/Sony] 3. SCPt060578 : T=x [Nokia] 4. MMC encapsulation [Gemplus] 5. ST [ST Microelectronics] In the final week of the analysis three further solutions were identified and considered in the analysis: 6. SCPt060763 : Sony [Sony] 7. SCPt060778 : Multi Protocol Interface (MPI) [Nokia] 8. SCPt060735 : DIOCTL (S1C) [NXP] Solutions 4 and 5 were withdrawn and solutions 6 and 7 were rejected by the workgroup due to insufficient maturity and, in the current state, do not seem to fulfil the ecosystem and business requirements. 2007, GSMA. All Rights Reserved Appendix 11

Mobile NFC Technical Guidelines vs1 Finally, the following technical propositions were considered in scope and assessed: 1. Single Wire Protocol (SWP) [Gemalto] 2. NFC-WI (formerly known as S_C) [NXP/Sony] 3. T=X [Nokia] 4. DIOCTL (S1C) [NXP] 7.2 Technical propositions The pros and cons of each of the above technical solutions were assessed and are presented below: 7.2.1 SWP Table 1: SWP Pros and Cons Pros Can be combined with high speed protocol (USB) UICCs. More mature, comprehensive specification, available for review. Supports Type A, B, C Supports battery off. Full Duplex supported Silicon available now. Viewed as widely supporting MNOs requirements, and therefore widely supported by MNOs.. Two suppliers have SIM cards which support this technology today (Oberthur, Gemalto). At least two silicon suppliers on the mobile side at the moment (Inside Contactless and NXP) Cons Mifare not yet available. Handling of the contactless protocol may be more complex in the UICC operating system since the UICC has no time reference of the contactless transaction. Appendix 12 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 7.2.2 NFC-WI (S2C) Table 2: S2C Pros and Cons Pros Supports Type A, (and also Type C, but the latter was not considered within the scope of the project). Type B is theoretically supported. Supports Battery Off Mifare supported Proven and stable technology ISO 14443 friendly, and simple Cons Potential Intellectual Property issues may arise No support for battery off in card emulation mode currently. Can not be combined with USB high speed protocol Type B has not yet been implemented. Speed negotiation not supported (Can not switch between different ISO speeds defined for air interface.) Currently only one silicon supplier (NXP) 7.3 T=X Table 3: T=X Pros and Cons Pros Insufficient technical information available to undertake an appropriate assessment. Cons Insufficient technical information available to undertake an appropriate assessment. Direct link not supported. Protocol parameter selection procedure is time consuming during operation, which would impact response times during NFC use. 2007, GSMA. All Rights Reserved Appendix 13

Mobile NFC Technical Guidelines vs1 7.4 DIOCTL Table 4: DIOCTL Pros and Cons Pros ISO14443 supported. Mifare supported. Compatible with USB HSP. Limited technical information available to undertake an appropriate assessment. Cons No silicon currently available and no estimated date. Battery-off (battery empty) mode support: not confirmed (silicon supporting this functionality not currently available.) Variable speed available raises concerns about interoperability between different implementations and legacy infrastructures. Limited technical information available to undertake an appropriate assessment. 7.5 Solutions In the light of the work conducted by this working group, the GSMA NFC Project would like to highlight the following points:. the NFC-WI interface, contributed as ECMA-373 in document SCPt060543 cannot be considered a candidate for the UICC-CLF interface due to foreseen incompatibility with the UICC s USB high-speed interface. SCPt060735 (DIOCTL by NXP) seem to be in an early development stage and in the current state do not seem to fulfil the GSMA NFC Project or ETSI requirements. At the time of writing NXP has withdrawn this proposal. the proposal contributed as SCPt060718 (SWP by Gemalto, Giesecke & Devrient, Sagem-Orga) will be the best fit for the GSMA NFC Project requirements and to the working group s understanding for the ETSI TS 102 412 requirements. It should however be mentioned that the GSMA NFC Project endorses SWP as a physical (i.e. the analogue part) interface and welcomes further discussions about the upper logical protocol. 7.6 Recommendations Regarding the UICC to NFC Chip interface (lower OSI layers) and keeping in mind the tight schedule for Rel-7 completion in ETSI, the GSMA NFC Project endorses ETSI TC SCP TEC to focus on the SWP proposal. Appendix 14 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 Section 8: Mobile to Reader Interface This section primarily describes, from an MNO point of view, the key issues surrounding the Mobile NFC mobile to Contactless reader interface. In addition to this topic, other technical points are also addressed. Issues are grouped into three types, depending upon whether the issues are regarding all three modes of NFC, card emulation mode, or peer-to-peer and reader mode. For each issue, an overview of the issue is provided, followed by a brief description of possible solutions and a recommendation for the preferred solution. General Issues in the Mobile to Reader Interface 1. The compatibility of NFC mobile phones on existing contactless infrastructures 2. Compatibility for new contactless infrastructure 3. Whether there is an automatic or a manual (user selected) activation of the NFC radio module marketing issue (e.g. Bluetooth enablement). 4. Privacy issues 5. Automatic switching between the different NFC modes Card Emulation mode issues. NFC mobiles phones are not covered in the current ISO-JTC1/SC17/WG8 standards, for example field load effects. The performance achievable by NFC mobile phones in the "Power Off' case. Multi-application selection (implicit or explicit selection of NFC applications) Peer-to-Peer and Reader Mode Issues. Communication range of a mobile operating in reader mode and peer-to-peer mode. 2007, GSMA. All Rights Reserved Appendix 15

Mobile NFC Technical Guidelines vs1 8.1 Radio-frequency compatibility of NFC mobile phone 8.1.1 Statement of the problem Contactless cards and contactless readers are compliant with the ISO 14443 standard and in accordance with the corresponding test methods, as defined in ISO/10373-6. However, NFC mobiles phones are not covered in the current ISO-JTC1/SC17/WG8 standards, for example the topic of field load effects is not considered. In order to prevent interoperability issues with existing and future contactless infrastructure (i.e. on the radio interface between NFC phones and contactless readers), test methods dealing with NFC mobile phones need to be defined. With respect to this topic, the ISO/IEC JTC1/SC17/WG8 committee has launched a work item in order to investigate any interoperability issues between ISO 14443 standard and NFC devices. NFC mobile phones shall comply with ISO 18092 and with ISO 22536 (test methods on the RF interface). Adjustments between ISO 14443 and ISO 18092 and their corresponding test methods may be needed. 8.1.2 Solution As ISO 14443, ISO 18092 and ISO/10373 have already defined a specific class for cards (i.e. class 1 PICC), a specific class shall be defined according to NFC phones characteristics. 8.1.3 Recommendation It is recommended that ISO-JTC1/SC17/WG8 standards address the specification for the field load effects due to NFC mobile phones. It is recommended that a specific class should be defined accordingly. Appendix 16 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 8.2 "Battery low" use case Figure 2 defines various available power thresholds and power regions within a mobile NFC Device. Full Power REGION 1 Threshold 1 REGION 2 Threshold 2 REGION 3 Zero Power Figure 2: Power levels within a Mobile NFC device Region 1 (Full Power to Threshold 1): All functions are available in the mobile device. Region 2 (Threshold 1 to Threshold 2): In this region, all the functionalities of the mobile phone are shut down, except the clock module and some other remaining functions. The mobile phone is put in this mode when a first voltage threshold (i.e. Threshold 1) of the battery is reached. Region 3 (Threshold 2 to Zero Power): No functions are available in the mobile device. 2007, GSMA. All Rights Reserved Appendix 17

Mobile NFC Technical Guidelines vs1 8.2.1 Statement of the problem This issue is covers Card emulation mode only and concerns operation of the mobile NFC device with zero or low available power from its own battery source (i.e. the available power is in Region 2). When the battery of the mobile phone is low, the user might need to make use of certain NFC services (e.g. getting access in to and out of public transport networks). In this mode, the NFC chip and the UICC shall be powered during a NFC transaction. It is assumed that all the other functionalities of the mobile phone are switched off (e.g. MMI). 8.2.2 Solution Two solutions are proposed: Solution 1: Operation with power supplied by the low-battery in the mobile device In this solution:. When the mobile device is in Region 2, the remaining power of the battery allows a user to get about tens of contactless transactions.. The duration that a mobile device can remain in Region 2 is recommended to be at least 12 hours.. When the mobile device is in Region 3 all the functions are shut down, this includes NFC functions. Solution 2: Operation with power supplied by an external field In this mode, both the NFC chip and the UICC are powered by the field during an NFC transaction (in card emulation mode only). One can expect that some performance degradations may occur (for example: the communication distance or the transaction duration). The maximum power consumed by the NFC chip and by the UICC should be standardised. Currently, the field strength that is needed to power both the UICC and NFC chip is higher than the minimum field strength that any contactless reader can emit. One technical option to solve this issue is for contactless readers to emit a higher field strength than the minimum value (i.e. 1.5 A/m) defined in ISO 14443. This would imply an upgrade to existing (installed) contactless readers and to the development of new readers. Another technical option is to lower the power consumption of the UICC and NFC chip. In this case, user expectation could be met with no impact to the existing reader infrastructure. Appendix 18 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 8.2.3 Recommendation For power down mode, solution 2 is recommended. Solution 2 can be achieved in two ways: a) Partially upgrading existing contactless readers, or b) Restricting the UICC-NFC Power consumption The latter option (b) is recommended. It is recognised however that this solution will not be available in the short term and therefore it is recommended that solution 1 is desirable at this time. 8.3 Operational range 8.3.1 Statement of the problem The operational range defines the communication range when the mobile phone is operating in reader mode, peer-to-peer mode or card emulation mode. For user convenience, it is appropriate to define a minimum communication range (see Figure 3). 4 cm NFC Device 1 or contactless reader NFC Device 2 Figure 3: Operational range between two NFC devices 8.3.2 Recommendation For NFC Device 1 and 2 operating in Peer-to-Peer mode or Reader mode, an operational range of 0 to 4 cm is targeted. 2007, GSMA. All Rights Reserved Appendix 19

Mobile NFC Technical Guidelines vs1 In card emulation mode, good user convenience may require a minimal communication distance between contactless readers and NFC mobile phones. However, the ISO 14443 standard does not specify any operating range. The choice of operating range is currently manufacturer specified. Depending on the application, contactless reader manufacturers are encouraged to define a minimal operating range (e.g. 0 to 4cm range). Note ISO 14443 operating range is known as operating volume. 8.4 Transaction duration 8.4.1 Definition Transaction duration is defined as the time required to complete a transaction including anticollision, authentication procedures as well as reading/writing of data at the NFC mobile device, and also includes the time required to complete corresponding data processing at the Reader/Writer. 8.4.2 Statement of the problem The NFC mobile device must be compatible with legacy infrastructure, as well as future infrastructure. The transaction duration through an NFC mobile device must be comparable to a contactless card. The intention is to ensure that the transaction duration will be the same as that achieved with a contactless card, at least in battery on mode (e.g. European market expectations for transaction duration in public transport applications is less than or equal to 250ms; in Japan the corresponding requirement is less than or equal to 200ms). Note, it is very likely that the transaction duration will decrease over time due to, for instance, improvements in the UICC and NFC chipset technology and software optimisation. The following factors affect the transaction duration: 1. Execution of the application on the Secure Element 2. The operational clock of the chip processing the application 3. Bit rate between the contactless reader and the application, which includes the NFC chip and Secure Element 4. Time to process data exchanged between the NFC chip and Secure Element 8.4.3 Recommendations In battery-on mode, the targeted transaction duration between an NFC mobile device and Reader shall be less than or equal to 250 ms to meet Service Provider requirements. Appendix 20 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 8.5 Application selection 8.5.1 Statement of the problem One of the promises of NFC technology is interoperability with a wide range of contactless technologies. For example, card emulation mode must deal with several contactless card technologies, provided by different manufacturers in order to maintain backwards compatibility. This fact implies different proprietary and standard technologies working simultaneously in the same physical device (e.g. a mobile phone). Therefore it is necessary to implement procedures to select the appropriate card technology that is to be emulated. The following technologies are considered to be the most relevant. ISO 14443A, used to a certain extent by proprietary technologies such as:. Philips MIFARE Classic, Ultralight and DESFire flavours.. EMV ISO 14443B, used to a certain extent by proprietary technologies such as:. Calypso. EMV ISO 18092, used to a certain extent by proprietary technologies such as:. Sony Felica Current analysis leads to some preliminary conclusions that require making a decision focusing in the trade-off between usability, security and supported technologies. Assuming that the NFC controller can select the appropriate technology at the RF layer (ISO 14443- A, ISO 14443-B or Felica), the main issues occur at anti-collision and application selection levels. Figure 4 shows a simplified flow diagram illustrating the decision points once the RF technology has been selected and communication is in progress. 2007, GSMA. All Rights Reserved Appendix 21

Mobile NFC Technical Guidelines vs1 Use proprietary technology 2 flavour A Use proprietary technology 1 Proprietary commands Use proprietary technology 2 flavour B Use proprietary technology 3 EMV Field detection Proprietary Technology 1? Proprietary Technology 2? ISO 14443-4 ISO 7816 Proprietary commands Use proprietary technology 4 Use nonproprietary technology 5 RF Layer Anticollision Transport Application Figure 4: Application selection problem Figure 4 depicts the application selection problem. Decisions can be based on information previously extracted from the signal, or assuming a certain technology is being used (i.e. uninformed decisions). In some cases uninformed decisions could be solved by a trial and error selection method, but this would result in slower transaction times and impacts the user experience due to the time it would take to restart the communication. The trial and error selection method can be limited by application requirements, which could limit the maximum transaction speeds to an average time of 250mS. However, some applications, such as public transport, may require shorter transaction durations (e.g. 100mS). If the trial and error method is used excessively, this time requirement could be jeopardised. Therefore it is necessary to limit the maximum amount of retries possible or to avoid this method altogether. Another case which needs to be considered is when the reader supports different contactless technologies. In this case, both reader and NFC card could start swapping the selection method. This could lead to the divergence in the selection algorithm and deadlock. Note:. A legacy contactless system means an old and/or existing operational contactless system.. Explicit selection is when the application in the mobile device is automatically selected by the reader without any user interaction (see Figure 5).. Implicit selection is when the operating system running in the mobile device automatically selects the default NFC application (see Figure 6). Appendix 22 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 Reader Card 1. Anti-collision and initialization procedure. 2. A card is selected. 3. Select application command. 5. Card response. 4. The card operating system selects the application based on the dedicated select application command. Sending of application commands. 6. Application command (eg. read/write). 7. Card response. Figure 5: Explicit Selection Reader Card 1. Anti-collision and initialization procedure. 2. A card is selected. 3. The card operating system automatically selects the application. The reader does not need to select an application. Sending of application commands. 4. Application command (eg. read/write). 5. Card response. Figure 6: Implicit selection 2007, GSMA. All Rights Reserved Appendix 23

Mobile NFC Technical Guidelines vs1 8.5.2 Recommendation and Solutions suggested Based on convenience and usability as the main adoption drivers, the following guidelines could improve the user experience of NFC services:. Compliance protocols and procedures for service provider infrastructure must be defined for existing service providers and new entrants. A requirement could be the enforcement of explicit selection in the reader, upgrading its software and other legacy infrastructures if necessary. Therefore, for new contactless infrastructure, it is recommended that explicit selection mechanisms are employed, for example adopting the ISO-7816-4 AID (Application Identification) command or by using MAD (Mifare Application Directory). In the case where legacy systems do not adopt implicit selection, owners of those systems are encouraged to upgrade their infrastructure so as to support explicit selection mechanisms.. A temporary solution could be the definition of implicitly selected applications for each logical channel of the card. In this case there would be one predefined application by protocol type, but several applications can be mapped on the same protocol. The mapping between the logical channel and the contactless protocol used has to be done on the UICC. It is mandated that the user can configure the default application list.. Implementation of a configurable NFC/UICC supported technologies list (or firmware), which discards the emulation of a selectable set of technologies. This could prevent uninformed decisions and reduce the use of the trial and error selection method. Since some technologies are not established in certain geographies, the MNO could tailor the emulated technology in order to improve performance and adapt the solution to the target market. List/Firmware configuration should be updatable by the MNO using the OTA (Over The Air) channel.. In cases where the application overlap cannot be avoided (e.g. when the NFC mobile contains two contactless credit cards and the reader accepts both types) the user will have to choose the right application. This application will be updated in the UICC as the default application and could pose security issues. These recommendations aim to minimise frequent user interaction in application selection, except in cases where explicit user selection is unavoidable. It is acknowledged that in some cases, explicit user application selection is the preferred and simplest solution,- for example credit card selection should be based on user preference. Note explicit user application selection is not possible in battery off mode. These recommendations are based on an initial analysis of application selection mechanisms. A further analysis will be included in the next version of the White Paper. Appendix 24 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 8.6 RF Layer Privacy Issues Each time a reader communicates with a mobile device it retrieves a User Device Identification number; this is termed UID for ISO 14443 Type A contactless systems and PUPI for ISO 14443 Type B contactless systems. 8.6.1 Statement of problem A privacy issue exists in exchanging the UID or PUPI. It can potentially be captured by a third party and duplicated. Hence a security risk exists in that the UID or PUPI could be used to obtain access/entry to premises. The fact that the UID/PUPI is fixed would mean that the mobile device could be traced by a third party, across range of contactless services, without the knowledge of the user. 8.6.2 Recommendation and Solution The UID (card identifier in ISO 14443 type A) and PUPI (card identifier in ISO 14443 type B) shall be randomly computed in order to avoid privacy issues (the card identifier is used during the anticollision procedure). In case some existing applications make use of a fixed UID, it is highly encouraged that application providers upgrade their infrastructures in order not to rely on a fixed UID. 8.7 Automatic switching between the different NFC modes 8.7.1 Statement of the problem Poll sequences and Listen sequences are employed to enable NFC mobile devices to operate in: Card Emulation mode, Peer-to-Peer mode and Reader mode. In poll mode (applicable to Reader and Peer-to-Peer modes), the NFC mobile device can detect NFC devices as well as tags or contactless cards. In the current NFC draft specification, the timing of each sequence is left to the implementation. Since poll mode consumes more power, this may limit the battery life of the mobile so this mode needs be carefully monitored. On the other hand, listen mode (applicable to Card Emulation mode) is not power consuming. One can assume that mobile phones shall be in listen mode most of the time in order to allow fast card emulation transactions. Any impact to customer experience should be taken in to consideration. 2007, GSMA. All Rights Reserved Appendix 25

Mobile NFC Technical Guidelines vs1 8.7.2 Solution There are 2 ways to handle this issue: Solution 1: Automatic selection The user does not have to switch-on the poll mode. Hence, when the user brings his mobile phone near a tag or a contactless card, a transaction will automatically be triggered. The timing of the poll sequences is implementation specific. Solution 2: Manual selection In this mode, the user selects the poll mode. A poll sequence has to be triggered when the device operates in Peer-to-Peer and in Reader/writer mode. Furthermore, one can expect that there are no tight constraints regarding the duration of the transaction. 8.7.3 Recommendation It is recommended that a NFC enabled mobile shall automatically alternate between poll sequence and listen sequence. Furthermore, it is recommended that the user can override the automatic selection between modes, thus resulting in a manual selection between modes. In that case, the listen mode shall be the default mode. Poll sequences and listen sequences shall alternate, the time interval between two successive poll sequences shall be between 1 and 2 seconds, keeping in mind that 1 second is the target. However, the impact on the battery life shall be kept to a minimum and should be less than 10%. 8.8 Automatic enabling of the NFC module 8.8.1 Statement of problem Automatically enabling the NFC module could result in unintentional contactless transactions. The short range capability of the NFC technology limits the level of unintended contactless transactions however, such unintentional transactions could still occur. 8.8.2 Solution One solution is to allow the user to activate/deactivate the NFC module. Appendix 26 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 8.8.3 Recommendation It is recommended that the user shall be able to activate/deactivate the NFC module. The activation/deactivation mechanism for the user needs to be as simple and accessible as possible, for example via a physical button or soft key. In order to inform the user, a status icon (active, non active) shall be displayed on the mobile phone main screen. 2007, GSMA. All Rights Reserved Appendix 27

Mobile NFC Technical Guidelines vs1 Section 9: Multi-Application UICC Framework This section addresses the Multi-application UICC framework issues and design choices involved with running multiple applications within the UICC of an NFC enabled mobile device. It is acknowledged that other architectures are possible, however the scope of this work is limited to UICC based applications. During the analysis, the main requirements for a multi-application UICC framework have been defined, the focus has been set specifically on:. UICC reference architecture. Security domain separation and hierarchy As one of the business requirements is the portability of contactless services based on the UICC, it should be assumed that all the applications should be stored completely inside the UICC. This can have memory requirement implications that have to be managed prior to the installation of the application from the server side. 9.1 General Issues 1. Sharing and management of card memory resources. 2. Fire-walling and inter-application communication. 3. Anti-collision policies and Multi-application selection (see section 8.5) 9.2 Proposed Solutions The UICC, as used by MNOs, is based on ETSI Smart Card Platform standards which aim to comply with Global Platform standards. The Global Platform model defines a hierarchical structure of privileges, addressing the issue of extending UICC resources to third parties. Figure 7 depicts the NFC mobile device as three main components: the application processor, the NFC chip and the UICC card. The UICC contains a hierarchy of Security Domains in accordance with the Global Platform standard: The Issuer security domain created for the issuer of the secure element (in this case the MNO) and the Secondary Security Domains created on demand for the different Service providers that have installed their applications in the UICC. Appendix 28 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 The UICC will be designed to comply with NFC service requirements and on the interfaces with the other components of the ecosystem. The NFC mobile device (as shown in Figure 7) offers three different interfaces: the contactless one, the OTA one, and the MMI. MNO Trusted Third Party Mobile Device Browser MMI JSR 257 Midlet JSR 177 Modem Application Processor USIM SCWS STK Proactive Commands Issuer Security Domain Servlet NFC Application Secondary SD 1 App 1 App 2 App n SSD 2 App SSD n App n API NFC Peer to Peer Interface (LLCP) NFC Controller R/W Interface Card Emulation Interface NFC Device NFC Tag Merchant POS Figure 7: Mobile NFC device functional architecture 2007, GSMA. All Rights Reserved Appendix 29

Mobile NFC Technical Guidelines vs1 9.3 Recommendations MNOs require interoperability of all UICCs used to run NFC services. The following features for existing or future technologies and standards should be implemented in the UICC developed for NFC services: ETSI SCP. NFC Application Programmer Interface (API) in the UICC: The on-card application shall have different levels of access to the API depending on Security Domain (SD) privileges.. NFC API shall allow UICC applications to use the NFC Controller in Peer-to-Peer mode and Reader/Writer mode. OTA application management (load, install, Extradite, remove) Global Platform. Interoperable Security Domain creation (Using standardised installation command). application management (load, install, Extradite, remove) These recommendations are based on an initial analysis. Further analysis, solutions and recommendations will be presented in subsequent versions of this technical guidelines White Paper. Appendix 30 2007, GSMA. All Rights Reserved

Mobile NFC Technical Guidelines vs1 Section 10: Acronyms Acronym 3GPP ETSI ETSI-SCP GSM GSMA IPR ISO MNO Mobile-TV NFC OTA SE SIM SMS SP TSM UICC Meaning Third Generation Partnership Project European Telecommunications Standards Institute European Telecommunications Standards Institute-Smart Card Platform Global System for Mobiles GSM Association Intellectual Property Rights International Standards Organisation Mobile Network Operator Mobile Television Near Field Communication Over The Air Secure Element Subscriber Identity Module Short Message Service Service Provider Trusted Services Manager Universal Integrated Circuit Card The UICC is a smart card which contains account information and memory that is used to enable GSM cellular telephones. One of the applications running on the smart card is the SIM, or Subscriber Identity Module. In common parlance the term "UICC" is not used but the phrase "SIM" is used to describe the smart card itself. For further information please contact: Dr. Nav Bains nbains@gsm.org 2007, GSMA. All Rights Reserved Appendix 31

GSMA London Office 1st Floor, Mid City Place, 71 High Holborn, London WC1V 6EA, United Kingdom T +44 (0) 20 7759 2300 www.gsmworld.com GSMA/NFC TECHv2/11.07