GSMA MIFARE4Mobile Implementation Guidelines · sector used as a directory for the rest of the card. ... MIFARE4Mobile is a solution first released by NXP ... there is no need to

GSMA MIFARE4Mobile Implementation GuidelinesAPRIL 2015

1 Introduction 03 1.1 Out of Scope 04 1.2 Background on MIFARE and MIFARE4Mobile Technologies 042 MIFARE Technology Used Within a Mobile Environment 053 MIFARE4Mobile V2.1.1 Specification 06 3.1 MIFARE4Mobile V2.1.1 Actors and Entities 06 3.2 MIFARE4Mobile V2.1.1 Framework Architecture 09 3.3 MIFARE4Mobile V2.1.1 User Interface 10 3.4 MIFARE4Mobile V2.1.1 Framework External Interfaces 104 MIFARE4Mobile Deployment Guidelines 12 4.1 Key Assumptions and Recommendations 13 4.2 MIFARE4Mobile Actor to GSMA Actor Mapping 13 4.3 Recommended UICC Configuration 14 4.3.1 UICC Requirements 15 4.3.2 Common UICC Configuration 15 4.3.3 Radio Frequency Protocol Parameters 16 4.4 Migration from MIFARE4Mobile V1 or Any Proprietary MIFARE / MIFARE4Mobile Framework to M4M V2.1.1 17 4.4.1 Co-Existence of M4M V1 and M4M V2.1.1 Frameworks 17 4.5 TSM OTA Configuration 18 4.6 TSM Architectural Models 19 4.7 Recommendations for MIFARE4Mobile User Interface 21 4.7.1 MDAC Mechanism and Impacts on User Interface Development 21 4.8 MIFARE Licensing 21 4.8.1 MIFARE UICC Licence Models 21 4.8.2 Management of MIFARE Licences in a MIFARE4Mobile Framework 21 4.9 Certification and Security Evaluation 22 4.10 MIFARE4Mobile Life Cycle Process Implications 225 MIFARE4Mobile User Experience 236 Summary 27Annex A MIFARE4Mobile V1 and V2.1.1 Co-Existence Solution Description 28 A.1 Management of M4M V1 Services Through TSM API(s) 28 A.1.1 Creation of VCM_0 Instance 28 A.1.2 Creation of VC_0 Virtual Card in MIFARE Implementation 29 A.1.3 Creation of SM_0 “Dummy” Service Manager 31 A.1.4 Association of SM_0 to VCM_0 31 A.1.5 Creation of Service Objects and Associated Metadata Within the “M4M V1 Service Manager” Application 32 A.2 Management of M4M V1 Services Through Wallet API(s) 32 A.2.1 Activation of M4M V1 Services 32 A.2.2 Activation of VCM_0 Instance 32 A.2.3 Deactivation of VCM_0 Instance 32 A.2.4 Deactivation of M4M V1 Services 32Annex B Management of Routing Table on Multi Card Emulation Environment (CEE) Devices 33 B.1 Configuration for MIFARE Classic Services 33 B.2 Configuration for MIFARE DESFire Services 33 Abbreviations 34 References 35

CONTENTS

There are various competing transport ticketing technologies available in the market and this document reviews one of them – MIFARE®. MIFARE technology has been widely adopted in the near field communication (NFC) ecosystem – particularly within the transport and access sectors – and is now one of the most commonly deployed technologies1.

The MIFARE4Mobile specifications aim at enabling consistent distribution and management of MIFARE applications on mobile devices, while keeping them compatible with the existing NFC-enabled card reader infrastructure. The release of the GSMA MIFARE4Mobile Implementation Guidelines moves the industry towards a uniform approach to deliver ticketing and access services at scale on NFC-enabled devices by:

• Formulating recommendations and highlighting preferred options from MIFARE4Mobile specifications.• Defining a migration path from existing mobile MIFARE solutions to MIFARE4Mobile V2.1.1.

The MIFARE4Mobile V2.1.1 specification has been developed by the MIFARE4Mobile Industry Group as the first interoperable multi-vendor MIFARE4Mobile solution. (Note: Previous versions of MIFARE4Mobile specifications that were supporting only MIFARE Classic were not interoperable.) The objective was to:

• Develop an architecture relying on GlobalPlatfom for life cycle management and the co-existence with non-MIFARE NFC services on a secure element (SE) to ensure that the MIFARE4Mobile solution is interoperable across different vendors, independent of SE form factors and covers the business relationships between the various ecosystem actors. • Increase interoperability by leveraging deployments of existing card and reader infrastructure.

The aim of this document is to provide guidance to the mobile operator community on the fundamental aspects of MIFARE4Mobile technology to aid business development and technical project managers in understanding the requirements around the deployment of a MIFARE4Mobile solution. These guidelines will assist mobile operators and service providers to deliver a consistent user experience and will detail technical considerations for implementations.

The goal is to endorse MIFARE4Mobile V2.1.1 technology as the targeted framework for the deployment of MIFARE-based mobile services, and to define a migration path from the existing solutions to MIFARE4Mobile V2.1.1. The target audience of this document is, therefore, mobile operators and service providers wishing to support MIFARE technology on UICCs (commonly known as SIM cards). MIFARE4Mobile technology is compatible with a variety of secure elements (including UICCs, embedded secure elements and embedded Secure Digital cards), however, this document focuses on the UICC as the GSMA recommends that the UICC is used as the secure element.

About the MIFARE4Mobile Industry GroupThe MIFARE4Mobile® Industry Group consists of leading players in the NFC ecosystem including Gemalto, Giesecke & Devrient, NXP Semiconductors, Oberthur Technologies and STMicroelectronics. The group acts as a platform to guide the evolution of MIFARE4Mobile technology. The aim of the MIFARE4Mobile Industry Group is to standardise and advance the uniform management of MIFARE applications on NFC-enabled secure elements, such as SIM cards and mobile phones.

MIFARE4Mobile is a registered trademark of NXP Semiconductors N.V. About the GSMAThe GSMA represents the interests of mobile operators worldwide, uniting nearly 800 operators with more than 250 companies in the broader mobile ecosystem, including handset and device makers, software companies, equipment providers and Internet companies, as well as organisations in adjacent industry sectors. The GSMA also produces industry-leading events such as Mobile World Congress, Mobile World Congress Shanghai and the Mobile 360 Series conferences.

03

1.

Introduction

1. MIFARE is currently deployed in the infrastructure of 730+ cities around the world, key deployments are Oyster in London, UK; OV–Chipcard in the Netherlands; and CharlieCard in Boston, US. Source: http://www.nxp.com/.

1.1 Out of Scope

This document does not aim to address or discuss the following:

• Radio Frequency (RF) interoperability at the card reader (i.e. Type A vs Type B).• MIFARE Classic and MIFARE DESFire security evaluations. 1.2 Background on MIFARE and MIFARE4Mobile Technologies

MIFARE is a technology owned by NXP Semiconductors. It is based on the ISO/IEC 14443 Type A contactless smart card standard. The term MIFARE refers to several different variants of contactless cards: MIFARE Classic; MIFARE Classic EV1; MIFARE Ultralight; MIFARE Ultralight C; MIFARE Ultralight EV1; MIFARE DESFire; MIFARE DESFire EV1; MIFARE DESFire EV2; and MIFARE Plus. For further information regarding MIFARE technology, refer to the NXP Semiconductors website. To assist readers of this document in understanding the full breadth of MIFARE4Mobile, some clarification about the key technical differences between MIFARE Classic, MIFARE DESFire and MIFARE Plus is provided below: • MIFARE Classic – MIFARE Classic uses sectors, which are configured to manage application data, with the first sector used as a directory for the rest of the card. MIFARE Classic 1K allows 15 different applications to be stored on a MIFARE card and these applications are separate and secure from one another using unique keys for each sector. MIFARE Classic 4K could support up to 40 applications. Note that the messaging is proprietary and is not ISO/IEC 14443-4 compliant. • MIFARE DESFire – MIFARE DESFire is based on open global standards for both over-the-air interface as well as cryptographic methods such as Triple DES (TDES) and Advanced Encryption Standard (AES). It is compliant with ISO/IEC 14443 part 1, 2, 3 and 4 (Type A) and uses optional ISO/IEC 7816-4 commands. MIFARE DESFire is NFC Forum Type 4 Tag compatible. It is widely available from NXP and licensed partners for use on secure elements in mobile phones such as UICCs and embedded secure elements. • MIFARE Plus – MIFARE Plus offers a straightforward upgrade to AES security for existing MIFARE Classic based systems. The support for MIFARE Plus will be

included in the next generation of MIFARE4Mobile. MIFARE4Mobile is a solution first released by NXP Semiconductors in 2008 to provide support for the managing of MIFARE-based applications on mobile devices. The latest version of MIFARE4Mobile specifications is MIFARE4Mobile Version 2.1.1. To clearly distinguish MIFARE4Mobile V2.1.1 from previous versions of MIFARE frameworks and specifications, early versions of the MIFARE4Mobile technology are referred to as “MIFARE4Mobile V1” within the remainder of the document. Note that these early implementations of the MIFARE4Mobile technology may also refer to services launched on proprietary MIFARE frameworks. One of the fundamental differences between MIFARE4Mobile V2.1.1 and MIFARE4Mobile V1 is that MIFARE4Mobile V2.1.1 is based on a multiple Virtual Card concept, while MIFARE4Mobile V1 is based on a single MIFARE Card sharing multiple Service Objects. In MIFARE4Mobile V1, all services are implemented in Service Objects, which must make use of the single Virtual Card available, eventually needing to be swapped in and out of it. In MIFARE4Mobile V2.1.1, multiple Virtual Cards exist concurrently, containing the user data permanently so there is no need to swap the data in and out.

