NFC Windows Phone Applications. Development Guidelines

(1)

NFC Windows Phone Applications

Development Guidelines

RELEASE 1.0

(2)

Document management

Name Company

Authors Jérôme Roussel, Erwan Louet Orange

Eric Le Bomin SFR

Nicolas Sollier EI Telecom

Document Manager Grégoire Fraisse AFSCM

Document history

Version Date Chapters Modification

(3)

TABLE OF CONTENTS ____________________________________________________________

1 INTRODUCTION ... 4

1.1 Context ...4

1.2 Copyright license ...5

1.3 Purpose and content of this document...6

1.4 References ...7

1.5 Abbreviation ...8

1.6 Definitions ...8

2 WINDOWS PHONE APPLICATION DEVELOPMENT ... 9

2.1 Development environment ...9

2.2 Reference guidelines ...9

2.3 Implementation guidelines ...9

2.3.1 Manipulation of logical channels ...9

2.3.2 NFC card emulation state ... 10

2.3.3 NFC transaction event registration ... 10

2.3.4 Background tasks and transaction events filtering ... 11

3 MANAGEMENT RULES ... 11

3.1 Dependencies in terms of device properties and features ... 11

3.2 Usage of personal data ... 11

3.3 Publishing a Windows Phone Mobile Application... 12

3.3.1 Structure of the deliverable ... 12

3.3.2 Preparing to Publish ... 12

3.3.3 Publishing on Windows Store ... 12

3.3.4 AFSCM NFC Application Validation Process ... 12

3.3.5 Windows Phone Application signature ... 12

3.3.6 Windows Phone Mobile Application update ... 13

3.4 Connectivity ... 13 3.4.1 General Requirements ... 13 3.4.2 Network ... 13 3.4.3 Server Requests ... 14 3.4.4 Phone numbers ... 14 3.5 Security Requirements ... 14

3.5.1 Protection of local assets ... 14

3.5.2 Protection of private user assets ... 14

3.5.3 Alteration of assets ... 14

3.5.4 Confidential assets ... 15

3.5.5 Protection of assets among network communications ... 15

3.5.5.1 Prohibited transmissions ... 15

3.5.5.2 Secured transmissions ... 15

3.6 Protection of the Environment ... 16

(4)

1 I

NTRODUCTION

1.1 Context

The Mobile Network Operators Bouygues Telecom, Orange and SFR have founded the AFSCM (Association Française du Sans Contact Mobile) to foster the development of mobile contactless services.

The AFSCM constituency includes 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.

The AFSCM members include mobile telephony operators, contactless service providers, manufacturers and technical service providers. Together, AFSCM members contribute to the definition of innovative industry standards and best practices.

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

- To support service providers 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 end user experience;

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

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

Together, the AFSCM members 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,

