mobile NFC technical guidelines

(1)

technical guidelines

November 2007

(2)

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.

(3)

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.

(6)

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.

(7)

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 run-time (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.

(8)

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 on-card 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.

(9)

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.

(10)

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

(11)

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

(12)

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

(13)

2.2 Project Deliverable Documents

# Document Title Document Reference

1 GSMA Mobile NFC Services White Paper

GSMA_153_WP510_001, February 2007. (Available for download from:

http://www.gsmworld.com/news/press_2 007/index.shtml)

2 GSMA Mobile NFC Technical Guidelines White Paper V1.0

GSMA_153_WP510_002, April 2007. (Available for download from:

http://www.gsmworld.com/news/press_2 007/press07_34.shtml)

3 GSMA Mobile NFC Technical Guidelines White Paper V2.0

GSMA_153_WP510_003, August 2007 (Available for download from:

http://www.gsmworld.com/news/press_2 007/)

(14)

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.

(15)

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)

(16)

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)

(17)

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

(18)

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

(19)

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

Figure 2 : Option 1 – Single SE visible to reader at any given time

Other SE SD Card Mobile Phone 1. SIM CARD 2. SD CARD 3. Other CARDS User action Choice of the SE Select

(20)

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.

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.

Other SE SD Card Mobile Phone 1. ____ 2. ____ 3. ____ 4. ____ 1. ____ 2. ____ 3. ____ 4. ____ Software Component AID SE Identifier Select AID

(21)

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.

Other SE SD Card Mobile Phone Software Component Scanning of one SE after the other until the application

is found

* there is no scanning order Select SE

(22)

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.

(23)

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.

(24)

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.

Figure 5 : Generic overall transaction time in a contactless interaction

Card is moved close to Reader

Transaction

Overall

transaction time

Initialization, anticollision, select application

Reader Card

(25)

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 inter-working 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.

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

Phone is moved close to Reader

polling loop, mode switch, UICC wake-up

Transaction

Overall

transaction time

Initialization, anticollision, application select

Reader Mobile Phone

(26)

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

(27)

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

(28)

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.

(29)

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

(30)

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

(31)

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

6.4.2 Smart Card Web Server

Pros Cons

Proven and tested technology Only text based user interace Highly interoperable between different mobile

terminals

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.

Pros Cons

Uses built-in browser of mobile NFC device to

render data New technology in UICC

For simple web server content quite high interoperability

It is difficult to define the exact look and feel of the interface since the browser’s rendering engine finally controls the exact layout OTA provision of user interface

Interactive user interaction with typical browsers is bad: Many key clicks necessary to input information

Java Card Applet and UI is on the same media. Changing terminals is very easy for the customer

Different versions of web pages have to be stored to adapt for UI for different browsers and screen resolution in the terminal.

(32)

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.

Any of the above options (or combinations thereof) are possible; the choice is left to the operator implementation.

Pros Cons

User interface is fully customisable API is not the same or does not work in the same way on different mobile phones

User interaction can be perfectly adapted to service provider needs

Test effort quite high: NFC services have to be tested or even adapted for new terminals coming to the market

Expensive UICC memory is not used 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.

(33)

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.

(34)

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

(35)

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

(36)

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

(37)

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.

Figure 10 : Initialisation Sequence Diagram

* Note: Some of the service approval functions performed by the TSM can also be performed by the MNO.

1. Service Provider provisioning

2. TSM Registration

3. Service provisioning/creation

*Service Approval request (Applets and Midlets and list of AIDs, Service Name)

Ack (Applets and Midlets approved by card-issuer)

Service Registration (Approved Applet(s) and Midlet(s) and list of instanciation data)

Verify/generate AIDs, inocuity of applications

Store application/commands hash

SP connection request (SP ID) SD creation request TSM registration request Register TSM Reserve SD for SP Ack (SP SD AID)

Ack (Service ID) Create Service Ack (TSM ID)

Ack (SD AID)

SP TSM Card-Issuer

(38)

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.

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.

4. End user subscription

5. SD creation (if not created in factory)

6a. Applet installation (if not pre-installed)

6b. Midlet installation (if not pre-installed) 7. Applet personalization

Signature verification and Midlet installation under a Protection Domain End-user subcription to NFC service

Service Installation Request (User ID, Service ID) Process subcription

Check if SD already created? SD creation request (User ID, SD AID) SD creation

Ack (SD temporary keys) Ack

Ack

Ack Update SD keys(SD final keys)

End-user acceptance and/or

authentication might be required

prior Applet

installation Applet installation

Get perso data

Perso commands preparation Ack (Perso Data)

Applet personalisation

Retrieve Applet and ACP file and prepare installation commands Token request (Applet AID,list of commands)

Ack (Tokens)

Token verification PoR

Aliasing

Inform on installation status Retrieve Midlet

Inform SP that NFC Service is operational Send SMS: Service is operational

SP TSM Card-Issuer End-User

Retrieve Midlet

User acceptance Request Midlet

Download signed Midlet Push Wap (Midlet URL)

(39)

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.

UICC Card Issuer TSM ISD SP #1 SP #2 SP #3 SP #3 SP #4 SP #4 SP #2 SP #1 MNO Network Control & encryption Token Generation Policy encryption encryption Token Generation Policy Storage Appli Appli Delegated Management SP Load/install data SP Pesonalization data (SCP) Lifecycle Management Tokens (optional) Tokens (optional) Delegated Management Storage

(40)

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

(41)

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

(42)

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.

(43)

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 on-card 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.

(44)

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.

(45)

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.

(46)

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.

mobile NFC technical guidelines

technical guidelines

November 2007

Disclaimer and Legal Notices

Table of Contents

Section 1:

Executive Summary

.

.

.

.

.

.

.

UICC to NFC Chip Interface (Host Controller Interface [HCI])

Support of contactless systems

Secure Element (SE) selection

Compatibility between ETSI HCI specification and NFC-Forum HCI specification

UICC Run-Time Environment

UICC Environment

a) Performance

.

.

.

b) Memory management

c) Multi-tasking

.

.

.

.

.

Java Card Application Programmer Interface (API)

.

.

.

.

.

.

.

.

.

.

OTA Provisioning

Security Domain (SD) creation

Applet issuance

Transport protocol

Token mechanism

Data Authentication Pattern (DAP) mechanism

Authorised management

Applet personalisation

Mifare

Felica

Mobile NFC Device Security

Secure display on the Screen and secure entry on the Keyboard

User Interface Authentication

Enhance security by using the Handset connectivity

.

.

NFC Application Approval

Section 2:

Introduction

.

.

.

2.1

External Reference Documents

2.2

Project Deliverable Documents

Section 3:

Purpose of the Document

.

.

.

.

3.1

Document Structure

.

.

.

.