04

GSMA MIFARE4Mobile Implementation Guidelines

http://www.nxp.com

2.

MIFARE Technology Used Within a Mobile EnvironmentMobile operators across the globe are exploring, testing or launching NFC based services that support the storage of electronic versions of access credentials (e.g. transport tickets) on a mobile device. A ticket can be delivered securely over the air to the passenger’s NFC-enabled mobile device and be validated by the ISO/IEC 14443 contactless readers of the transport operator.

The fundamental requirements to enable ticketing and access management on NFC-enabled devices is to ensure full interoperability with the existing infrastructure while maintaining a consistent consumer experience over all NFC services. These considerations were key when developing the implementation guidelines outlined in this document.

Previous implementations of MIFARE technology for mobile devices have faced the following challenges:

• The absence of interoperability and standardisation increased the complexity of deploying MIFARE solutions in a mobile environment. • The maintenance of the MIFARE technology security / trust model – MIFARE technology supports the use of symmetric keys and end-to-end (E2E) security is a key consideration. The transport authority needs to trust that the security model employed by the card-to-reader transaction authentication (i.e. the use of symmetric keys) offers the same level of security when extended to a mobile environment.• Managing multiple virtual cards on the same UICC, potentially making use of incompatible contactless parameters.

The goal of MIFARE4Mobile V2.1.1 is to address these challenges and provide an interoperable solution to mobile operators and service providers, in compliance with

GlobalPlatform architecture and life cycle management tools. The ambition is to pave the way for interoperability across the ticketing and access control ecosystem in a mobile environment. By interoperability, we mean:

Mobile operator / service provider interfaces:• Ensuring compatibility with the existing service provider infrastructure.• Providing an “umbrella” framework to leverage interoperability between existing MIFARE deployments, while reducing deployment costs and speeding up time-to-market.

OTA remote management:• Allowing service providers to access their assigned MIFARE resources over-the-air in a consistent and interoperable way.• Ensuring a uniform management of the MIFARE application life cycle – offering service providers a standardised interface to access their entire customer base.

Secure element platform:• By providing common access to the hardware resources of the MIFARE implementation, reducing complex and expensive integration activities.

05

MIFARE4Mobile V2.1.1 specifications are owned by the MIFARE4Mobile Industry Group, which consists of UICC-based secure element, embedded secure element (eSE) and Trusted Service Manager (TSM) providers. The MIFARE4Mobile V2.1.1 framework provides new software components and Application Programming Interfaces (APIs) to deploy MIFARE services by the standardisation of MIFARE deployments within the NFC ecosystem. This section provides a high-level overview of the new actors and entities introduced within the MIFARE4Mobile V2.1.1 specifications. The full and detailed specifications are available for download at the MIFARE4Mobile website.

3.

MIFARE4Mobile V2.1.1 Specification

3.1 MIFARE4Mobile V2.1.1 Actors and Entities

MIFARE4Mobile V2.1.1 has introduced specific actors and entities to help MIFARE technology deployment within a mobile environment. This section provides an overview of them to introduce readers to the MIFARE4Mobile technology.

Table 1 provides a brief description of the actors outlined in the MIFARE4Mobile V2.1.1 specification.

The MIFARE4Mobile specifications aim at enabling consistent distribution and management of MIFARE applications on mobile devices, while keeping them compatible with the existing NFC-enabled card reader infrastructure.

06


http://mifare4mobile.org

ServiceManager

Trusted ServiceManager(s)

Virtual Card Owner

Issuer SecurityDomain

Controlling Authority Security Domain

Secure Element Issuer

ControllingAuthorityService Provider

Secure Element (UICC)

MIFARE Implementation

MIFARE ApplicationVirtual CardMIFARE

Implementation Owner

Virtual Card Manager

Security Domain Security Domain

Table 1: MIFARE4Mobile V2.1.1 actors

MIFARE4Mobile V2.1.1 actors Description

Virtual Card OwnerA Virtual Card Owner is the entity that controls a Virtual Card and its associated Virtual Card Manager (VCM). The role of the Virtual Card Owner may be performed by most players in the NFC ecosystem – such as a mobile operator, TSM, service provider or MIFARE Implementation Owner, etc.

MIFARE Implementation OwnerA MIFARE Implementation Owner is responsible for the administration and management of MIFARE4Mobile licences. Typically, the role of the MIFARE Implementation Owner is fulfilled by the Secure Element Issuer, for example, the mobile operator for UICC-based delpoyments.

Service Provider A Service Provider (SP) is responsible for deploying and managing the MIFARE4Mobile Services from an end user perspective.

Trusted Service ManagerTrusted third party responsible for Security Domain management, service management, and delivery on behalf of Service Providers or the Secure Element Issuer. It commonly performs the functions assigned to the Security Domain Manager role.

Secure Element Issuer

A Secure Element Issuer (SEI) is responsible for provisioning the Secure Element (SE), and allowing access to Service Providers. The Secure Element Issuer owns the Secure Element Issuer Security Domain. An Issuer Security Domain is the primary, mandatory, on-card component representative of the Secure Element Issuer. In case MIFARE services are deployed on a UICC, the Secure Element Issuer role is owned by the mobile operator.

Controlling Authority A Controlling Authority is a trusted independent third party that enforces security policies. The Controlling Authority Security Domain (CA SD) is the on-card representative of this party.

Figure 1 uses the actors described in Table 1 to provide a graphical representation of their relationship to the entities described within the MIFARE4Mobile V2.1.1 specification, including insight into how the various actors and entities interact.

Note: In the following figure, colour coding has been applied to allow readers to easily identify which actor is managing which secure element entity.

07

Figure 1: High-level overview of actors and concepts in MIFARE4Mobile V2.1.1

The remainder of Section 3.1 describes the MIFARE4Mobile V2.1.1 entities that reside on the UICC. A Service Manager (SM) is the on-UICC entity representative of the Service Provider; it is a contactless Java Card application that is a logical representation of a MIFARE Application, which is physically implemented in a Virtual Card of the MIFARE Implementation. A MIFARE Implementation is the component in a Secure Element that implements MIFARE functionality and manages memory resources to hold one or more Virtual Cards contained within Virtual Card entries of the MIFARE Implementation. Note: The MIFARE4Mobile V2.1.1 specification only allows one MIFARE Implementation per UICC (which may be configured in-factory). Virtual Cards (VC) are defined by the following characteristics2:• A set of specific contactless protocol parameters for the different MIFARE technologies.• MIFARE technologies (MIFARE Classic or DESFire).• Memory space.• MIFARE host capability (that is, whether they can host more than one MIFARE application). Roles and responsibilities for the creation of Virtual Cards (described within the MIFARE4Mobile V2.1.1 specification) are defined within the MIFARE4Mobile 2.1.1 − End-to-End Simplified Framework document [11]. The Virtual Card Manager (VCM) is the on-card representation of a Virtual Card Owner. It can create Virtual Cards, or take ownership of an existing Virtual Card. The Virtual Card Manager is a contactless Java Card application that is a logical representation of a MIFARE Virtual Card that is physically implemented in the MIFARE Implementation. It is used to manage the life cycle of a Virtual Card. If secure elements are deployed with a set of pre-created Virtual Cards, then the MIFARE4Mobile specification V2.1.1 provides a mechanism for a Virtual Card Manager to take ownership of existing Virtual Cards using an “authentication” process3. The Virtual Card Manager maintains a list of “Allocated Resources per Associated Service Manager” (ARASM) to assign MIFARE resources to a Service Manager. Each ARASM has the capability to allocate the following MIFARE resources in the MIFARE Implementation: • For MIFARE Classic Virtual Card − a list of sector numbers.• For MIFARE DESFire Virtual Cards − a list of MIFARE DESFire Application IDs.

A MIFARE Application is a collection of data, keys and access conditions loaded in the memory of the MIFARE-enabled device.

The MIFARE4Mobile V2.1.1 (M4M V2.1.1) specification allows different combinations of contactless applications to co-exist and be simultaneously active at the contactless interface. Therefore, the Secure Element has the capability (depending on memory capacity) to host several MIFARE services.

The M4M V2.1.1 specification prescribes the following rules for the co-existence of Virtual Card combinations: • Only one MIFARE Classic Virtual Card may be active at any one time.• A single MIFARE Classic Virtual Card and one or more MIFARE DESFire Virtual Cards may be active simultaneously if supported by the MIFARE Implementation.• Several MIFARE DESFire Virtual Cards may be active at the same time if all MIFARE DESFire applications have unique Application Identifiers and if this is supported by the MIFARE Implementation as well as the NFC card readers. Note: A MIFARE Classic sector cannot be shared by several MIFARE Applications deployed by different service providers. If two MIFARE Applications use the same sector, then they cannot be implemented on the same Virtual Card. If there are Virtual Cards activated concurrently, their contactless protocol parameters should be the same so they do not conflict (for further details on protocol parameter conflict, see GlobalPlatform Amendment C [3]).

08


2. The characteristics listed are defined when the Virtual Card is created by the Virtual Card Creation String instruction. 3. See MIFARE4Mobile specification V2.1.1 for further information regarding the authentication process.



MIFARE ApplicationVirtual Card

CRSapplication

Contactless Interface

MNO TSM Mobile Device

Security Domain Security Domain

MIFAREContactless Reader

Service Provider

SP TSM


ServiceManager

Mobile operator wallet application

Service-specificapplication

3.2 MIFARE4Mobile V2.1.1 Framework Architecture

