NFC Mobile Handset High Level Specifications

Transcription

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
Copyright © AFSCM 2008-2011
AFSCM NFC Mobile Handset High Level Requirements v2.0
p1/23
Name
Company
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
Authors
Document management
Version
Date
0.1
28/03/2008
0.2
2/10/2008
1.0
24/12/2008
Chapters
Modifications
Document Creation
all
First release
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
2.0
29/08/2011
1.4.5
UICC secure access API reference added
p2/23
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
Appendix A ....................................................................................................................... 23
p3/23
1 INTRODUCTION
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.
p4/23
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, knowAFSCM NFC Mobile Handset High Level Requirements v2.0
p5/23
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:
AFSCM:
API:
BB:
BIP:
CLF:
CLT:
JCP:
HCI:
JSR:
LLCP:
ME:
MIDP:
MNO:
NFC:
RF:
SCWS:
SE:
SIM:
SWP:
UPI:
UICC:
1.4
Near Field Communication
Association Française du Sans Contact Mobile
Application Programming Interface
Base Band
Bearer Independent Protocol
ContactLess Frontend
ContactLess Tunnelling
Java Community Process
Host Controller Interface
Java Specification Request
Logical Link Control Protocol
Mobile Equipment
Mobile Information Device Profile:
Mobile Network Operator
Near Field Communication
Radio Frequency
Smart Card Web Server
Secure Element
Subscriber Identity Module
Single Wire Protocol
User Primary Interface
Universal Integrated Circuit Card (aka SIM)
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
p6/23
[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
[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
p7/23
2 MOBILE NFC HANDSET TECHNICAL 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.
MNO
Trusted third
party
Mobile handset (Application processor = baseband)
Browser
Network access
Mobile app
Mobile NFC API
Mobile UICC API
UICC
CAT – proactive commands
ISD
SSD 1
NFC application
App 1
App 2
App n
SSD 2
App
SSD n
App
UICC NFC API
CLF
Peer to peer
interface (LLCP)
R/W interface
Card emulation
interface
NFC device
NFC tag
Merchant POS
Figure 1: General Architecture of the NFC Device
p8/23
2.1.1
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
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].
p9/23
2.1.2
Java / MIDP-specific requirements
This section is dedicated to handsets in a Java / MIDP mobile environment.
Requirement #
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
Requirement #
2.2
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
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.
p10/23
2.2.1
Global architecture
This figure describes the global architecture:
MNO UPI
Service providers’ applications
Mobile environment
NFC Services
Application 1
Application 2
Service 1
Application 3
Service 2
Service 3
MNO UPI
Exit
Menu
Mobile
handset
registry
UICC
Umbrella
application
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
Umbrella Application
UICC Application listing NFC JavaCard applications in the UICC
p11/23
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 #
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 78164 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.
p12/23
For Java / MIDP: JSR 320 (as described in [16])
For Android: included in the Android framework
2.2.5
Java / MIDP-specific UPI requirements
Requirement #
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
1
2
4
5
6
7
2.3.1
Version
Label (service name to
display in the UPI main
screen)
Logo (service logo to display
in the UPI main screen)
Logo 2 (alternative service
logo to display in the UPI
main screen)
Long AID of Cardlet
application
Service Type
RecordStore Version
3
2.3
Description
Format
ASCII (ex : 1.0.12 shall be
written 010012)
ASCII
Binary
Binary
Binary
1 Byte
ASCII (ex : 1.0 shall be
written 0100)
NFC API requirements
NFC events requirements
Requirement #
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
p13/23
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 #
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)
For Android: the handset shall implement the
p14/23
uicc.secure.access.api API, described in [31] API and Android
permissions
2.3.3
Java / MIDP-specific security requirements
Requirement #
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 #
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
2.4.1
Required NFC Features
CLF Required Features
The CLF enables contactless communication and shall support the following requirements:
Requirement #
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:
p15/23
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:
NFC Tag writing capability enabled
Supports writing at least NFC Forum Type 1-2-4 tags
NFC Forum Type 3 tags not required
2.4.2
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]
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
technology and UICC Config 1.0.1.
p16/23
Requirement #
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
2.4.3
CLT mode support
The handset supports the CLT mode (Mifare), as defined in [9]
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 #
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]
p17/23
2.5
2.5.1
NFC tag reading/writing
Architecture overview
UICC
Umbrella application
Certificate
control
Mobile handset
Application 1
Tag reading / writing
native application
Application 2
Application 3
Mobile NFC API
NFC controller
NFC tag
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 #
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
Store different content in mobile:
p18/23
o
o
o
o
Note
Contact
Calendar
Multimedia
Pairing
Tag Writing
2.5.3
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.
Tag data format
Requirement #
TAG_REQ_12
Tag writing format
Tag data must be written in NDEF following the NFC Forum SmartPoster RTD
p19/23
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 draftwugofski-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.
[Note] For SMS and MMS, the phone number is directly read from the tag
p20/23
3 REQUIREMENTS 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
p21/23
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
TAG_REQ_13
Tag writing format complement
p22/23
4 APPENDIX A
The following file contains the javadoc documentation of the API described in [16].
End of document
p23/23

NFC Mobile Handset High Level Specifications

Transcription

Documents pareils

A quick look at some of the top birds currently on the Elimar online

Financial Institutions` Digital Future: Embracing the Inevitable

koveri™ data

Near Field Communication Research Lab Hagenberg

business

Machine A Sous En Ligne Gratuite Casino Jeux Paris Xbox

CONFERENCE PROGRAMME

Direct vibe handset Combiné à transducteur Bone conduction