NFC Windows Phone Applications. Development Guidelines

NFC Windows Phone Applications Development Guidelines RELEASE 1.0 Date 04/09/2014 Reference afscm-windows-phone-development-guidelines-v1.0-20140904.doc AFSCM Android development guidelines p1/19 Copyright AFSCM20121

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 1.0 04/09/2014 - First release of the guide AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p2/19

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 ANNE: SYNTHESIS OF RULES... 17 AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p3/19

1 INTRODUCTION 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, - Service portability in the event of a mobile equipment swap. AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p4/19

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, EPLICIT 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, knowhow 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 AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p5/19

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 Mandatory AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p6/19

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 [R6] App development guide for UICC-based NFC card emulation Microsoft white paper AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p7/19

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 Cardlet Mobile Application Service Service Provider Validation Entity 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]) JavaCard application loaded onto the UICC (also known as UICC application or applet) Application loaded onto the mobile handset, providing a GUI (also known as MMI or midlet) Combination of a Cardlet and a Mobile Application (also known as NFC service or Mobile NFC service) Entity which provides an NFC service. Entity in charge of validating that the security level in the applications meets the security requirements (typically, a laboratory). AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p8/19

2 WINDOWS PHONE APPLICATION DEVELOPMENT 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. AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p9/19

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. NFC transaction events are handled in background tasks. However, for a background task to be notified, a preliminary registration is necessary from the main application. Cf. chapter Smart card WinRT API for event notifications from the Microsoft white paper App development guide for UICC-based NFC card emulation ([R6]) for more details and examples of code. 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. AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p10/19

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 MANAGEMENT RULES 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]). Rule 3.2.1: The list of all personal data accessed by the Mobile Application shall be provided. AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p11/19

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 APP 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 APP 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). 3.3.4 AFSCM NFC Application Validation Process It is mandatory to perform the NFC Application Validation Process as described in the corresponding AFSCM guides ([R2]) on the Windows Phone Mobile Application to ensure that it respects the rules described in the present guide. 3.3.5 Windows Phone Application signature In order to allow access to the Cardlet on a UICC containing ACL rules defined following the Global Platform standard, the Mobile Application must include a file signed with any certificate authorized by the ACL rules on the UICC. Re-using an existing certificate is supported (e.g. a certificate used to sign the SP Mobile Application on another operating system such as Android). AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p12/19

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. 3.4 Connectivity Rule 3.3.2: When publishing an update, the SP should increment the version number of the Mobile Application. 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 shall only 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. As previously mentioned, Mobile Applications are not allowed to share data and services with AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p13/19

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). 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. 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. 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). AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p14/19

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. AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p15/19

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. AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p16/19

Mandatory Recommended Changed? (*) 4 ANNE: SYNTHESIS 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 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. Rule 2.3.5: Mobile Applications should ensure that card emulation is permanently enabled and display appropriate status accordingly. 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. Rule 2.3.7: Background tasks capturing NFC transaction events shall check AID and systematically filter out transactions targeting AID they do not own. 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. Rule 3.2.1: The list of all personal data accessed by the Mobile Application shall be provided. 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. 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. Rule 3.3.2: When publishing an update, the SP should increment the version number of the Mobile Application. Rule 3.4.1: The Mobile Application shall only use URLs in which the protocol and destination host are determined. AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p17/19

Mandatory Recommended Changed? (*) Rule ID and description Rule 3.4.2: The Mobile Application shall use fixed host strings (URLs shall not be dynamically built). 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. 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. 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. 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. 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. 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). 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. 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. 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). 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. AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p18/19

Mandatory Recommended Changed? (*) Rule ID and description 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. 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. 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. 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. (*) In this column, the rules are marked: if this rule is, 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 END OF DOCUMENT AFSCM NFC Windows Phone Applications Development Guidelines v1.0 p19/19