The MIFARE4Mobile V2.1.1 framework specifies the mechanisms to remotely manage MIFARE technology within the mobile environment and allow the user to access the MIFARE service via a user interface. The MIFARE4Mobile V2.1.1 framework does not provide advice, however, on how to implement a MIFARE solution nor does it provide guidance on co-existence with other non-MIFARE NFC services.

Note: The MIFARE4Mobile V2.1.1 framework relies on standardised GlobalPlatform mechanisms to handle the co-existence of the MIFARE Service with other contactless applications.

Actors and entities shown in orange in Figure 2 represent mobile operator responsibilities, whereas actors and entities shown in grey represent service provider responsibilities.

Figure 2 provides a graphical representation of how all of the MIFARE4Mobile V2.1.1 components can interact via the available options described in the M4M V2.1.1 specification. Within the remainder of this document − and utilising the approach from the MIFARE4Mobile E2E Simplified Framework recommendations [11] − the aim is to reduce the range of options and provide guidance on how to simplify M4M deployments.

09

Figure 2: MIFARE4Mobile recommended simplified architecture

3.3 MIFARE4Mobile V2.1.1 User Interface

Within the context of the MIFARE4Mobile V2.1.1 framework, the “wallet” application is a graphical user interface provided by the service provider or mobile operator, which interfaces with and manages the associated VC Manager and Service Manager. The MIFARE4Mobile V2.1.1 framework provides options for the wallet application to be implemented within the handset or the SE. (For information on the recommended implementation option, see sections 4.1 and 4.7.)

The MIFARE4Mobile Service Manager is used to retrieve the information relative to the MIFARE Application it manages. It allows the end user to activate and deactivate the MIFARE Application (including Virual Cards). The MIFARE4Mobile framework defines an optional component called the Parser to process the raw data retrieved from the MIFARE Application. The Parser may be on the mobile device if the raw data are not considered as confidential by the service provider or it may be in the SE if the raw data are confidential. The service-specific application can call the Parser directly or via the Service Manager.

Two different types of user interfaces can be used to access MIFARE4Mobile services via the SE:

• Mobile operator wallet application – This type of wallet application allows access to other mobile applications using their graphical user interfaces4. It is aware of all instances of MIFARE4Mobile Service Managers and Virtual Card Managers in the secure element, and any non-MIFARE4Mobile NFC applications. The mobile operator wallet application allows the user to manage the installed services (i.e. selecting “default” applications for some services). Therefore, the mobile operator wallet application needs to create an internal representation of the MIFARE4Mobile services installed and activated on the UICC, with the knowledge of which MIFARE applications share Virtual Cards. The wallet application user interface needs to be designed with this knowledge and information to allow the mobile operator wallet application to facilitate different services using the SE. (The GlobalPlatform and MIFARE4Mobile architecture provides a set of tools for a mobile operator wallet application to gather information about the installed MIFARE4Mobile services.)

• Service-specific application – This type of application only caters to a single service from a service provider. A MIFARE4Mobile service-specific application only interacts with the Service Manager implementing that specific MIFARE4Mobile service. This application is pre-set with the Application Identifier of the Service

Manager, as well as the data structures and semantics of SP information. Essentially, a dedicated mobile service-specific application would be used to access the provisioning service. Note: These applications are not mutually exclusive and the mobile operator wallet application shall be the interface to the service-specific application when activating or deactivating a MIFARE Application on the UICC (through the Contactless Registry Service).

3.4 MIFARE4Mobile V2.1.1 Framework External Interfaces

MIFARE4Mobile V2.1.1 exposes two external interfaces (the Remote Management API and the Wallet API) to allow off-card entities to interact with the MIFARE4Mobile V2.1.1 framework components.

The Remote Management (RM) API provides the mechanisms to allow remote management of MIFARE4Mobile components and Virtual Cards, allowing a service provider to manage the life cycle and content of the MIFARE Application. The RM API provides mechanisms to remotely create, delete, and lock MIFARE Applications and update the data keys. It also provides access control functionality. These are typically used by the Secure Element Issuer and Service Provider TSM to install MIFARE services and manage in-life (post issuance) events. The MIFARE4Mobile Remote Management commands and responses are embedded as the payload of a GlobalPlatform STORE DATA APDU command, which is issued to the Security Domain where the targeted Virtual Card Manager or Service Manager resides. For further details on the Remote Management API, refer to the MIFARE4Mobile Remote Management API specification [8].

The Wallet API provides logical “hooks” for the wallet application (i.e. user interface) to interact with the user. This interface is used to provide generic information about the MIFARE Application, as well as user data stored in the VC. It also provides functionality to activate and deactivate a VC, used by the service-specific application.

For further details on the Wallet API, refer to the MIFARE4Mobile Wallet API specification [9].

10


4. An interoperable “wallet” interface has been standardised within the GSMA’s Core Wallet API document [2]. The term “core wallet” refers to a subset of features, protocols and interfaces that different mobile operators’ mobile wallet applications should support. The GSMA’s Core Wallet API is designed to provide a consistent and interoperable offering to service providers for NFC-based services and to host applications produced by the service providers.

4.

MIFARE4Mobile Deployment GuidelinesWhen investigating the deployment of a MIFARE4Mobile based solution, there are a number of technical considerations that need to be understood by the mobile operator / solution provider. For example, the MIFARE4Mobile V2.1.1 framework requires new MIFARE-specific functional entities to be established in order to simplify solution deployments. It also has specific requirements on the delivery path of MIFARE4Mobile user data to the mobile device. This section aims to provide a high-level overview of the technical considerations involved when deploying a MIFARE4Mobile solution. By clarifying and highlighting preferred options, it also provides guidelines for mobile operators to enable them to implement the specifications in an interoperable way.

The following topics are covered:

• UICC requirements and a proposed common UICC configuration. For details, see Section 4.3.• OTA platform TSMs required to support additional functionality over and above requirements for payment applications. For details, see Section 4.5.

Note: The technical considerations outlined below have business and commercial implications, such as acquisition requirements for UICCs and TSMs; these business considerations are considered beyond the scope of this document and should be assessed on a per-deployment basis.

The description of ticket types and transactional modes are considered to be out of scope from this document – both of these should be understood with their impact assessed by service providers during their system design phase.

12


4.1 Key Assumptions and Recommendations

This section lists the key assumptions and main recommendations that serve as the basis of the guidelines outlined in the remainder of Section 4.The key assumptions are as follows:

• Services are managed in Simple Mode5 (card content management mode) by the MNO TSM, with service life cycle event commands sent to the consumer’s device through the MNO TSM. For details on OTA communication channels, see section 4.5.• The mobile operator is responsible for maintaining shared UICC components.• There is no User Verifier on the UICC.• The service provider provides a mechanism to allow the MIFARE4Mobile user interface to display service data. The main recommendations for a MIFARE4Mobile V2.1.1 solution – based on the assumptions highlighted above − are listed as follows:

• The mobile operator owns the “wholesale Virtual Card creation key” allowing the creation of a Virtual Card.• There is only one Service Manager per VC Manager. • There is no User Verifier on the UICC.• A Contactless Registry Service (CRS) application on the UICC shall be used to activate and deactivate a Virtual Card.• There is no user interface in the secure element.

4.2 MIFARE4Mobile Actor to GSMA Actor Mapping

Table 2 clarifies some of the terms used in theMIFARE4Mobile specifications (in particular, terminology with regards to actors and roles) and aligns them with terms used in the GSMA documentation.

13

5. By definition, Simple Mode uses the mobile operator OTA capability. However, this may not be used for in-life messages (such as buy ticket, send ticket and provide access credentials).

When investigating the deployment of a MIFARE4Mobile based solution, there are a number of technical considerations that need to be understood by the mobile operator.

Table 2: MIFARE4Mobile actors and GSMA actors

MIFARE4Mobile V2.1.1 actors GSMA actors

Virtual Card Owner Mobile Operator

MIFARE Implementation Owner Mobile Operator

Service Provider Access Control / Transport Operators

Trusted Service Manager MNO TSM supporting service deployment with an option for the SP TSM or the MNO TSM to provide support for in-life messaging

Secure Element Issuer Mobile Operator

Controlling Authority SIM/UICC Provider

Figure 3 provides a graphical representation of the MIFARE4Mobile actors highlighted in Table 2. Actors and entities shown in orange represent mobile operator responsibilities, whereas actors and entities shown in grey represent service provider responsibilities.




Issuer Security Domain

Service Provider

Security Domain

Controlling Authority Security Domain

Security Domain

MIFAREImplementation

Owner

Virtual CardOwner

Secure ElementIssuer

ControllingAuthority


ServiceManager

MNO TSMSP TSM

4.3 Recommended UICC Configuration

Traditional ticketing and access technologies have been deployed within a system where only the transport operator has complete control over the issuance, validation and management of the card technology. Limiting the number of players reduces the risk of fraud and vulnerabilities. When the environment is extended to include mobile operators, it is important to maintain card-to-reader authentication by allowing and enabling service providers to manage their own authentication keys.

Hence, with the introduction of the MIFARE technology into the mobile environment, additional requirements are placed on the UICC for the deployment and operation of a MIFARE service. For example, UICCs on the field shall be changed to support MIFARE4Mobile V2.1.1.

This section provides an overview of the GSMA’s UICC recommendations for MIFARE4Mobile V2.1.1 deployments.

14


Figure 3: Visualisation of GSMA MIFARE4Mobile actors

4.3.1 UICC Requirements

To support MIFARE4Mobile V2.1.1 based deployments, the following requirements apply for the UICC:

• A new UICC configuration is required6, as well as a new UICC operating system (OS) to support the MIFARE4Mobile V2.1.1 implementation. • It is recommended that mobile operators’ UICCs are compliant with the GSMA’s NFC UICC Requirements Specification V5.0 (including A.2) [1] or later.

