• No results found

NFC Mobile Handset High Level Requirements V2

N/A
N/A
Protected

Academic year: 2021

Share "NFC Mobile Handset High Level Requirements V2"

Copied!
23
0
0

Loading.... (view fulltext now)

Full text

(1)

AFSCM NFC Mobile Handset High Level Requirements v2.0 p1/23

NFC Mobile Handset High Level Requirements

V2

Release 2.0

Date : 28/09/2011

Reference: 110928 - AFSCM TECH - LIVBL - NFC Mobile Handset High Level Requirements - v2.0.doc

(2)

Name Company

Authors Pierre Le Pallec Bouygues Telecom

Ahmad Saif Orange

Thierry Simon SFR

Sébastien Gauthier AFSCM

Document Manager Sébastien Gauthier AFSCM

Approval Laurence Becq AFSCM

Document management

Version Date Chapters Modifications

0.1 28/03/2008 Document Creation

0.2 2/10/2008 all First release

1.0 24/12/2008 First version sent to handset manufacturers 1.1 (ex 2.0) 20/07/2009 3.4 Tag read specifications added

1.2 (ex 3.1) 30/07/2009 all Copyright licence added in introduction, table of contents modified

1.3 (ex 3.2) 24/08/2009 all Document template updated, table of contents modified 2.0 DRAFT 27/07/2011 all Draft release of version 2

(3)

TABLE OF CONTENTS

1 Introduction ... 4 1.1 Context ... 4 1.2 Copyright license ... 5 1.3 Acronyms ... 6 1.4 References ... 6 1.4.1 3GPP specifications ... 6 1.4.2 SCP specifications ... 6 1.4.3 JSR Specifications... 7 1.4.4 NFC Forum Specifications ... 7 1.4.5 Android specifications ... 7

1.5 Operating system environments ... 7

2 Mobile NFC Handset Technical requirements ... 8

2.1 Mobile NFC Handset Architecture Overview... 8

2.1.1 Android-specific requirements ... 9

2.1.2 Java / MIDP-specific requirements ... 10

2.1.3 Java / RIM-specific requirements ... 10

2.2 NFC Services User Primary Interface (UPI) – MNO Wallet ... 10

2.2.1 Global architecture ... 11

2.2.2 UPI Overview ... 12

2.2.3 Handset registry ... 12

2.2.4 UPI requirements ... 12

2.2.5 Java / MIDP-specific UPI requirements ... 13

2.3 NFC API requirements ... 13

2.3.1 NFC events requirements ... 13

2.3.2 Security requirements ... 14

2.3.3 Java / MIDP-specific security requirements ... 15

2.3.4 Android-specific security requirements ... 15

2.4 Required NFC Features ... 15

2.4.1 CLF Required Features ... 15

2.4.2 Secure Element UICC Required Features ... 16

2.4.3 Remote management of NFC services (Access to UICC in connected mode) ... 17

2.5 NFC tag reading/writing ... 18

2.5.1 Architecture overview ... 18

2.5.2 Tag reading/writing requirements ... 18

2.5.3 Tag data format ... 19

3 Requirements summary ... 21

(4)

1 I

NTRODUCTION

1.1 Context

AFSCM was established in April 2008 by Bouygues Telecom, Orange and SFR as a non-profit organization to foster the development of mobile contactless services.

AFSCM objective is to support the inception of new contactless services for mobile phone users. In particular, AFSCM endeavors:

To support service providers such as banks or transit authorities in the definition and deployment of contactless solutions suited for mobile subscribers to any available mobile network;

To specify technical guidelines for the development of mobile contactless services to ensure seamless installation and consistent user experience ;

To promote the benefits of the mobile phone platform for contactless service providers, for technology providers and for end users.

To define a mutually beneficial mobile contactless eco-system, AFSCM will propose a shared mobile contactless target mark and a shared brand that will distinguish those contactless services that are available to mobile phone users.

AFSCM constituency will include all companies involved in the development of a sustainable market for mobile contactless services such as service providers, handset makers, Smart Card Manufacturers, mobile network operators, MVNOs. Together, AFSCM members will contribute to the definition of innovative industry standards and best practices.

The stated objective of the AFSCM is to facilitate the development of mobile contactless services. To this end, the founding members recognize the significance of the following success factors:

virtuous eco-system in which all parties involved can develop a sustainable market position efficient customer support

smooth customer experience

state-of-the art application life cycle management service portability in the event of a ME swap service portability in the event of a MNO swap

The purpose of this document is to provide handset manufacturers with a set of common NFC handset high level specifications consistent with this objective.

The AFSCM cannot be held liable to anyone for:

the use and/or publication of all or part of this document,

the accuracy of this document and/or its suitability for any specific needs, any development that arises from it.

(5)

This document remains the exclusive property of the AFSCM. This document may not be copied, translated or divulged to third parties in their present or modified form except with the prior written consent of the AFSCM.

This document is supplied "AS-IS" and the AFSCM does not claim and cannot accept any liability for any errors or omissions in this document.

The AFSCM makes no guarantees and refuses all liability with regard to the content of this document, and in particular any breaches of intellectual property rights such as patents, trademarks, copyright or other intellectual property rights belonging to third parties in relation to all or part of this document. On this basis, no claims and/or legal proceedings relating to the use of this document can be brought against the AFSCM or any of its members.

In no case can any members of the AFSCM be held liable for any losses caused to the User or anyone else by the direct and/or indirect use of this document, such as, but not limited to, losses of income, financial losses (including cases of breach of intellectual property rights) and losses of information.

1.2 Copyright license

The following document is a personal, non-exclusive copyright license between you - the Licensee - and the AFSCM founding members (*), regarding the AFSCM specifications, that must be included in any copy of said specifications.

The licensee is authorized to copy, present or communicate the AFSCM specifications on any media without having to pay any license fee under the condition that the following copyright notice be included in any copy or any excerpt of the specifications:

« Copyright © AFSCM 2008-2011 (Association Française du Sans Contact Mobile ;

http://www.afscm.org/ ). All rights reserved. Terms and conditions to copy, display and communicate these Specifications are available at http://www.afscm.org/conditions.html »

The licensee is NOT authorized to create or disclose modifications or abstracts of the specifications or work derived from the specifications.

The specifications include detailed functional specifications, technical specifications, NFC handset and NFC UICC implementation guidelines, application development guidelines (midlet and cardlet) and SP-MNO interconnection guidelines.

Separate patent licenses and additional materials will be proposed to those wanting to implement solutions compliant with the AFSCM specifications, under licensing conditions to be defined in separate agreements. Information for procuring such patent licenses and additional materials documents is contained in Annex 1.

THE SPECIFICATIONS ARE SUPPLIED "AS IS" AND NEITHER THE AFSCM NOR ITS MEMBERS ARE COMMITTED TO ANY WARRANTY, EXPLICIT OR IMPLICIT, REGARDING THE SPECIFICATIONS, IN PARTICULAR NO WARRANTY IS GIVEN OF QUALITY, SUITABILITY TO ANY USE WHATSOEVER, ABSENCE OF TITLE OR RIGHTS TO THE CONTENT OF THE SPECIFICATIONS, INSURANCE THAT THE USE OF THE SPECIFICATIONS WILL NOT INFRINGE INTELLECTUAL PROPRETY RIGHTS OF A THIRD PARTY SUCH AS PATENTS, TRADE MARKS, COPYRIGHTS. NEITHER THE AFSCM NOR ITS MEMBERS SHALL BE HELD LIABLE FOR ANY DAMAGE INCURRED IN CONNECTION TO THE USE, REPRESENTATION OR COMMUNICATION OF THE SPECIFICATIONS.

Neither the AFSCM name nor its trade marks shall be used under any circumstances, such as to communicate or advertise the specifications without the prior written agreement of the AFSCM. No rights other than the rights described above are granted under this license and the rights granted under this license cannot be construed as conferring, implicitly or explicitly, any rights (through a licensing agreement or any other means) concerning AFSCM or AFSCM members inventions,

(6)

know-how or intellectual property, or any of their assets resulting from, based on or required in the specifications.

This copyright license is subject to French law and shall be governed by and interpreted according to French laws. The exclusive place of jurisdiction shall be the Paris Court of Appeal, regardless of the number of claims or defendants.

By downloading the AFSCM specifications, you indicate your acceptance of these terms and conditions.

(*) : AFSCM founding members are : Bouygues Telecom, Orange France / France Telecom, SFR

1.3 Acronyms

NFC: Near Field Communication

AFSCM: Association Française du Sans Contact Mobile API: Application Programming Interface

BB: Base Band

BIP: Bearer Independent Protocol CLF: ContactLess Frontend

CLT: ContactLess Tunnelling JCP: Java Community Process HCI: Host Controller Interface JSR: Java Specification Request LLCP: Logical Link Control Protocol

ME: Mobile Equipment

MIDP: Mobile Information Device Profile: MNO: Mobile Network Operator

NFC: Near Field Communication

RF: Radio Frequency

SCWS: Smart Card Web Server

SE: Secure Element

SIM: Subscriber Identity Module SWP: Single Wire Protocol UPI: User Primary Interface

UICC: Universal Integrated Circuit Card (aka SIM)

1.4 References

All standard reference(s) can be found in the following list: 1.4.1 3GPP specifications

[1] 3GPP TS 23.040 (v6.7.0, Rel-6): Technical realization of the Short Message Service (SMS) [2] 3GPP TS 23.048 (v5.9.0, Rel-5): Security Mechanisms for the (U)SIM application toolkit; Stage 2 [3] 3GPP TS 31.111 (v6.9.0, Rel-6): USIM Application Toolkit (USAT)

1.4.2 SCP specifications

[4] ETSI TS 102 223 (Rel-9): Card Application Toolkit

[5] ETSI TS 102 225 (Rel-9): Secured packet structure for UICC applications [6] ETSI TS 102 226 (Rel-9): Remote APDU Structure for UICC based Applications [7] ETSI TS 102 240 (Rel-9): UICC Java Card™ API - Stage 1

[8] ETSI TS 102 241 (Rel-9): UICC Java Card™ API - Stage 2

[9] ETSI TS 102 613 (Rel-9): Smart Cards: UICC - Contactless Front-end (CLF) Interface; Part 1: Physical and data link layer characteristics

(7)

[10] ETSI TS 102 622 (Rel-9): Smart Cards: UICC - Contactless Front-end (CLF) interface; Host Controller Interface (HCI)

[11] ETSI TS 102 705 (Rel-9): Smart Cards; UICC Application Programming Interface for Java Card™ for Contactless Applications

1.4.3 JSR Specifications

[12] JCP – JSR-000118: Mobile Information device Profile -Trusted MIDlet suites using X509 PKI [13] JCP – JSR-000177: Security and Trust Services API for J2ME

[14] JCP – JSR-000211: Content Handler API

[15] JCP – JSR-000257: Contactless Communication API

[16] Services Framework API, based on the JCP – JSR-000320 draft document, and finalized by Orange. This API is free for implementation and use and is included in this document in

Appendix A. 1.4.4 NFC Forum Specifications [17] NFCForum-TS-Type-1-Tag_1.0 [18] NFCForum-TS-Type-2-Tag_1.0 [19] NFCForum-TS-Type-3-Tag_1.0 [20] NFCForum-TS-Type-4-Tag_2.0 [21] NFCForum-TS-GenericControlRTD_1.0 [22] NFCForum-SmartPoster_RTD_1.0 [23] NFCForum-TS-NDEF_1.0 [24] NFCForum-TS-RTD_1.0 [25] NFCForum-TS-RTD_Text_1.0 [26] NFCForum-TS-RTD_URI_1.0 [27] NFCForum-TS-Signature-1.0 [28] NFCForum-TS-LLCP_1.00 1.4.5 Android specifications

[29] SIMalliance Open Mobile API, Release v.1.01

[30] http://developer.android.com/guide/topics/nfc/index.html

[31] UICC secure access API:

GP_DC_secure_element_access_control_gemalto_technical_solution_v1.2.1

1.5 Operating system environments

This document addresses both global requirements and environment specific requirements. When necessary, the document will indicate when a section deals with the:

Java / MIDP environment Java / RIM environment Android environment

(8)

2 M

OBILE

NFC

H

ANDSET

T

ECHNICAL REQUIREMENTS

2.1 Mobile NFC Handset Architecture Overview

The NFC mobile device is divided in three main components: The NFC controller and connected antenna

The secure element

The application processor (called also Base Band)

The Mobile NFC Handset (as shown below) offers three different interfaces: the contactless one, the OTA one, and the MMI (Man Machine Interface).

The Secure element to store and execute NFC secure applications is the UICC.

The UICC will be designed to comply with NFC service requirements and to interface with the other components of the ecosystem.

CLF

Peer to peer

interface (LLCP) R/W interface

Card emulation interface

NFC device NFC tag Merchant POS

UICC ISD SSD 1 NFC application App 1 App 2 App n SSD 2 App SSD n App UICC NFC API

CAT – proactive commands

Mobile handset (Application processor = baseband)

Browser Network access

Mobile UICC API

Mobile app

Mobile NFC API MNO Trusted third

party

Figure 1: General Architecture of the NFC Device

(9)

Element Description

Browser The browser inside the Handset displays internet pages (HTML), WAP (WML, XML) pages

Mobile app The mobile application is a program loaded inside the handset which acts as a graphical interface to a specific mobile NFC service

Network access Unit of the mobile phone used to communicate through the telecom network via GSM, GPRS, EDGE, UMTS, HSDPA,… Telecom bearers

Mobile UICC API The UICC API of the handset allows any mobile application installed on the handset to communicate with the UICC card using APDU commands Mobile NFC API The NFC API of the handset allows any mobile application installed on the

handset to communicate with the CLF.

It also allows the cardlet to communicate with the mobile application (when invoked by a POS for instance).

CAT The Card Application Toolkit provides mechanisms which allow applications, existing in the SIM, to interact and operate with any Mobile equipment which supports the specific mechanism(s) required by the application

UICC NFC API Specific Java card API which allows to the UICC card (Specially Java card applications embedded inside) to communicate with the NFC controller NFC application Java card application which allows managing all NFC applications

App 1 to App n Applications loaded into UICC

CLF The Contactless Frontend (or NFC controller) is a NFC chip which allows the handset to communicate through the NFC bearer using three different modes: card emulation, card reader, peer to peer

ISD The Issuer Security Domain is the primary, mandatory on-card representative of the Card Administrator, typically the Card Issuer

SSD A Supplementary Security Domain is an additional, optional on-card representative of an Application Provider or the Card Issuer

2.1.1 Android-specific requirements

This section is dedicated to handsets in an Android mobile environment.

Requirement # Requirement description API_ANDROID_REQ_01 The Mobile UICC API used in the Android architecture is:

the org.simalliance.openmobileapi API, described in [29], to gain access to the UICC

the uicc.secure.access.api API, described in [31], to secure the access to the UICC

API_ANDROID_REQ_02 The Mobile NFC API used in the Android architecture is the android.nfc API, described in [30].

(10)

2.1.2 Java / MIDP-specific requirements

This section is dedicated to handsets in a Java / MIDP mobile environment.

Requirement # Requirement description

API_MIDP_REQ_01 The Mobile UICC API used in the Java / MIDP architecture is the JSR 177 API_MIDP_REQ_02 The Mobile NFC API used in the Java / MIDP architecture is the JSR 257

2.1.3 Java / RIM-specific requirements

This section is dedicated to handsets in a Java / MIDP mobile environment.

Requirement # Requirement description

API_RIM_REQ_01 The Mobile UICC API used in the Java / RIM architecture is the JSR 177 API_RIM_REQ_02 The Mobile NFC API used in the Java / RIM architecture is the

net.rim.device.api.io.nfc package and its sub-packages

2.2 NFC Services User Primary Interface (UPI) – MNO Wallet

The UPI is intended to facilitate the User experience while accessing the NFC Services portfolio. The UPI lists all Service Provider mobile NFC services loaded into the Mobile Equipment/UICC and displays their current status. Furthermore this list allows the user to launch the MMI associated with the services.

Moreover, this interface may allow the end user to manage the NFC settings of his handset. This section describes the APIs required by the implementation of the NFC UPI.

(11)

2.2.1 Global architecture

This figure describes the global architecture:

UICC

Mobile environment

MNO UPI

NFC Services

Service 1

Service 2

Service 3

Exit

Menu

Application 1

Application 2

Application 3

MNO UPI

Service providers’ applications

Umbrella application Mobile handset registry Figure 2: UPI Architecture Overview

Element Description

UPI User’s Primary Interface for accessing NFC Services Service Provider’s

applications or MMI

Mobile application serving as a graphical interface to the mobile NFC service of a Service Provider

Handset registry A database used to link UPI and SP MMI

(12)

2.2.2 UPI Overview

Both MNO UPI and SP MMI are mobile applications loaded into the ME. The AFSCM architecture defines two kinds of mobile applications:

UPI application under the responsibility of MNO. SP MMI under the responsibility of the SP.

Each SP MMI is represented by one entry in the UPI with at least the following information: Service name

Service logo

Service Provider Name Life cycle status 2.2.3 Handset registry

In order to list the NFC Services installed on the handset, the UPI shall access a specific shareable NFC database (Handset registry) which references the SP MMI that are installed and their related data (service name, logo, etc…).

This NFC database is shared between the SP MMI and the MNO UPI. Each record of the handset registry corresponds to one Service Provider Application, with its associated data.

Each SP MMI shall only access its own information in the ME Registry. It is recommended that the Operating System of the handset guarantees the confidential access to the handset registry.

2.2.4 UPI requirements

Requirement # Requirement description UPI_REQ_01 UICC secure application management (APDU Exchange)

The handset shall include an API enabling communication of the mobile applications with applications loaded into the UICC by exchanging ISO 7816-4 APDU

For Java / MIDP: JSR 177 (APDU Exchange)

For Android: the org.simalliance.openmobileapi API, described in [29]

UPI_REQ_02 Third party application launching

The handset shall include an API enabling the MNO UPI to launch third party applications. If the system allow multiple concurrent applications, both applications are staying alive; else only the third party application goes on; In this case this application shall hand over back to the MNO MMI when closing.

For Java / MIDP: JSR 320 (as described in [16]) or JSR 211 For Android: Intent mechanism

UPI_REQ_03 Application auto-updating

The handset shall include an API enabling the UPI Application to update itself.

(13)

For Java / MIDP: JSR 320 (as described in [16]) For Android: included in the Android framework

2.2.5 Java / MIDP-specific UPI requirements

This section is dedicated to handsets in a Java / MIDP mobile environment.

Requirement # Requirement description UPI_MIDP_REQ_01 Third party application installing/uninstalling

The handset shall implement the JSR 320 (as described in [16]), enabling an application (such as the MNO wallet) to load, install and uninstall third party applications.

UPI_MIDP_REQ_02 RecordStore entries storage

Service Providers’ mobile applications shall be able to create at least 100 RecordStore entries in the following format:

Record Id Description Format

1 Version ASCII (ex : 1.0.12 shall be

written 010012) 2 Label (service name to

display in the UPI main screen)

ASCII

3 Logo (service logo to display in the UPI main screen)

Binary

4 Logo 2 (alternative service logo to display in the UPI main screen)

Binary

5 Long AID of Cardlet application

Binary

6 Service Type 1 Byte

7 RecordStore Version ASCII (ex : 1.0 shall be written 0100)

2.3 NFC API requirements

2.3.1 NFC events requirements

Requirement # Requirement description

API_REQ_01 The CLF shall be able to trigger a mobile application (as defined in [10]) A NFC event (on POS transaction, on tag reading…) must be able to trigger a mobile application:

On tag reading, a NDEF is pushed from the CLF to the system On a POS reader transaction, a secure element push shall be

(14)

understood as a UICC push through a HCI event (a.k.a.

EVT_TRANSACTION) and will be able to provide the cardlet’s AID with private data support as described in [10]

The handset shall implement:

For Java / MIDP: JSR 257 with appendix B implemented

For Android: Card Events through HCI shall be implemented, and applications shall be able to register for the events using intent filters For Java / RIM: the net.rim.device.api.io.nfc package and its sub-packages

API_REQ_02 Multi-SE environment requirements

Whether or not the handset hosts an NFC capable embedded secure element, there should be an API that allows the following

Identify which secure element is responding in card emulation Define which secure element is responding in card emulation At any given point in time, only one secure element should be active in card emulation mode.

2.3.2 Security requirements

Requirement # Requirement description

SEC_REQ_01 Only authorized mobile applications shall be able to access the UICC applications

For Java / MIDP (also applicable in the Java / RIM environment): o the mobile NFC Handset shall implement a Protection

Domain as a set of permissions defined to limit access to some APIs

o only signed midlets shall be able to access the UICC using the JSR177 ([13])

For Android: only signed mobile applications, with a valid ACF corresponding to this signature, shall be able to access to the corresponding applications in the UICC, using the

uicc.secure.access.api API, described in [31]. SEC_REQ_02 Certificates and permissions management

For Java / MIDP: the handset shall implement JSR 118 ([12]) o Mandatory: Certificates which give some access to the

Protection Domain are loaded into the mobile (i.e. JSR118) (also applicable to the RIM environment)

o Optional: Certificates which give some access to the Protection Domain can be loaded into the SIM card (PKCS#15 files)

(15)

uicc.secure.access.api API, described in [31] API and Android permissions

2.3.3 Java / MIDP-specific security requirements

This section is dedicated to handsets in a Java / MIDP mobile environment.

Requirement # Requirement description SEC_MIDP_REQ_01 Access to UICC applications is forbidden using JSR257.

For security reasons, the implementation of JSR257 SHALL NOT implement access to the UICC.

The mobile applications shall access NFC applications on the UICC using the JSR177.

2.3.4 Android-specific security requirements

This section is dedicated to handsets in an Android mobile environment.

Requirement # Requirement description

SEC_ANDROID_REQ_01 Eavesdropping protection in Android

The card emulation transaction event should also be protected from eavesdropping by checking whether the target application has access to the source AID in the UICC through the UICC access API (the same security policy shall apply).

2.4 Required NFC Features

2.4.1 CLF Required Features

The CLF enables contactless communication and shall support the following requirements:

Requirement # Requirement description NFC_REQ_01 RF compliance

The handset’s NFC chipset & antenna are compliant with contactless reader infrastructure (ISO 14443 A & B)

NFC_REQ_02 The CLF shall support the card emulation mode: Using ISO 14443 A & B

Mifare support is optional Felica support not required

NFC_REQ_03 The CLF shall support the tag reader mode: Using ISO 14443 A & B

(16)

NFC Tag reading capability enabled

Supports reading at least NFC Forum Type 1-2-4 tags NFC Forum Type 3 tags not required

NFC_REQ_04 The CLF shall support the tag writer mode: Using ISO 14443 A & B

NFC Tag writing capability enabled

Supports writing at least NFC Forum Type 1-2-4 tags NFC Forum Type 3 tags not required

NFC_REQ_05 The CLF shall support the peer-to-peer (LLCP) mode with a transfer rate of at least 206Kbps

NFC_REQ_06 NFC function toll on autonomy

Automatic and continuous switch between card emulation and reader mode. If this switch is permanent, the decrease of the autonomy of the phone in standby mode shall be less than 10%.compared to the standby time when the NFC is totally off. If this 10% threshold can’t be reached, the automatic switch shall be applied only when the keyboard is activated or the screen back lighted.

NFC_REQ_07 Minimum battery requirements in battery low mode

When the battery is low and the phone is automatically switched off (no more screen display possible, no more phone calls, no more mobile data exchange), the phone shall have the capability to supply a source of power to perform a few transactions (50 transactions) in card emulation mode for at least 24 hours

NFC_REQ_08 Transactions in battery low mode

NFC transactions shall be possible in battery low mode for public transportation application but shall not be possible for payment application.

NFC_REQ_09 NFC mobile phone test methods

To address mobile phones, a new class of devices is under study within ISO/SC17 committee in charge of ISO 14 443 specifications. NFC mobile phones shall comply with upcoming test methods on the RF interface which will be considered in ISO 10373-6

NFC_REQ_10 SWP support

The CLF shall support the SWP standard as defined in [9] NFC_REQ_11 HCI support

The CLF shall support the HCI standard as defined in [10]

2.4.2 Secure Element UICC Required Features

The Secure element to store and execute NFC secure applications is the UICC.

[Note] For information purpose, the Mobile NFC UICC shall be compliant with the Java Card 3.0.1

(17)

Requirement # Requirement description UIC_REQ_01 NFC SIM cards compliance

The NFC handset shall be compliant with the NFC SIM cards that are compliant with SWP ([9]) & HCI ([10]).

UIC_REQ_02 NFC Transaction duration

The UICC and Mobile Environment shall allow the shortest delay possible between the 14443 REQ command and the response to a ISO 7816 Select command in order to ensure an acceptable user experience.

For information, the targeted duration of a mobile NFC transit transaction is 230-250 ms

UIC_REQ_03 CLT mode support

The handset supports the CLT mode (Mifare), as defined in [9]

2.4.3 Remote management of NFC services (Access to UICC in connected mode)

In order for the MNO or the SP to perform the remote management of NFC services, and access the UICC in connected mode, the mobile NFC handset shall implement standards SIM OTA protocol (SMS, Security, Proof Of Receipt…)

Requirement # Requirement description OTA_REQ_01 BIP support

The handset shall support the BIP protocol in client mode (UDP) OTA_REQ_02 BIP proactive commands and CAT events

The handset must be "class e" compliant and BIP (Client) in Transparent mode (Alpha-ID = NULL) shall be supported.

The handset must support the following proactive commands and CAT (Card application Tool KIT) events issued by the UICC, described in [3] and [4]:

Proactive commands o OPEN CHANNEL o CLOSE CHANNEL o SEND DATA o RECEIVE DATA

o GET CHANNEL STATUS Events

o DATA AVAILABLE o CHANNEL STATUS OTA_REQ_03 UICC standards compliance

The handset must be compliant with the UICC standards, and in particular does not limit or prevent UICC OTA functionalities described in [5], [6] and [1]

(18)

2.5 NFC tag reading/writing

2.5.1 Architecture overview

UICC

Mobile handset

Application 1 Application 2 Application 3 Umbrella application

NFC tag

Certificate control NFC controller Tag reading / writing

native application

Mobile NFC API

Figure 3: Tag reading / writing architecture overview

2.5.2 Tag reading/writing requirements

The tag reading user interface shall comply with the following requirements:

Requirement # Requirement description TAG_REQ_01 Mandatory tag reading/writing features

The handset shall support the following NFC tag reading/writing features: Launch phone call

Send SMS and MMS Launch Browser

Launch Service Provider application TAG_REQ_02 Optional tag reading/writing features

The handset may support the following NFC tag reading/writing features: Launch mobile native function

(19)

o Note o Contact o Calendar o Multimedia Pairing Tag Writing

TAG_REQ_03 Tag reading application launch

The triggering of the tag application shall be transparent for the user while reading a tag

TAG_REQ_04 Tag reading/NFC activation/de-activation

The tag reading application cannot be specifically activated / deactivated by the user.

However, when the NFC feature is being globally activated / deactivated by the user on his handset, all NFC features must be activated / deactivated (including the emulation card mode and the tag reader mode).

TAG_REQ_05 Tag reading performance

The user shall be informed in less than 500 ms that a tag is being read, which ensures an acceptable user experience

TAG_REQ_06 NFC Forum Smart Poster support

The user shall be able to read/write the NFC Forum Smart Poster Tag. TAG_REQ_07 NFC Forum Generic Control Tag support

The mobile shall be able to read the NFC Forum Generic Control Tag. TAG_REQ_08 Tag signature verification

The mobile shall be able to verify NFC tags’ signatures. The tags’ signature follows the NFC Forum RTD signature specification.

TAG_REQ_09 Tag reading distance

NFC tags shall be read from 4 cm to 0 cm TAG_REQ_10 User prompt following tag reading

Following a tag read, once the tag reading application is launched, the user shall be prompted before an action is performed

TAG_REQ_11 Reading un-trusted tags

When reading a tag that cannot be authenticated by the tag reading application, the user shall be explicitly prompted that the tag is untrusted. However, reading the tag shall remain possible. It shall be possible to enable/disable this prompt in factory settings.

2.5.3 Tag data format

Requirement # Requirement description

TAG_REQ_12 Tag writing format

(20)

specification

For all the undefined cases, the URI 0x00 Identifier code is used TAG_REQ_13 Tag writing format complement

For all undefined cases using the 0x00 URI identifier code, data written on tags should be formatted as:

Type Format

Text V-Card VCARD (Seer RFC2426) Text Calendar VEVENT (See RFC2445)

Text Notes VTODO (See RFC2445)

URI05 Phone Number Phone number (See RFC3966)

URI00 SMS sms:recipient?body=message (cf draft-wilde-sms-uri-09) URI Web Browser http://site.com?param=value (see RFC2616)

GC JAVA VM See Generic Control Specification URI USSD Session ussd: (see RFC3966)

URI00 MMS mms:recipient?subject=subj&body=message (cf draft-wugofski-mms-uri-scheme-00)

URI eMail mailto: (see RFC3966)

URI video-phone functionality

video: (See RFC3966)

[Note] V-Card, Calendar, and Notes are directly read on the tag. Data format complies with the

RFC2426 format for Vcard, and the RFC2445 format for calendar and notes.

(21)

3 R

EQUIREMENTS SUMMARY

Requirement # Requirement title

API_ANDROID_REQ_01 The Mobile UICC API used in the Android architecture API_ANDROID_REQ_02 The Mobile UICC API used in the Android architecture API_MIDP_REQ_01 The Mobile UICC API used in the Java / MIDP architecture API_MIDP_REQ_02 The Mobile NFC API used in the Java / MIDP architecture API_RIM_REQ_01 The Mobile UICC API used in the Java / MIDP architecture API_RIM_REQ_02 The Mobile NFC API used in the Java / MIDP architecture UPI_REQ_01 UICC secure application management (APDU Exchange) UPI_REQ_02 Third party application launching

UPI_REQ_03 Application auto-updating

UPI_MIDP_REQ_01 Third party application installing/uninstalling UPI_MIDP_REQ_02 RecordStore entries storage

API_REQ_01 The CLF shall be able to trigger a mobile application API_REQ_02 Multi-SE environment requirements

SEC_REQ_01 Only authorized mobile applications shall be able to access the UICC applications

SEC_REQ_02 Certificates and permissions management

SEC_MIDP_REQ_01 Access to UICC applications is forbidden using JSR257 SEC_ANDROID_REQ_01 Eavesdropping protection in Android

NFC_REQ_01 RF compliance

NFC_REQ_02 The CLF shall support the card emulation mode NFC_REQ_03 The CLF shall support the tag reader mode NFC_REQ_04 The CLF shall support the tag writer mode

NFC_REQ_05 The CLF shall support the peer-to-peer (LLCP) mode NFC_REQ_06 NFC function toll on autonomy

NFC_REQ_07 Minimum battery requirements in battery low mode NFC_REQ_08 Transactions in battery low mode

NFC_REQ_09 NFC mobile phone test methods

NFC_REQ_10 SWP support

NFC_REQ_11 HCI support

UIC_REQ_01 NFC SIM cards compliance UIC_REQ_02 NFC Transaction duration

(22)

UIC_REQ_03 CLT mode support

OTA_REQ_01 BIP support

OTA_REQ_02 BIP proactive commands and CAT events OTA_REQ_03 UICC standards compliance

TAG_REQ_01 Mandatory tag reading/writing features TAG_REQ_02 Optional tag reading/writing features TAG_REQ_03 Tag reading application launch

TAG_REQ_04 Tag reading/NFC activation/de-activation TAG_REQ_05 Tag reading performance

TAG_REQ_06 NFC Forum Smart Poster support TAG_REQ_07 NFC Forum Generic Control Tag support TAG_REQ_08 Tag signature verification

TAG_REQ_09 Tag reading distance

TAG_REQ_10 User prompt following tag reading TAG_REQ_11 Reading un-trusted tags

TAG_REQ_12 Tag writing format

(23)

4 A

PPENDIX

A

The following file contains the javadoc documentation of the API described in [16].

References

Related documents

So, the contribution of the research will develop an Android application which can provide detection and protection against ARP spoofing by installing the application on

Taking up this call, this research on Canadian game developers, community or- ganizers, and others involved in indie games suggests that contemporary cultural pro- ducers locate

The Relay clearing ground fault shall be set to a minimum Pick up current below the sustained earth fault current..

the results of voting through Remote Electronic Voting (“E-Voting” here in after) and Electronic Voting at the Annual General Meeting at the aforesaid AGM as

The countries of the Middle East and North Africa (MENA) have had to confront key developments that have coloured the past two years on the global and regional levels: the crisis

As current President of the Screen Producers Association of Australia, Antony Ginnane (2004), has observed, Australian films are “notorious in a good way for getting so much

Na TC da perna esquerda observaram- -se, na face interna, 6 lesões sólidas heterogéneas (a maior na pele e no tecido celular subcutâneo e duas delas em contacto com a aponevrose

Although there are three main elements in addressing the selling and sexual exploitation of vulnerable people according to the Palermo Protocol on Trafficking in Persons