(5)

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-2014 (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://info.afscm.org/credits-mentions-legales/ ».

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 (Mobile Application 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, 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.

(6)

1.3 Purpose and content of this document

The purpose of this document is to provide to Service Providers some security rules and best practice guidelines to develop their service Mobile Application on the Windows Phone 8.1 (or later version) mobile operating system.

Note: Security rules and best practice guidelines to develop a Cardlet are described in the AFSCM Cardlet Development Guidelines ([R3]).

This document focuses on card emulation application development, which is the more specific, lesser documented topic in the industry.

The mobile network operators members of the AFSCM have agreed on a common set of rules and recommendations regarding the design and the development of Mobile Applications appropriate for the context of NFC services. This document therefore also serves as a reference for the AFSCM NFC Applications Validation Process as described in the corresponding AFSCM guides ([R2]).

This document intends to refer to existing documents and specifications and to highlight the topics that are relevant regarding Mobile Applications development in these documents.

The safety of a Mobile Application is achieved through a variety of factors mentioned throughout this document, ranging from the development process to the correct use of the APIs, and the structure of the Mobile Application. In addition, because these applications are intended to be embedded on mobile handsets they require particular care in the usage of the operators and devices resources.

Throughout the document, the key points are highlighted with the following icons: Recommended

(7)

1.4 References

AFSCM:

The following documents are publicly available on the AFSCM website (www.afscm.org): [R1] Interface Specification between Telecom Operators and NFC Service Providers [R2] NFC Applications Validation Process

[R3] Cardlet Development Guidelines

[R4] Guidelines for interconnection of Service Providers' and MNOs' Information Systems

The AFSCM also specifies high level requirements for both UICC and mobile handset in separate documents.

Microsoft:

The following development guidelines are publicly available on the on Microsoft Developer Network (MSDN) website (msdn.microsoft.com):

[R5] Windows Runtime app development

(8)

1.5 Abbreviation

ACL Access Control List

AFSCM Association française du sans contact mobile AID Application (or Applet) IDentifier

APDU Application Protocol Data Unit API Application Programming Interface ATR Answer To Reset

BIP Bearer Independent Protocol MIDP Mobile Information Device Profile MNO Mobile Network Operator

NDEF NFC Data Exchange Format NFC Near Field Communication OTA Over The Air

RAM Remote Access Management SE Secure Element

SIM Subscriber Identity Module SP Service Provider

UICC Universal Integrated Circuit Card (aka SIM) UPI User Primary Interface

URL Uniform Resource Locator URI Uniform Resource Identifier

1.6 Definitions

Acknowledgment to Security Requirements

Declarative document to be provided by the Service Provider for the AFSCM NFC Application Validation Process described in the AFSCM NFC Applications Validation Process guidelines ([R2])

Cardlet JavaCard application loaded onto the UICC (also known as UICC application or applet)

Mobile Application Application loaded onto the mobile handset, providing a GUI (also known as MMI or midlet)

Service Combination of a Cardlet and a Mobile Application (also known as NFC service or Mobile NFC service)

Service Provider Entity which provides an NFC service.

Validation Entity Entity in charge of validating that the security level in the applications meets the security requirements (typically, a laboratory).

(9)

2 W

INDOWS

P

HONE

A

PPLICATION

D

EVELOPMENT

2.1 Development environment

The present guidelines assume an up-to-date Visual Studio environment is being used for development, including Windows Phone 8.1 support. The Windows Phone 8.1 development tools are included starting with Visual Studio 2013 (Update 2 or later).

An updated set of APIs has been introduced with Windows Phone 8.1, to build what Microsoft calls

Windows Runtime (or Windows Phone Runtime) apps. Windows Runtime (WinRT) is the main framework recommended to create new Mobile Applications for Windows Phone from now on. Cf. Windows Runtime app development ([R5]) on Microsoft Developer Network (MSDN).

Microsoft has added a new SmardCards API to develop UICC-based NFC applications in the WinRT framework. The older framework, called Silverlight, keeps evolving from Windows Phone 8.0 to 8.1 but does not include this newer NFC API to build UICC-based NFC applications. This document will thus focus on and cover only WinRT application development using the SmartCard WinRT API found in the Windows.Devices.SmartCards namespace.

2.2 Reference guidelines

Microsoft has published a detailed white paper entitled “App development guide for UICC-based NFC card emulation” ([R6]) which describes specifically how to develop UICC-based NFC applications. This Microsoft white paper is covering all the major aspects to create such applications, including API descriptions, required building blocks, sample code and even certificate creation.

This is the must-read reference for all developers targeting the Windows Phone 8.1 platform.

2.3 Implementation guidelines

This part provides additional development rules to follow, complementing the reference guidelines mentioned in the previous section.

2.3.1 Manipulation of logical channels

On Windows Phone, only one application is running in foreground at any given time. Due to this, when the user switches away from a Mobile Application, it is either suspended (Dormant state) or terminated (Tombstoned state), depending on the context. In both these states, the SmartCard API (used to access the UICC) is not available anymore. All SmartCard resources created before

transmitting APDUs to the SIM will be closed/deleted.

For this reason:

1. The Mobile Application must release the UICC logical channel(s) explicitly as soon as possible. This is done using the Dispose method, as in the following example:

connection.Dispose();

2. The Mobile Application must release the UICC logical channel(s) explicitly when a Deactivated event is raised,

3. On an Activated event, the Mobile Application must re-open UICC logical channel(s) before transmitting new APDUs. Trying to transmit APDUs using existing SmartCard resources created before the Mobile Application passed in Suspended State will fail.

(10)

Rule 2.3.1: Mobile Applications shall only open logical channels to their respective AID.

Rule 2.3.2: Mobile Applications shall explicitly release UICC logical channel(s) as soon as possible after sending all APDUs in a sequence.

Rule 2.3.3: On a Deactivated event, Mobile Applications shall explicitly release UICC logical channel(s).

Rule 2.3.4: On an Activated event, Mobile Applications shall re-open UICC logical channel(s) before transmitting new APDUs.

It is strongly recommended following all the recommendations about Activation/Deactivation provided by Microsoft at: “Activation and deactivation best practices for Windows Phone 8” on Windows Developer Network (MSDN).

For more details about Windows Phone application life cycle, please refer to both: “App activation and deactivation for Windows Phone 8” and “Launching, resuming, and multitasking for Windows Phone 8” on Windows Developer Network (MSDN).

2.3.2 NFC card emulation state

Windows Phone 8.1 gives end users a fine control over the card emulation state. It is therefore important for an NFC Mobile Application to check the activation state of NFC, and warn the end user if card emulation is not permanently enabled. This is done using the Windows.Devices.SmartCards.SmartCardEmulator class.

Rule 2.3.5: Mobile Applications should ensure that card emulation is permanently enabled and display appropriate status accordingly.

2.3.3 NFC transaction event registration

Windows Phone 8.1 exposes 3 different types of NFC-triggered events:

 Transaction event:

This event can be registered openly (no specific capability is required to use them) as it is subject to the Access-Control List (ACL) rules on the UICC as defined by the Global Platform standard.

 Field-entry and field-exit events:

These events are not bound to a specific AID and represent a less valuable (generic) interaction with the card reader than the transaction event. They must not be used by application developers for UICC transaction purpose and they must be restricted only to developers with access to specific capabilities granted by Microsoft.

(11)

2.3.4 Background tasks and transaction events filtering

In order to receive and process transaction notifications triggered by the UICC, a background task is required (cf. “Guidelines for background tasks” on Windows Developer Network). It must “wake up” the Mobile Application and launch the corresponding user interface only for transaction events triggered by its own AID, as in the following example:

public sealed class NFCTask:IBackgroundTask {

const String TAPINTAP_AID = "A000000004101011"; /* Run method is called when on NFC event */

public void Run(IBackgroundTaskInstance taskInstance) {

HandleEvent(taskInstance); }

/* HandleEvent treats NFC events */

public void HandleEvent(IBackgroundTaskInstance taskInstance) {

var eventDetails = (SmartCardTriggerDetails)taskInstance.TriggerDetails; switch (eventDetails.TriggerType)

{

case SmartCardTriggerType.EmulatorTransaction:

// Check that the transaction event was triggered by my own applet if (eventDetails.SourceAppletId.Equals(TAPINTAP_AID)) { Windows.ApplicationModel.Package.Current.Launch( "/PinPage.xaml?aid=" + eventDetails.SourceAppletId + "&data=" + eventDetails.TriggerData ); } taskInstance.GetDeferral().Complete(); break; } } }

Rule 2.3.7: Background tasks capturing NFC transaction events shall check AID and systematically filter out transactions targeting AID they do not own.

3 M

ANAGEMENT

R

ULES

3.1 Dependencies in terms of device properties and features

The list of operating system properties and APIs features accessed by the Mobile Application must be documented and transmitted to the AFSCM and to the Validation Entity during the AFSCM NFC Applications Validation Process as described in the corresponding AFSCM guides ([R2]).

Rule 3.1.1: The list of all external APIs imported by the Mobile Application shall be provided (including list of proprietary and device-specific APIs).

Rule 3.1.2: The list of all external APIs packaged within the Mobile Application’s binary file shall be provided.

3.2 Usage of personal data

The list of accessed personal data and the description on their handling must be documented and transmitted to the AFSCM and to the Validation Entity during the AFSCM NFC Applications Validation Process as described in the corresponding AFSCM guides ([R2]).

(12)

Rule 3.2.2: The type (or category) of each personal data field accessed by the Mobile Application shall be provided.

Rule 3.2.3: The list of all files and folders accessed by the Mobile Application shall be provided.

Rule 3.2.4: The type of each file accessed by the Mobile Application shall be provided.

Rule 3.2.5: A description of usage of read/write accesses on existing personal data elements shall be provided.

Rule 3.2.6: A description of creation/deletion of personal data elements shall be provided.

Rule 3.2.7: A description of copying, storing and transferring personal data elements and their destination location shall be provided.

In France, depending on the type of data accessed, the Service Provider may have to declare this information to the CNIL (http://www.cnil.fr).

3.3 Publishing a Windows Phone Mobile Application

3.3.1 Structure of the deliverable

A Windows Phone Mobile Application (Windows Runtime app) is packaged as an APPX file format (file extension .appx). This file format is used for the distribution and installation of bundled components onto the Windows Phone mobile device platform.

An APPX file is a ZIP-based container file containing the following items:

 App payload

 App manifest

 App block map

 App signature

More details can be found at: “App packages and deployment (Windows Runtime apps)” on Windows Developer Network (MSDN)

3.3.2 Preparing to Publish

Publishing a Mobile Application means testing it, packaging it appropriately, and making it available to users of Windows Phone powered mobile devices.

Before considering a Mobile Application ready for release, it is recommended to test it using the Windows App Certification Kit which may be downloaded at: “Windows App Certification Kit” on Windows Developer Network (MSDN).

3.3.3 Publishing on Windows Store

The complete description of the end-to-end process of getting a Windows Phone Mobile Application into the Windows Store, from signing up through launch may be found at: “Overview of publishing an app to the Windows Store” on Microsoft Developer Network (MSDN).

(13)

To generate and include this signed file into your project, please refer to the step by step guidelines found in the Microsoft with paper “App development guide for UICC-based NFC card emulation” ([R6]) in chapter “Using an MO-owned certificate for Global Platform (GP) ACL access”.

The signature can be applied either by the Service Providers (‘SP self-signing mode’) or the Mobile Network Operators (‘MNO signing mode’).

Remark: The Microsoft step-by-step guidelines are indeed applicable to both SP self-signing and MNO signing modes, despite its title and description making confusing references only to Mobile Operator (“MO”) owned certificates.

In ‘MNO signing mode’, since the Mobile Application can contain only one unique signed file, the Service Provider will have to publish as many variants of its Mobile Application as there are MNO supported.

Rule 3.3.1: In ‘MNO signing mode’, the Mobile Application name should include the MNO name in order to guide the end user to the correct Mobile Application.

3.3.6 Windows Phone Mobile Application update

In order to clearly identify a given version of the Mobile Application, it is necessary to systematically increment its version number for each published update.

Rule 3.3.2: When publishing an update, the SP should increment the version number of the Mobile Application.

3.4 Connectivity

3.4.1 General Requirements

Many APIs use URLs to refer to resources. Beyond the connection APIs, URLs are also used in media players, and elsewhere.

It is therefore very important to determine properties about URLs, because they are used by the verification process to determine which protocols – connections – resources are used by the Mobile Application. This information can actually be inferred if the URLs comply with simple constraints such as specifying a determined scheme.

Rule 3.4.1: The Mobile Application shallonly use URLs in which the protocol and destination host are determined.

Rule 3.4.2: The Mobile Application shall use fixed host strings (URLs shall not be dynamically built).

3.4.2 Network

The following rules must be respected by the Mobile Application regarding the network connections:

Rule 3.4.3: The Mobile Application shall only use HTTP and HTTPS network connections. In particular, the following low-level protocols are prohibited: datagram, socket, ssl and tcpobex.

Rule 3.4.4: The Mobile Application shall not open connections to numerical IP addresses.

This rule simply consists in forbidding the usage of numerical IP addresses to meet both portability and security requirements.

Rule 3.4.5: The Mobile Application shall not open connections to local host.

(14)

other Mobile Applications. Opening a connection to localhost or to 127.0.0.1 is therefore strictly prohibited since it can be used to get out of the Mobile Application’s sandbox, by performing direct exchanges with native code on the platform.

3.4.3 Server Requests

Microsoft defines a method allowing Windows Phone Mobile Applications to request that the device handles an indicated URL.

Rule 3.4.6: The Mobile Applications shall not use HTTP requests for downloading files. The use of requests should be limited to Web content browsing.

3.4.4 Phone numbers

The following rules must be respected by the Mobile Application when managing phone numbers:

Rule 3.4.7: The Mobile Application shall only use constant or defined phone numbers. This is particularly important to detect costly calls to premium or international numbers.

3.5 Security Requirements

3.5.1 Protection of local assets

The Mobile Application is responsible for the protection of the local assets (= all the information generated and/or handled by the Mobile Application) during their manipulation.

Depending of the type of manipulated asset, the Mobile Application should take appropriate security measures to ensure its protection.

3.5.2 Protection of private user assets

Rule 3.5.1: The Mobile Application shall not access any non-public resources of other Mobile Applications.

Rule 3.5.2: The Mobile Application shall neither access the user’s MSISDN, nor the IMSI, nor the IMEI.

3.5.3 Alteration of assets

Mobile Applications are not supposed to alter or corrupt the assets managed by the mobile Operating System, mostly because these assets are shared with other Mobile Applications and this could lead to severe functional issues.

Rule 3.5.3: The Mobile Application shall not alter user assets without the end user approval (e.g. the Mobile Applications shall not add new contacts or calendar events without the end user approval).

(15)

3.5.4 Confidential assets

The Mobile Application may be responsible to manage confidential assets. These assets are end user’s secrets (e.g. service logins and passwords) or application-own assets (e.g. activation or encryption keys).

Rule 3.5.7: The Mobile Application shall not define default passwords for accessing its services. Most end users never change the password attributed by the service. Thus, defining default password exposes end users to identity theft attacks.

Rule 3.5.8: Mobile Application’s secrets shall not be hard coded in plaintext format in the Mobile Application binary file.

On some devices and some provisioning servers, the Mobile Application binary file is not protected against disclosure. Thus, an attacker could disassemble the Mobile Application’s code and retrieve any secret value it contains.

Rule 3.5.9: Secrets shall not be stored in plaintext format in the local storage.

Developers should particularly consider the issue about persistent storage as files and databases are exposed to data disclosure.

Rule 3.5.10: Secrets shall not be decrypted for comparison.

When possible, the Mobile Application should prefer to perform the verification of secrets on encrypted values. This will prevent the Mobile Application from involuntary storing the plaintext secret value.

3.5.5 Protection of assets among network communications

Most of the assets manipulated by the Mobile Application are not intended to be transmitted to any remote entity. This is the purpose of this section which defines the security guidelines accordingly.

3.5.5.1 Prohibited transmissions

In order to preserve end user's privacy, the Mobile Applications are not allowed to transmit to remote entities some categories of data.

Rule 3.5.11: The Mobile Application shall not send Operator and third party data. Usage of Operator data should be restricted to local computations.

Rule 3.5.12: The Mobile Application shall inform the end user of the usage and storage of end user identification data, end user authentication data, device localization data and device network identification information when these data are sent to a remote server.

3.5.5.2 Secured transmissions

For data that could be exchanged between entities, some of them may require the implementation of specific security mechanisms, especially to prevent social-engineering attacks.

Rule 3.5.13: The Mobile Application shall implement mutual authentication mechanisms when sending end user personal data or mobile network operator data.

Rule 3.5.14: The Mobile Application shall use encrypted communications when sending end user personal data or mobile network operator data.

Rule 3.5.15: The design of the Mobile Application should not permit replay attacks.

This is the only server-oriented security requirement mentioned in this document as it has some impact on the implementation of the local agent. In particular requests to remote servers should be protected against replay attacks, especially authentication requests, as it should not be possible for an attacker to illegally authenticate on servers.

Rule 3.5.16: The Mobile Application shall be able to handle the cases when the Cardlet is not present on the UICC.

(16)

3.6 Protection of the Environment

The security of Mobile Application does not only concern local features, but also requires considering the global environment. Mobile handsets are mobile items in a wide network connecting personal computers, other handsets, other devices (headphone, GPS receiver), through several operating systems and protocols.

Thus, the Mobile Applications are not only the direct target of the attacks: they could be used as communication interfaces (e.g. to propagate a malware program).

Rule 3.5.17: The Mobile Application shall not send any executable program to remote entities. A Mobile Application shall not be a vector to propagate malware programs among the network. The Mobile Applications that send some files are intended to verify these files are not executable files.

Rule 3.5.18: The Mobile Application shall not send binary SMS/MMS messages containing executable code.

This rule is an extension of the previous rule, to precise that is also applies to SMS or MMS binary messages: executable code shall be prohibited in the body of these messages.

Rule 3.5.19: The Mobile Application shall not intensively use network resources.

In particular, the Mobile Application shall not massively send emails or any kind of data because: - It implies a cost to the end user;

- It could have a significant impact on the bandwidth; - It could be associated to spam operations.

(17)

4 A

NNEX

:

S

YNTHESIS OF RULES

The following table lists all the rules defined in the present guide and indicates for each rule if it is a requirement (mandatory) or a recommendation (recommended), and if it is new or updated (or if it has been suppressed).

Rule ID and description

M an d ato ry R e co m m e n d e d C h an ge d ? ( *)

Rule 2.3.1: Mobile Applications shall only open logical channels to their respective AID. X New

Rule 2.3.2: Mobile Applications shall explicitly release UICC logical channel(s) as soon as

possible after sending all APDUs in a sequence. X

New

Rule 2.3.3: On a Deactivated event, Mobile Applications shall explicitly release UICC logical

channel(s). X

New

Rule 2.3.4: On an Activated event, Mobile Applications shall re-open UICC logical channel(s)

before transmitting new APDUs. X

New

Rule 2.3.5: Mobile Applications should ensure that card emulation is permanently enabled and

display appropriate status accordingly. X

New

Rule 2.3.6: Mobile Applications willing to be notified by transaction events sent from the UICC shall create a background task and register it from the main application. X

New

Rule 2.3.7: Background tasks capturing NFC transaction events shall check AID and

systematically filter out transactions targeting AID they do not own. X

New

Rule 3.1.1: The list of all external APIs imported by the Mobile Application shall be provided

(including list of proprietary and device-specific APIs). X

New

Rule 3.1.2: The list of all external APIs packaged within the Mobile Application’s binary file shall

be provided. X

New

Rule 3.2.1: The list of all personal data accessed by the Mobile Application shall be provided. X New

Rule 3.2.2: The type (or category) of each personal data field accessed by the Mobile

Application shall be provided. X

New

Rule 3.2.3: The list of all files and folders accessed by the Mobile Application shall be provided. X New

Rule 3.2.4: The type of each file accessed by the Mobile Application shall be provided. X New

Rule 3.2.5: A description of usage of read/write accesses on existing personal data elements

shall be provided. X

New

Rule 3.2.6: A description of creation/deletion of personal data elements shall be provided. X New

Rule 3.2.7: A description of copying, storing and transferring personal data elements and their

destination location shall be provided. X

New

Rule 3.3.1: In ‘MNO signing mode’, the Mobile Application name should include the MNO name

in order to guide the end user to the correct Mobile Application. X

New

Rule 3.3.2: When publishing an update, the SP should increment the version number of the

Mobile Application. X

New

Rule 3.4.1: The Mobile Application shall only use URLs in which the protocol and destination

host are determined. X

(18)

Rule ID and description M an d ato ry R e co m m e n d e d C h an ge d ? ( *)

Rule 3.4.2: The Mobile Application shall use fixed host strings (URLs shall not be dynamically

built). X

New

Rule 3.4.3: The Mobile Application shall only use HTTP and HTTPS network connections. In

particular, the following low-level protocols are prohibited: datagram, socket, ssl and tcpobex. X

New

Rule 3.4.4: The Mobile Application shall not open connections to numerical IP addresses. This rule simply consists in forbidding the usage of numerical IP addresses to meet both portability and security requirements.

X New

Rule 3.4.5: The Mobile Application shall not open connections to local host.

As previously mentioned, Mobile Applications are not allowed to share data and services with other Mobile Applications. Opening a connection to localhost or to 127.0.0.1 is

therefore strictly prohibited since it can be used to get out of the Mobile Application’s sandbox, by performing direct exchanges with native code on the platform.

X New

Rule 3.4.6: The Mobile Applications shall not use HTTP requests for downloading files.

The use of requests should be limited to Web content browsing. X New Rule 3.4.7: The Mobile Application shall only use constant or defined phone numbers.

This is particularly important to detect costly calls to premium or international numbers. X New Rule 3.5.1: The Mobile Application shall not access any non-public resources of other Mobile

Applications. X New

Rule 3.5.2: The Mobile Application shall neither access the user’s MSISDN, nor the IMSI, nor the

IMEI. X New

Rule 3.5.3: The Mobile Application shall not alter user assets without the end user approval (e.g. the Mobile Applications shall not add new contacts or calendar events without the end user approval).

X New

Rule 3.5.4: The Mobile Application shall verify the consistency of its database.

This rule requests Mobile Applications to perform format verification on the content of the database while inserting or extracting data. This may be useful to detect a record corruption.

X New

Rule 3.5.5: The Mobile Application shall verify the consistency of its files.

This rule requests Mobile Applications to perform format verification on the content of their own files while inserting or extracting data. This may be useful to detect a file’s corruption.

X New

Rule 3.5.6: The Mobile Application shall preserve RFID tags integrity.

The Mobile Application shall make significant effort to preserve the integrity of the RFID tags it writes (e.g. when writing NDEF tags).

X New

(19)

Rule ID and description M an d ato ry R e co m m e n d e d C h an ge d ? ( *)

Rule 3.5.10: Secrets shall not be decrypted for comparison.

When possible, the Mobile Application should prefer to perform the verification of secrets on encrypted values. This will prevent the Mobile Application from involuntary storing the plaintext secret value.

X New

Rule 3.5.11: The Mobile Application shall not send Operator and third party data.

Usage of Operator data should be restricted to local computations. X New Rule 3.5.12: The Mobile Application shall inform the end user of the usage and storage of end

user identification data, end user authentication data, device localization data and device network identification information when these data are sent to a remote server.

X New

Rule 3.5.13: The Mobile Application shall implement mutual authentication mechanisms when

sending end user personal data or mobile network operator data. X New Rule 3.5.14: The Mobile Application shall use encrypted communications when sending end

user personal data or mobile network operator data. X New Rule 3.5.15: The design of the Mobile Application should not permit replay attacks.

This is the only server-oriented security requirement mentioned in this document as it has some impact on the implementation of the local agent. In particular requests to remote servers should be protected against replay attacks, especially authentication requests, as it should not be possible for an attacker to illegally authenticate on servers.

X New

Rule 3.5.16: The Mobile Application shall be able to handle the cases when the Cardlet is not

present on the UICC. X New

Rule 3.5.17: The Mobile Application shall not send any executable program to remote entities. A Mobile Application shall not be a vector to propagate malware programs among the network. The Mobile Applications that send some files are intended to verify these files are not

executable files.

X New

Rule 3.5.18: The Mobile Application shall not send binary SMS/MMS messages containing executable code.

This rule is an extension of the previous rule, to precise that is also applies to SMS or MMS binary messages: executable code shall be prohibited in the body of these messages.

X New

Rule 3.5.19: The Mobile Application shall not intensively use network resources. In particular, the Mobile Application shall not massively send emails or any kind of data because:

- It implies a cost to the end user;

- It could have a significant impact on the bandwidth; - It could be associated to spam operations.

X New

(*) In this column, the rules are marked:

 New if this rule is New, compared with the previous version of the specification

 Upd. if this rule has been Updated from the previous version of the specification

 Suppr.if this rule was in the previous version of the specification and has been Suppressed

If a rule has been kept as-is from the previous version of the specification, it is not marked