4.3.2 Common UICC Configuration

The recommendation is to rely on a common UICC configuration (defined below) and a standardised delivery communication path when providing services to consumers. This approach would provide scope to standardise testing requirements, reduce costs and reduce time to market.

The recommendation is to pre-load (at manufacturing) the UICC application packages into a shared Utility Security Domain; this is managed by the mobile operator and accessible to the service provider (and their respective SP TSMs if required) [11]. This could greatly simplify the loading of application packages (i.e. the MIFARE4Mobile Execution Load File) when deployed in Simple Mode.





Virtual Card Security Domain

MIFARE4MobileELF

Utility Security Domain

SP 1 Security Domain

SP 1 Trusted Service Manager

ServiceManager 1


MNO TSM

15

Figure 4: Suggested approach for MIFARE4Mobile V2.1.1 using a shared Utility SD

6. This is dependent on whether the UICCs already in the field meet the criteria described in this section.

The Utility Security Domain contains one Executable Load File (ELF) with two modules: a Service Manager and a Virtual Card Manager. Using the shared MIFARE4Mobile application package, Virtual Card Managers and Service Managers can be instantiated in respective dedicated Supplementary Security Domains. The recommendation is to instantiate all Virtual Card Managers in a single Virtual Card Security Domain.

According to the MIFARE4Mobile E2E Simplified Framework document, only a single MIFARE4Mobile Executable Load File shall be loaded.

It is recommended that the MIFARE Implementation Owner is the mobile operator, who is also responsible for updating the shared components, i.e. the contents of the Utility Security Domain.

4.3.3 Radio Frequency Protocol Parameters

Given the fast pace of adoption of NFC services, more and more services are being delivered to consumers. To support this increase in demand, there is the possibility of multiple NFC services existing and being supported on the same mobile device. NFC services originating from different sources may request a mixture of Radio Frequency (RF) parameters, in order to maintain physical card experiences and be detected by the NFC reader infrastructure. This could create a number of challenges for the mobile operator when managing the radio frequency parameters on the NFC interface.

This section has been included to clarify the requirements for configuring the radio frequency protocol parameters, also known as contactless protocol parameters, of a UICC and its purpose is to enhance information provided in the GSMA’s NFC Multi Protocols for Interoperability document [10]. This document [10] defined contactless protocol parameters at the card level, i.e. parameters that apply to all applications installed on the card.

In some cases, however, those card-level parameters do not fit in a particular contactless infrastructure, and therefore the service provider will have to define contactless parameters at the application level. This could be the case of the Unique Identifier parameter and further details on this are provided in the next section.

4.3.3.1 Handling and Managing Unique Identifiers

For operators who wish to configure the RF protocol parameters on the UICC, it is recommended that they analyse the local deployment market to identify what type of MIFARE technology is existing live in the field and whether new technologies are planned to be deployed. The mobile operator will need to understand whether the local environment requires the support of 4-byte Unique Identifier (UIDs)7. As of Q2 2010, NXP have informed their customers that

unique8 4-byte Unique Identifiers will be discontinued. NXP recommended their customers to purchase either MIFARE Classic products with unique 7-byte identifiers or 4-byte non-unique identifiers.

Potentially, a situation may occur where in a particular region there could be a mixed estate of NFC card acceptance readers, with each deployment requiring a different Unique Identifier configuration. The choice of the Unique Identifier type is the responsibility of the service provider to ensure that it is supported within the existing infrastructure.

In MIFARE4Mobile V2.1.1, application-specific protocol parameters − among them, Unique Identifiers − are assigned at virtual card creation. The Virtual Card Manager retrieves protocol parameters from their associated Virtual Cards and writes the protocol parameter values in the GlobalPlatform registry. Upon the activation of the Virtual Card Manager / Service Manager, the Contactless Registry Service calculates the optimum configuration for protocol parameter values (based on the stored protocol parameters plus the mask values of all activated contactless applications [including the Virtual Card Manager and Service Manager]). The Contactless Registry Service (CRS) then provides the protocol parameters to the Contactless Front End (CLF) with a Single Wire Protocol (SWP) / Host Controller Interface (HCI) pipe.

For MIFARE Classic, SPs could request any of the following:

• The 7-byte Unique Identifier of the SE. • The 4-byte Fixed but non-unique ID (FnUID) derived from the 7-byte Unique Identifier of the SE.• Other FnUID provided by the service provider if the 4-byte FnUID derived from the SE 7-byte UID collides with the FnUID of a card available in the SP infrastructure.

MIFARE DESFire is always created with a 7-byte Unique Identifier of the SE. However, the Service Provider could request that one of the following identifiers is presented during ISO activation:

• A 4-byte random Unique Identifier. • The 7-byte Unique Identifier of the SE.

Note: 7-byte Unique Identifiers of the SE will be provided by the secure element manufacturers since they have them registered under their vendor code with ISO/IEC 7816. Each Unique Identifier attached to a specific Virtual Card is the 7-byte SE Unique Identifier or a 4-byte FnUID, either derived from it or obtained otherwise.

For MIFARE Classic based 4-byte FnUID installations and in order to ensure compatibility with the deployed infrastructure, it is recommended that 4-byte FnUID serial numbers are unique within a specific local market.


16

7. Each silicon manufacturer manages its own Unique Identifier pool, therefore no central library or uniform view exists. 8. Note: ISO/IEC 14443 Type A defines a Unique Identifier used for card activation; it defines three different sizes for a Unique Identifier: single (4), double (7), and triple (10) byte sizes. In early MIFARE contactless systems, the UID is used both for card activation and as a logical “user / passenger” identifier. The UID is also used as a derivation input for the calculation of individual service keys.

4.4 Migration from MIFARE4Mobile V1 or Any Proprietary MIFARE / MIFARE4Mobile Framework to M4M V2.1.1

To address in-field demands for the deployment of MIFARE services, some mobile operators launched MIFARE services based on previous versions of MIFARE4Mobile specifications, or even on proprietary MIFARE frameworks.

When migrating from MIFARE4Mobile V1 (M4M V1) to M4M V2.1.1, mobile operators will need to replace UICCs with those supporting a new UICC operating system (for more information, see section 4.3.1). Mobile operators and SP TSMs will require an update to support the MIFARE4Mobile V2.1.1 framework and APIs.

The MIFARE4Mobile E2E Simplified Framework does not take into account any pre-existing MIFARE deployment, it assumes a new MIFARE4Mobile V2.1.1 deployment and supporting infrastructure. Therefore, guidance is needed with regards to scenarios where M4M V1 and M4M V2.1.1 frameworks co-exist or where there is a need to migrate from M4M V.1 implementations to M4M V2.1.1.

Whenever possible, it is recommended to “synchronise” the upgrade of TSM platforms (i.e. both MNO TSM and SP TSM[s]) with new UICC rollouts, in order to ensure the smooth rollout of M4M V2.1.1 services on new M4M V2.1.1 capable UICCs. Nevertheless, this scenario may not be possible in some markets, for example, when SP TSM(s) or the SP TSM hub have their own migration roadmap that does not coincide with the mobile operator’s UICC rollout plan.

It is therefore important to understand local market conditions to be able to assess if a co-existence or migration strategy is required. The GSMA has identified conceptual migration solutions which may be possible, listed as follows:

• Migration from proprietary MIFARE Classic / DESFire (including M4M V1) to M4M V2.1.1 – This conceptual migration path may be difficult to implement due to the fact that the Remote Management and Wallet APIs of M4M V1 and V2.1.1 are not compatible, and the service needs to be re-coded with a new Java Card API. Each SE vendor has a slightly different solution to implement this use case, the recommendation for mobile operators is to contact their respective SE vendors individually to determine whether this migration would be possible with their implementation.

Recommendation: This migration path is complex and uncertain, the GSMA does not recommend this option.

• M4M V1 services to exist within an M4M V2.1.1 framework − M4M V1 Service Objects are not supported by M4M V2.1.1. Therefore, the remote management of an M4M V1 Service Manager is not compatible with the remote management of an M4M

V2.1.1 Service Manager. M4M V1 is based on the concept of the Service Object that is copied into the Virtual Card when the service is activated. Whereas M4M V2.1.1 does not store any MIFARE data in the SM but in the Virtual Card. The activation of a service requires the activation of the Virtual Card Manager.

Recommendation: This migration path is complex and uncertain, the GSMA does not recommend this option.

• M4M V1 framework to co-exist within a M4M V2.1.1 framework – As stated in the next section (Section 4.4.1), it is possible for both versions of the framework (including a proprietary implementation) to co-exist if a Virtual Card is reserved for M4M V1. As a reminder, the Remote Management API and Wallet API specified by M4M V2.1.1 are not backward compatible with previous versions of the framework. Even if the M4M V2.1.1 specification mentions that a Virtual Card may be reserved to support the Java Card javacardx.external. MemoryAccess interface, it does not describe how this scenario should be implemented. Annex A defines a solution that allows for the implementation of such a co-existence scenario, i.e. where a VC is reserved by M4M V2.1.1 for M4M V1 services.

Recommendation: This is the recommended migration path in case a co-existence scenario cannot be avoided.

4.4.1 Co-Existence of M4M V1 and M4M V2.1.1 Frameworks

As mentioned above, in some markets, various versions of MIFARE4Mobile V1 have been deployed, with each card vendor implementing its own flavour of MIFARE4Mobile V1.

In addition, since the remote administration of M4M V1 services is not compliant with Card Content Management (CCM) standards (in particular GlobalPlatform), SP TSM vendors invested in some ad-hoc developments. Therefore, the remote administration of M4M V2.1.1 services will require an upgrade of both MNO TSM and SP TSM software.

As a consequence, a situation might arise where a new UICC embedding an M4M V2.1.1 framework is deployed by a mobile operator on a local market where MNO / SP TSMs have been deployed to support M4M V1 services. Since it is not possible to guarantee that the migration of those platforms to M4M V2.1.1 will be synchronised with the new UICC deployment, guidance is needed on how to manage M4M V1 services on the new UICC within a M4M V2.1.1 framework. For details on a suggested solution, see Annex A.

Note: This specific configuration has not been fully addressed by MIFARE4Mobile V2.1.1 specifications, and therefore will not be part of the MIFARE4Mobile Industry Group certification programme. As a consequence, an additional testing effort will be required from mobile operators implementing this solution.

17

4.5 TSM OTA Configuration

One of the key benefits to service providers of adopting MIFARE4Mobile V2.1.1 is the introduction of a uniform mechanism for the over-the-air installation, personalisation, maintenance and revocation of MIFARE applications using GlobalPlatform messaging.

The following recommendations apply for the over-the-air provisioning and management of MIFARE applications (as described in Figure 5): • It is recommended that the card content management mode is Simple Mode9 and that over-the-air messaging is sent by the MNO TSM (including service life cycle event commands but excluding the personalisation of Service Manager instances and the MIFARE Application, which will be managed by the SP TSM).

• For Service Manager and MIFARE Application personalisation messages, it is recommended to support at least one of the following options:

- The MNO TSM provides a GlobalPlatform “SendScript” API to the SP TSM.

- The SP TSM sends messages using a Remote Application Management over HTTP(S) Proxy Agent (ROH Proxy Agent) on the handset. • It is recommended that the mobile operator is the owner of the MIFARE4Mobile Implementation and the Virtual Card Manager responsible for the management of Virtual Cards. Actors and entities shown in orange in Figure 5 represent mobile operator responsibilities, whereas actors and entities shown in grey represent service provider responsibilities.



Virtual Card 1

MNO TSM

Virtual Card Security Domain

Service Provider 1

ServiceManager 1

SP TSM


SP 1 Security Domain


Figure 5: GSMA recommended card content management approach 10

18

9. By definition, Simple Mode uses the mobile operator’s OTA capability. However, this is not used for in-life messages, e.g. reset PIN, send ticket, etc.

10. Please note that the Utility Security Domain is not shown in the diagram for clarity.

4.6 TSM Architectural Models

There are three architectural models that are recommended for service deployment, all of which are determined by the roles the actors play. For more details on these models, see the GSMA TSM Hub Toolkit document [15].

Note: It is strongly recommended to discuss the choice of architectural model with UICC and TSM vendors at the planning stage.

The three models are: 1. Fully hosted mobile operator model (MNO TSM and SP TSM run by the mobile operator) – The MNO TSM - SP TSM entity is an all-encompassing single entity that manages the relationships with service providers, which have a single relationship with one mobile operator (B2B services such as employees’ access to company buildings). In this model, there is a technical collaboration / partnership between the mobile operator and service provider to deploy a service. All of the service deployment (including Virtual Card, Virtual Card Manager and Service Manager creation) and in-life messaging is performed by the MNO TSM - SP TSM entity run by the mobile operator.

MNO TSM SP TSMMobile Operator A

Service Provider 1

Service Provider 2

Service Provider 3

19

Figure 6: Fully hosted mobile operator model

MNO B TSM instance

MNO C TSM instance

SP TSM

Mobile Operator A

Mobile Operator B

Mobile Operator C

TSM HUB

Service Provider 1

MNO A TSM instance

MNO TSMA

MNO TSMB

SP TSM1

SP TSM2

Mobile Operator A

Mobile Operator B

Service Provider 1

Service Provider 2

2. MNO TSM hub and SP TSM – Mobile operators in a specific local market are partnering to build an MNO TSM hub in order to offer a single entry point to SPs/SP TSMs. In this model, service providers need to set up their own SP TSM and will manage their own Service Manager instances (personalisation and data exchange). The MNO TSM hub will manage the life cycle of Virtual Cards, Virtual Card Managers and the creation of Service Manager instances.

3. Traditional (split) model MNO TSM and SP TSM − This is the default model when no partnership has been set up in a specific market. Recommendations from the MIFARE4Mobile E2E Simplified Framework are still valid, i.e. Virtual Card creation by the mobile operator and service management by the SP TSMs.

Each of these models are market dependent and may not be set up exclusively for the deployment of MIFARE services. It is up to the stakeholders involved in service deployment to

decide on the details of individual implementations. Also note that the recommendations outlined in this document apply to any of the models presented above.

20


Figure 7: MNO TSM hub and SP TSM

Figure 8: Traditional model MNO TSM and SP TSM

4.7 Recommendations for MIFARE4Mobile User Interface

A description of the main principles concerning the MIFARE4Mobile user interface supported within the MIFARE4Mobile V2.1.1 specification was provided in Section 3.3. This section emphasises the key design considerations and recommendations that should be taken into account and understood when developing and deploying a mobile operator wallet application or a service-specific application.

The GSMA recommends the following for general consideration:

• In order to save resources on the UICC and to provide a better user experience to the end user, the user interface (the mobile operator wallet application or the service- specific application) is suggested to be implemented in the handset.• Only the service-specific application shall access the MIFARE Application data within the MIFARE Implementation. In case a mobile operator wallet application would like to display information stored in the MIFARE Implementation, a specific handset API needs to be provided by the service-specific application linked to the SM managing those data.

4.7.1 MDAC Mechanism and Impacts on User Interface Development

When a user interface wants to read data from the MIFARE Implementation, it has to follow a MIFARE Data Access Conditions (MDAC) mechanism that will guarantee that only an authorised user interface will have access to the corresponding blocks / files of the relevant service.

As a consequence of the mandatory MIFARE4Mobile requirement to use MDAC to access service data, a new business process needs to be implemented to share data between the MIFARE4Mobile user interface and the SP TSM.

MDAC check mechanisms differ between MIFARE Classic and MIFARE DESFire; the next sections provide further information on both.

4.7.1.1 MIFARE Classic

The user interface supplier needs to define a Public MDAC Tag Length Value (TLV) item for each sector (i.e. up to 40 TLVs for MIFARE Classic 4K) and send those TLVs to the SP TSM.

The SP TSM computes MACs for Public MDAC TLVs (i.e. for each sector) and personalises the corresponding Service Manager (part of Private metadata).

Once the Service Manager received a READ MIFARE command from the UI through the Wallet API (or Parser interface), it will re-compute the CMAC corresponding to the targeted sector / file, and compare it to the one personalised in the Private metadata. If there is a match, the requested MIFARE data are released.

If both CMACs are equal, then the Service Manager retrieves the MIFARE credentials [8] for the relevant blocks and can use them to access the MIFARE data through the Host Interface.

4.7.1.2 MIFARE DESFire

The MDAC mechanism is a built-in mechanism in a MIFARE DESFire implementation.

In order to be able to read data from the Host Interface, the MIFARE DESFire Host Interface specification [14] mandates the following fields in the Host API:

• File Access Conditions• Password

In a MIFARE4Mobile V2.1.1 implementation:

• File Access Conditions is the Public MDAC data defined in the UI.• The password is a CMAC computed from the Public MDAC data and personalised in the Service Manager.

Note: Unlike MIFARE Classic, in MIFARE DESFire implementations, the check of the MAC is not done in the Service Manager, it is done in the MIFARE Implementation.

4.8 MIFARE Licensing

MIFARE is the most widely accepted technology within the ticketing and access market, and is licensed to vendors by NXP. In addition to the MIFARE licence, the usage of the MIFARE4Mobile framework requires that MIFARE Implementation providers (i.e. UICC providers in the case of UICC-based services) exchange licences and associated strings with the MIFARE Implementation Owner, as described below.

For further information regarding the licensing of MIFARE4Mobile, refer to the MIFARE4Mobile website.

4.8.1 MIFARE UICC Licence Models

We recommend mobile operators contact their UICC vendors to discuss licensing models.

4.8.2 Management of MIFARE Licences in a MIFARE4Mobile Framework

According to the MIFARE4Mobile E2E Simplified Framework, the UICC provider (MIFARE Licensee):

• Holds a licence granted by NXP. • Provides a compliant MIFARE Implementation within the UICC. • Provides a “wholesale Virtual Card creation key” with a Unique Identifer range.

There are no prerequisites (i.e. certification requirements) for receiving a licence.

Note: The mobile operator directly interfaces with the UICC provider to get the “wholesale Virtual Card creation key” and the Unique Identifier range.

The “wholesale Virtual Card creation key” allows the owner to create a Virtual Card in an allocated Virtual Card entry (with any restrictions decided by the UICC provider) according to the provided wholesale licence on the SE.

Each UICC provider may have a different product / commercial solution to deliver the “wholesale Virtual Card creation key” and therefore mobile operators are recommended to contact vendors individually to obtain a solution.

21


4.9 Certification and Security Evaluation

The UICC-based component that implements the MIFARE DESFire protocol requires a security evaluation, and two types of evaluation are possible:

• Using the Common Criteria EAL4+ approach. • Or alternatively, a certification program defined by NXP (similar to the EMVCo security evaluation). For MIFARE Classic, there is no security evaluation requirement.

The M4M Virtual Card Manager and Service Manager do not require any security evaluation since these components do not store any assets covered by the security evaluation.

Regarding certification requirements of the MIFARE4Mobile framework, the MIFARE4Mobile Industry Group proposes two functional certifications leading to two types of MIFARE4Mobile licensed products: • MIFARE4Mobile Secure Element licensed product: It is a solution for a secure element implementing the external interfaces and the full set of functionalities specified in the MIFARE4Mobile specifications, without the need to add any other component on the secure element.• MIFARE4Mobile Platform Licensed Product: It is a card operating system that implements all interfaces and functionalities required to support the execution of a MIFARE4Mobile framework. This option could be valid in case the MIFARE4Mobile 2.1.1 framework is provided by a third party that is different from the UICC vendor.

It is up to mobile operators deploying a MIFARE4Mobile V2.1.1 framework to decide whether they require a MIFARE4Mobile Platform or Secure Element licensed product. At the time of writing, the messaging between the Service Provider, SP TSM, mobile operator and MNO TSM is out of the scope of any certification or evaluation programme.

Note: If a Parser11 resides on a mobile device, it will decode non-sensitive card data to display to the consumer, sensitive MIFARE data (such as keys) should not be displayed on the mobile device. This configuration is out of scope of security evaluation.

A Parser residing in the UICC grants a higher security level because it can store sensitive data. In this case, the Parser shall follow the security requirements of the UICC and any applet residing on the UICC. MIFARE4Mobile does not have any security requirements regarding the Parser or other applets that are not related to MIFARE4Mobile.

The MIFARE4Mobile Industry Group would expect that the MIFARE4Mobile Implementation would be delivered by the secure element vendors (or third parties) which provide the UICCs to mobile operators. The MIFARE4Mobile functional certification process is expected to take two weeks (order intake to certificate issuance). For more information on the certification process, refer to the MIFARE4Mobile website. 4.10 MIFARE4Mobile Life Cycle Process Implications

Life cycle processes are not explicitly handled in the MIFARE4Mobile V2.1.1 specification, they are covered in the MIFARE4Mobile E2E Simplified Framework document.

22


It is up to mobile operators deploying a MIFARE4Mobile V2.1.1 framework to decide whether they require a MIFARE4Mobile Platform or Secure Element licensed product.

11. To access MIFARE data, the Parser shall provide public MDAC as a Parser residing on the mobile phone.


The usability and user experience of a mobile application are key factors in consumer uptake. Sections 3 and 4 showed how a solution’s usability is shaped by the underlying infrastructure’s Quality of Service. This section, on the other hand, focuses on another aspect of the user experience, Quality of Experience. The usability of a mobile application is dependent upon the application’s perceived Quality of Experience and the appropriateness of the application to the user’s situation and context.

MIFARE4Mobile User Experience

5.

Here are some of the main design decisions which could impact the user experience:

1. The application user interface and how it is used – The different applications through which the MIFARE4Mobile service can be accessed, i.e. through a mobile operator wallet application and/or the service- specific application, will have an impact on user experience. Also, whether multiple ticketing and access solutions exist concurrently within the same market, and whether a single card is active or multiple cards can be activated through different interfaces will greatly affect the customer experience.

2. Local market environment – In some markets, the NFC readers will be required to concurrently support multiple contactless technologies, and this could impact the user’s perception of the speed of the ticketing solution. Also, the MIFARE4Mobile service provider will have to ensure that the RF protocol parameters configured in the consumer handset are compatible with the NFC reader infrastructure.

3. Ticketing and access control model applied within the local market and geographical area – Although this subject is considered to be beyond the scope of this document, an appreciation and understanding of how the MIFARE4Mobile application, tickets and credentials will be deployed to the end user is very important. The model applied may affect the approach to how life cycle events are managed. It is also important to note that the MIFARE4Mobile framework is OTA bearer independent but the transmission path may affect Quality of Service and perceived user experience. This section focuses on the “application user interface” aspect (see point 1) of the user experience and aims to provide clarity and recommendations around that.

23

An important element of the customer experience to consider is how the service exists and integrates within existing mobile application solutions, whilst maintaining the usability flow and security. Whether the MIFARE4Mobile service is accessed via a mobile operator wallet application or a service-specific application and how this distinction shapes the application consumer journey are key user experience factors. This constitutes one of the main differences when compared to the physical card user experience.

The recommendation is that the MIFARE4Mobile service is discovered through the mobile operator wallet application, and that service-specific applications make use of the Core Wallet API [2] to retrieve information from the mobile operator wallet application (see Figure 9). The GSMA Core Wallet specification [2] has defined APIs to provide a formal workflow to integrate a service provider application into a mobile operator wallet application. It proposes an interface for service providers to activate their application through the mobile operator wallet (in this scenario, the self-activation privilege is not mandated for the SP application).


ApplicationStore

Contactless Registry Service

Mobile operator wallet application


MIFARE Application

Security DomainSecurity Domain


Virtual Card

Service-specificapplication

GSMA Core Wallet API

ServiceManager


24


Figure 9: Mobile operator wallet application implementation

Whether the MIFARE4Mobile service is accessed via a mobile operator wallet application or a service-specific application and how this distinction shapes the application consumer journey are key user experience factors.

Another important aspect of the user experience is whether multiple ticketing and access technologies exist concurrently within the same market, and whether only a single or multiple cards can be active concurrently. The following scenarios may exist, each of them requiring a different approach to the user experience: • In markets where the MIFARE DESFire technology is used for all services, multiple MIFARE DESFire cards can be active at the same time, guaranteeing an enhanced user experience as consumers are not required to select a card on every occasion. Therefore, on mobile devices using MIFARE DESFire technology, cards do not always need to be selected, as in principle, many MIFARE DESFire cards could be active concurrently within the same device.• In markets where MIFARE Classic is the predominant technology and multiple MIFARE Classic cards could be present, a “select and present” approach is necessary, i.e. users would be required to select a card before using it. • The configuration of NFC card readers may differ from market to market and this can also have an impact on the user experience design decision. Some readers may not be compatible with multiple cards activated on a device, meaning that a “select and present” user experience is necessary.

To ensure a consistent user experience across mobile handsets and contactless applications − independent of the vertical (e.g ticketing, payment) and the technology used − the GSMA recommends a “select and present” approach, i.e. user action is required to select the NFC service that is appropriate in a particular situation.

25

Another important aspect of the user experience is whether multiple ticketing and access technologies exist concurrently within the same market, and whether only a single or multiple cards can be active concurrently.

6.

SummaryThe GSMA and the MIFARE4Mobile Industry Group have co-authored the GSMA MIFARE4Mobile Implementation Guidelines with the assistance of industry experts to provide a companion to the MIFARE4Mobile 2.1.1 − End-to-End Simplified Framework document. The aim was to offer guidance on the issues of interoperability and standardisation between MIFARE transport implementations on NFC-enabled devices.

The release of the GSMA MIFARE4Mobile Implementation Guidelines represents an industry wide collaboration to shift towards a uniform approach to MIFARE deployments on NFC-enabled devices. The MIFARE4Mobile 2.1.1 – End-To-End Simplified Framework specification provides a technical framework and a streamlined approach to service management in “greenfield” scenarios (i.e. where no other MIFARE services exist on UICCs). In markets where a MIFARE service already exists (either through proprietary deployments or earlier versions of MIFARE4Mobile), guidance is needed as to how the service could co-exist whilst maintaining interoperability and a consistent end user experience.

The key areas for a service provider, systems integrator and mobile operator to consider when planning a new MIFARE4Mobile deployment are:

• Understanding local market technical demands and requirements – The ticketing model, other ticketing and access technologies supported within the region should be fully assessed and considered in the MIFARE4Mobile service rollout strategy.

• Providing a consistent user experience and wallet application strategy – When introducing MIFARE4Mobile into a new market, the consumer graphical user interface will have a major impact on the uptake of the service and its integration into existing device applications. MIFARE4Mobile V2.1.1 end consumer interface integration could also affect time to market and testing overheads. Within local markets, the consumer shift towards open market devices should be taken into account when setting consumer experience expectations.

• Understanding MIFARE4Mobile V2.1.1 technical requirements – In order to deploy and support MIFARE4Mobile V2.1.1, a new UICC configuration and a new UICC (including new Java Card Operating System) will be required. Also, mobile operator TSM OTA platforms will be required to support MIFARE4Mobile commands.

Note: The recommendation is for service providers and mobile operators to consult TSM / UICC vendors when assessing technical requirements during the planning of a MIFARE4Mobile V2.1.1 deployment.

Widespread adoption of the MIFARE4Mobile E2E Simplified Framework and the accompanying implementation guidelines provided in this document should significantly improve consumer uptake of MIFARE4Mobile technology as well as ensure greater service scalability.

27

Annex A MIFARE4Mobile V1 and V2.1.1 Co-Existence Solution Description This section provides in-depth technical details on how to manage M4M V1 services on a new UICC within an M4M V2.1.1 framework, i.e. on the co-existence of M4M V2.1.1 and M4M V1 services.

Section 6.4.2 of the MIFARE4Mobile 2.1 Guidance Manual [5] defines a way to address the M4M V1 and V2.1.1 co-existence scenario, it suggests reserving a Virtual Card for M4M V1 services in the lowest VC Entry Number, “VC Entry Number 0” of the MIFARE Implementation.

Thus, a Virtual Card Manager 0 (VCM_0) needs to be instantiated to create this VC and configured in such a way that all sectors of Virtual Card entry 0 will be managed by Service Manager 0 (SM_0). Using this method, the management of those sectors will be reserved by the M4M V2.1.1 framework for SM_0. It is also mandatory to create an SM_0 and to associate it to VCM_0. To activate a Virtual Card, the associated VCM and SM need to be in the VCM_PERSONALIZED and SM_PERSONALIZED states, respectively. The wallet application / UI will be able to activate VCM 0 through the M4M V2.1.1 Wallet API, and it will follow the same rules as a “normal” Virtual Card Manager would in terms of Virtual Card combination or contactless parameters compatibility (through GlobalPlatform Contactless Registry Service rules enforcement).

The outstanding issue is how to fully manage M4M V1 services within the M4M V2.1.1 framework using M4M V1 APIs. The following issues need to be addressed:

• From the TSM(s)’s perspective: Installation and personalisation of M4M V1 applications through the M4M V1 TSM API.

• From a wallet application perspective: Contactless activation of M4M V1 applications. The next sections provide more details on the management of M4M V1 services in a dual framework environment, through both TSM and Wallet APIs.

A.1 Management of M4M V1 Services Through TSM API(s)

A number of M4M V1 specifications have been published in the past, defining proprietary TSM APIs to manage the provisioning and personalisation of M4M V1 services. The objective of this section is not to present those different APIs but rather to describe the global flow to install and personalise M4M V1 services within a dual framework environment.

The following steps are required to prepare the M4M V2.1.1 framework in order to allow installation and personalisation of M4M V1 services, assuming that TSMs did not migrate to the M4M V2.1.1 TSM API. As a prerequisite, M4M V1 Service Manager has been installed and configured.

1. Creation of VCM_0 instance [M4M V2.1.1 TSM API, IN FACTORY].2. Creation of VC_0 [M4M V2.1.1 TSM API, IN FACTORY].3. Creation of SM_0 “dummy” instance [M4M V2.1.1 TSM API, IN FACTORY].4. Association of SM_0 to VCM_0 [M4M V2.1.1 TSM API, IN FACTORY].5. Creation of Service Objects and associated Metadata within the “M4M V1 Service Manager” application [M4M V1 TSM API, OTA].

The next sections describe commands required to configure the card in factory (step 1, 2, 3 and 4), in order to be able to manage the UICC as an M4M V1 UICC in the field.

The assumption is that M4M V1 frameworks support MIFARE Classic cards only; the virtual card creation command parameters below will be set accordingly.

A.1.1 Creation of VCM_0 Instance

As defined in the M4M V2.1.1 Architecture document [6], the creation of the Virtual Card Manager is an instantiation of the MIFARE4Mobile Core Implementation application from the MIFARE4Mobile package.

As a prerequisite to this step, the UICC architecture has been created in factory, allowing the creation of this instance in the right Security Domain. See Section 4.3 for recommendations on UICC configuration. Since the M4M V2.1.1 application is a GP contactless application as defined in Card Technology Contactless Services Card Specification v2.2.1 – Amendment C [3], contactless parameters would need to be defined in the INSTALL [for Install] command. As stated in the M4M V2.1.1 Architecture document [6], the default contactless parameters should be set in the GP Registry once the Virtual Card Manager instance is created. Note: The contactless parameters of the VC will be set during Virtual Card creation. All protocol parameters set during this step will be overridden in the Contactless Registry once the Virtual Card is created. Only the Mandatory Mask set during this step will be kept in the Contactless Registry after Virtual Card creation.

28


Table 3: Default MIFARE4Mobile protocol parameters

Default MIFARE4Mobile Protocol Parameters

Protocol Data

Length UID Value UID SAK ATQAATS Historical bytes length

FWI, SFGI

CID Support

Max data rate

‘00’ ‘00’ ‘0000’ ‘00’ ‘00’ ‘00’ ‘0000’

Mandatory Mask

‘00’ ‘00’ ‘0000’ ‘00’ ‘00’ ‘00’ ‘0000’

It is up to each mobile operator to refer to a specific contactless profile on the UICC, or to explicitly set the contactless parameters in each INSTALL command.

As described in the M4M V2.1.1 Remote Management API [8], all remaining commands are encapsulated in GlobalPlatform STORE DATA commands, using the following format:

84 E2 00 00 XX

Where XX is an Lc and the incoming data of the STORE DATA command. The incoming data are a concatenation of MIFARE4Mobile remote commands.

A.1.2 Creation of VC_0 Virtual Card in MIFARE Implementation

The aim of the CREATE VC command is to create a new Virtual Card in the MIFARE Implementation. This newly created Virtual Card will be dedicated to the hosting of M4M V1 services.

Table 4: TLV of CREATE VC [8]

Tag Length (byte) Value

0x12 Variable See Table 5. For more details on the different fields, see [7].

29

The parameters constituting the value of the TLV field described in Table 4 are described in Table 5:

Note: The newly created VC_0 will be automatically associated to VCM_0.

Table 5: CREATE VC TLV fields [7]

Item Field type Tag Length (byte) Description Recommended value

VCx Entry Fixed length N/A 2Identification of the VC entry where the new VC will be created.

0x0000

MasterUID TLV 0x01 7

The Master UID of the targeted SE (most probably a 7-byte UID).See section 4.3.3.1 for a recommendation on UID assignment.

No

ImplementationType TLV 0x02 2 MIFARE type and size (e.g. MIFARE Classic 1K). 0x0101

VCUIDOption TLV 0x03 1

VC UID settings option. Note: It needs to be fixed since the SE Master UID will be a 7-byte UID.

0x02

newVCUID TLV 0x04 4

4-byte UID of the MIFARE Classic VC.See section 4.3.3.1 for a recommendation on UID assignment.

No

ATQA TLV 0x05 2

Optional – Activation parameters. Required only if default activation parameters configured in the SE for the implementation type shall not be used.

See Table 3 for a recommendation on default activation parameters. SAK: The recommended value is 0x28. UIDHandling: For the recommended value, refer to the MIFARE Virtual Card Creation specification [7].

SAK TLV 0x06 1

UIDHandling TLV 0x07 1

ATS TLV 0x08 1-20

WholesaleLicense TLV 0x10 5+2N

UIDPermission [1 byte]: 0x02 LowestVCx [2 bytes]: 0x0000HighestVCx [2 bytes]: 0x0000ImplementationTypes: 0x0101 (MIFARE Classic 1K only)

0x0200000101

MAC TLV 0x11 8 Truncated MAC as defined in [7]. N/A

EncInitialKeySet TLV 0x20 10 MIFARE Classic Sector Trailer KeyA || AC || KeyB N/A

MACInitialKeySet TLV 0x21 8 Truncated MAC of the EncInitialKeySet. N/A

30


A.1.3 Creation of SM_0 “Dummy” Service Manager

As defined in the M4M V2.1.1 Architecture document [6], the creation of the Service Manager is an instantiation of the MIFARE4Mobile Core Implementation application from the MIFARE4Mobile package.

A.1.4 Association of SM_0 to VCM_0

The aim of the JOIN VC command is to associate SM_0 to VCM_0 and to allocate all associated MIFARE resources (MIFARE Classic 1K sectors in the example below) to the SM. This will prevent other M4M V2.1.1 SMs from accessing resources of VC_0.

Prior to executing the JOIN VC command, the SM application discretionary data should be populated with the VCM_0 AID. The SM will transition to a METADATA_PERSONALIZED state.

The parameters constituting the value of the TLV field in Table 6 are described in Table 7.

A SET STATE (SM_PERSONALIZED) command needs to be sent to the SM_0 in order to set the application to the SM_PERSONALIZED state. It is mandatory for the SM_0 to be in this state to be activated on the contactless interface through the Wallet API.

Table 6: TLV of JOIN VC [8]

Tag Length (byte) Value

0x15 Variable See Table 7. For more details on the different fields, see [7].

Table 7: JOIN VC TLV fields

Item Field type Tag Length (byte) Description Recommended value

Service Manager Application Identifier TLV F6 0x10 Application Identifier of the

M4M V1 Service Manager. No

Sectors list TLV F7 0x01…0x10

List of sectors associated to the SM.In this particular scenario, all sectors of VC_0 will be allocated to the M4M V1 Service Manager, therefore all 16 sectors of the MIFARE Classic 1K card need to be listed.

0x000102030405060708090A0B0C0D0E0F

31

A.1.5 Creation of Service Objects and Associated Metadata Within the “M4M V1 Service Manager” Application

Starting from this step, the UICC can be deployed in the field and managed in the same way as any M4M V1 compliant UICC, using specific M4M V1 TSM API(s).

For details on how to manage Service Objects within the M4M V1 Service Manager, refer to M4M V1 specifications.

A.2 Management of M4M V1 Services Through Wallet API(s)

Similar to M4M V1 TSM APIs, specific Wallet APIs have been defined to manage the activation / deactivation of M4M V1 services. The objective of this section is to define the steps required to activate M4M V1 services in a dual environment (where M4M V1 and M4M V2.1.1 frameworks co-exist).

As a prerequisite, M4M V1 services have been created in the M4M V2.1.1 environment, as described in Section A.1.

The following steps will be required to activate M4M V1 services:

1. Activation of M4M V1 services [M4M V1 Wallet API].2. Activation of VCM_0 instance [M4M V2.1.1 Wallet API]. To deactivate M4M V1 services, the following steps will be required: 1. Deactivation of VCM_0 instance [M4M V2.1.1 Wallet API].2. Deactivation of M4M V1 services [M4M V1 Wallet API]. As an alternative, in case all M4M V1 services can be activated at the same time, it is also possible to leave all M4M V1 services as activated and to only activate / deactivate VCM_0 using the M4M V2.1.1 Wallet API.

A.2.1 Activation of M4M V1 Services

The activation of the M4M V1 service will be done using specific M4M V1 Wallet API(s), and need to be explicitly called by the wallet application. For details on how to manage Service Objects activation through the M4M V1 Service Manager, refer to specific M4M V1 specifications.

A.2.2 Activation of VCM_0 Instance

As defined in the M4M V2.1.1 Architecture document [6], there are two ways to activate a Virtual Card Manager:

• By sending a SET STATUS(VCM0, ACTIVATED) command to the CRS Application (as defined in GP Amendment C [3]) if present on the UICC; or• By sending a SET STATUS(VCM0, ACTIVATED) command directly to the Virtual Card Manager (as defined in the M4M V2.1.1 Wallet API [9]). Conflict detection, for example in case another MIFARE Classic Virtual Card is already activated, will follow the rules defined in the M4M V2.1.1 Architecture document [6]. In case a conflict is raised, it will be up to the wallet application to deactivate the previously activated Virtual Card.

A.2.3 Deactivation of VCM_0 Instance

As defined in the M4M V2.1.1 Architecture document [6], there are two ways to deactivate a Virtual Card Manager:

• By sending a SET STATUS(VCM0, DEACTIVATED) command to the Contactless Registry Service Application (as defined in the GP Amendment C specification [3]) if present on the UICC; or• By sending a SET STATUS(VCM0, DEACTIVATED) command directly to the Virtual Card Manager (as defined in the M4M V2.1.1 Wallet API [9]).

A.2.4 Deactivation of M4M V1 Services

The deactivation of the M4M V1 service will be done using specific M4M V1 Wallet API(s), and need to be explicitly called by the wallet application.

For details on how to manage Service Objects deactivation through the M4M V1 Service Manager, refer to specific M4M V1 specifications.

32


Annex B Management of Routing Table on Multi Card Emulation Environment (CEE) Devices

With the introduction of Host Card Emulation (HCE) into the Android KitKat 4.4 operating system, the possible co-existence of HCE and UICC contactless services is required to be managed by a routing table present in the NFC chipset (or Contactless Front End [CLF]) of each HCE-capable NFC handset.

The role of the CLF routing table is to route contactless transactions between the reader and the CEEs, which are in most cases either the UICC or the HCE. In order to properly configure the routing table, three types of contactless infrastructure need to be understood: • Category 1: Infrastructures compliant with ISO/IEC 14443-4, with explicit ISO SELECT command − this is the case, for example, of EMV readers.• Category 2: Infrastructures compliant with ISO/IEC 14443-4, with implicit ISO SELECT command − this is the case, for example, of some MIFARE DESFire readers.• Category 3: Other infrastructures compliant with ISO/IEC 14443 up to ISO/IEC 14443-3, or proprietary − this is the case, for example, of all MIFARE Classic readers.

As defined in the GSMA TSG Handset specification [13], the routing protocol implemented in the CLF is required to support different types of routing, in the following order:

1. Routing by Application Identifier – Only applies to services of category 1. The CLF shall first check if the selected Application Identifier is present in the routing table, and then route to the configured CEE. If the Application Identifier is not present, the contactless transaction is routed to the default Application Identifier route. 2. Routing by radio frequency protocol – Allows for configuring the CLF with a default route for ISO-DEP contactless transactions. This configuration addresses services of category 2. 3. Routing by radio frequency technology – Allows for configuring the CLF with a default route by radio frequency technology (Type A/B/F). This configuration addresses services of category 3.

Only the Routing by Application Identifier can be dynamically configured by the end user, either by adding / removing services that could potentially impact the routing table, or by changing the default Application Identifier route through a system menu, if such menu is available. The other types of routing are configured in the CLF in-factory and are difficult to change afterwards. Note: The next generation of CLF, following the next release of NFC Forum specifications (not published at the time of the publication of this document), should support the configuration of the radio frequency protocol as well as pattern recognition in the routing table. This would allow a more flexible configuration of MIFARE DESFire services. But for the time being, in order to address the diversity of handset operating system and firmware in the field, configurations that would provide a consistent user experience with any CLF are recommended; these are described in the next sections.

B.1 Configuration for MIFARE Classic Services

As mentioned previously, MIFARE Classic services are services of category 3. Moreover, MIFARE Classic is relying on Type ‘A’ radio frequency technology only.

HCE is unable to manage MIFARE Classic services, therefore it is recommended to route all MIFARE Classic transactions to the UICC.

Such behaviour of the CLF can be achieved

B.2 Configuration for MIFARE DESFire Services

As mentioned previously, MIFARE DESFire services can be services of category 1 or 2, depending on the capability of the infrastructure.

If the targeted infrastructure is category 1, the recommendation is to configure the routing table with the (ISO) Application Identifier of the MIFARE DESFire application to the UICC. Whereas if the targeted infrastructure is category 2, the recommendation is to configure the default route for ISO-DEP protocol to the UICC.

33

Abbreviations

Term Description

AES Advanced Encryption Standard

AID Application Identifier

API Application Programming Interface

ARASM Allocated Resources per Associated Service Manager

CA SD Controlling Authority Security Domain

CCM Card Content Management

CLF Contactless Front End

CMAC Block cipher-based message authentication code algorithm (For details on usage, refer to NIST special publication SP800-38B.)

CREL Contactless Registry Event Listener

CRS Contactless Registry Service

E2E End-to-End

EAL4+ Evaluation Assurance Level 4+

ELF Executable Load File

FnUID Fixed but non-unique ID

GP GlobalPlatform

GUI Graphical User Interface

HCI Host Controller Interface

ISD Issuer Security Domain

M4M MIFARE4Mobile

MDAC MIFARE Data Access Conditions

NFC Near Field Communication

OTA Over The Air

RF Radio Frequency

RM Remote Management

ROH Remote Application Management over HTTP(S)

SCP Secure Channel Protocol

SE Secure Element

SM Service Manager

SP Service Provider

SSD Supplementary Security Domain

SWP Single Wire Protocol

TDES Triple DES (Data Encryption Standard)

TLV Tag Length Value

TSM Trusted Service Manager

TSM OTA Term used to describe a TSM with OTA capability.

UI User Interface

UID Unique Identifier

UV User Verifier

VC Virtual Card

VCM Virtual Card Manager


34

References

Ref Title

[1] GSMA NFC UICC Requirements Specification, Version 5.0, 04 August 2014

[2] GSMA NFC Core Wallet Requirements, Version 2.0, 15 August 2013

[3] GlobalPlatform Card Contactless Services Card Specification v2.2 – Amendment C V1.1

[4] GlobalPlatform Card Technology – Secure Channel Protocol 03 – Card Specification v2.2 – Amendment D V1.1

[5] MIFARE4Mobile – Guidance Manual V 2.1

[6] MIFARE4Mobile – Architecture V 2.1.1

[7] MIFARE Virtual Card Creation V 1.0.2

[8] MIFARE4Mobile – Remote Management API V 2.1.1

[9] MIFARE4Mobile – Wallet API V 2.1.1

[10] GSMA NFC Multi Protocols for Interoperability Version 1.0 October 2012

[11] MIFARE4Mobile 2.1.1 − End-To-End Simplified Framework

[12] GlobalPlatform Card Confidential Card Content Management − Card Specification v2.2 – Amendment A V1.0.1

[13] GSMA NFC Handset Requirements, Version 6.0, 21 July 2014

[14] MIFARE DESFire Host Interface Functional Specification, Version 1.0.0, 4 Jun 2013

[15] GSMA TSM Hub Toolkit: Guide to deploying TSM hubs − From inception to implementation

35

http://www.gsma.com/newsroom/wp-content/uploads/SGP.03_v5.0.pdf

http://www.gsma.com/digitalcommerce/wp-content/uploads/2013/09/NFC.10%20Core%20Waller%20Requirements%20%20v2.0.pdf

http://www.globalplatform.org/specificationscard.asp


http://mifare4mobile.org/downloads/





http://www.gsma.com/digitalcommerce/wp-content/uploads/2012/11/GSMA-NFC-Multi-Protocol-for-Interoperability-V1.0.pdf



http://www.gsma.com/newsroom/wp-content/uploads/TS.26_v6.0.pdf


https://infocentre2.gsma.com/_layouts/InfoCentre/Login.aspx?ReturnUrl=%2fgp%2fpr%2fV2020%2fDCB2B%2f_layouts%2fAuthenticate.aspx%3fSource%3d%2Fgp%2Fpr%2FV2020%2FDCB2B%2FLists%2FNews%2FDispForm%2Easpx%3FID%3D9&Source=%2Fgp%2Fpr%2FV2020%2FDCB2B%2FLists%2FNews%2FDispForm%2Easpx%3FID%3D9

If you would like more information, please contact GSMA via [email protected]

GSMA London Office T +44 (0) 20 7356 0600www.gsma.com/digitalcommerce

Follow the GSMA on Twitter: @GSMA

APRIL 2015© GSMA 2015

About the GSMA

The GSMA represents the interests of mobile operators worldwide, uniting nearly 800 operators with more than 250 companies in the broader mobile ecosystem, including handset and device makers, software companies, equipment providers and Internet companies, as well as organisations in adjacent industry sectors. The GSMA also produces industry-leading events such as Mobile World Congress, Mobile World Congress Shanghai and the Mobile 360 Series conferences.

About the MIFARE4Mobile Industry Group

The MIFARE4Mobile® Industry Group consists of leading players in the Near Field Communication (NFC) ecosystem including Gemalto, Giesecke & Devrient, NXP Semiconductors, Oberthur Technologies and STMicroelectronics. The group acts as a platform to guide the evolution of MIFARE4Mobile technology. The aim of the MIFARE4Mobile Industry Group is to standardize and advance the uniform management of MIFARE applications on NFC-enabled secure elements, such as SIM cards, and mobile phones.

MIFARE4Mobile is a registered trademark of NXP Semiconductors N.V.

mailto:[email protected]

http://www.gsma.com/digitalcommerce

https://twitter.com/gsma

Documents

GSMA MIFARE4Mobile Implementation Guidelines · sector used as a directory for the rest of the card. ... MIFARE4Mobile is a solution first released by NXP ... there is no need to