MIFARE4Mobile_Whitepaper_V1.01 (1).pdf

7/27/2019 MIFARE4Mobile_Whitepaper_V1.01 (1).pdf

1/22

1

2012

MIFARE4Mobile Industry Group

29 Feb 2012

MIFARE4Mobileenabling electronic ticketing and access

management applications on mobile devices


2/22

2

The information provided in this document is believed to be accurate and reliable. However, the

MIFARE4Mobile Industry Group and the authors assume no responsibility for its use, and reserve the

right to revise this document without notice.

All product and service names mentioned in this document are the property of their respective owners.

Copyright 2012 by MIFARE4Mobile Industry Group. All rights reserved.


3/22

3

AbstractContactless ticketing systems based on MIFARE have reached a substantial global coverage over the last

two decades. Main application fields are automated fare collection in public transport as well as secure

access management. However, overall there are more than 40 different contactless applications that this

open technology platform can address. While contactless cards and tokens represent the majority of

todays media in the field, Near Field Communication (NFC) enabled mobile devices are currently

undergoing a fast adoption and are becoming omnipresent. This leads to the conclusion that joining

both technologies creates a huge benefit for the industry and will take the end user experience to the

next level opening new business models for all eco-system players.

The MIFARE4Mobile industry group, consisting of leading technology firms in the contactless market, has

taken the responsibility to standardize the management of MIFARE based applications on NFC enabled

mobile devices. As such the MIFARE4Mobile V2.0 specification is currently developed to make mobile

ticketing in MIFARE DESFire, MIFARE DESFire EV1 and MIFARE Classic based infrastructures possible.

MIFARE4Mobile V2.0 will ensure interoperability amongst different form factors (embedded secureelement, UICC SIM and micro SD) and different vendors.

Two main interfaces are at the core of the service manager as specified by MIFARE4Mobile V2.0:

remote management interface will allow toissue and manage cards and their contents (such as a top up transaction)

the wallet interface will enable the consumer to interact with the cardsIn conjunction with the new concept of multiple virtual cards and compliance to Global Platform,

MIFARE4Mobile V2.0 will bring a maximum of compatibility with existing infrastructure.

Global Platform (especially Amendment C) will enable MIFARE4Mobile V2.0 to co-exist with other

applications such as mobile payment on one and the same mobile device.

Contactless bank cards are another alternative form factor that could help to address the needs of

occasional travelers in public transit systems. They claim to reduce the cost for card issuance as well as

to cut queues in front of ticket vending machines and offices.

MIFARE4Mobile V2.0 as facilitator of MIFARE on mobile devices can cover both aspects and thus provide

the most flexible, scalable and extendable platform for transit agencies to make use of their existing

infrastructure under feasible commercial and technical conditions.


4/22

4

Table of Contents

Abstract ......................................................................................................................................................... 3

1. Introduction ........................................................................................................................................... 5

2. MIFARE4Mobile Industry Group ........................................................................................................... 5

3. Abbreviations ........................................................................................................................................ 5

4. Contactless electronic ticketing systems in use all over the world ....................................................... 6

5. Physical access management - using contactless secure smart cards .................................................. 8

6. Trends from tickets to convergence with banking cards and mobile phones ................................. 10

7. Eco-systems for mobile ticketing and access management ................................................................ 11

8. What is MIFARE4Mobile? .................................................................................................................... 13

9. MIFARE4Mobile V2.0 principle and concepts ..................................................................................... 14

9.1. Todays situation with physical smart cards................................................................................ 14

9.2. Physical smart cards going virtual ............................................................................................... 15

9.3. Remote Management of virtual cards Remote Management API ........................................... 15

9.4. User Interaction Wallet API ...................................................................................................... 17

9.5. MIFARE4Mobile and Global Platform ......................................................................................... 18

9.6. Security ........................................................................................................................................ 19

9.7. Interoperability ............................................................................................................................ 19

9.8. What is planned after the release of MIFARE4Mobile V2.0? ...................................................... 20

10. Summary.......................................................................................................................................... 21

11. About the Authors ........................................................................................................................... 22


5/22

5

1. IntroductionThis white paper is issued by the MIFARE4MobileTM industry group. The document aims to provide an

overview on the history, most recent trends and the future of contactless ticketing in public transport as

well as access management.

The target audience of this document is public transport operators, system integrators (not limited to

but with special focus on transport and access management systems), trusted service managers, mobile

network operators, mobile device OEMs and mobile device OS makers.

Basic background on RFID technology and contactless ticketing systems is of advantage.

2. MIFARE4Mobile Industry GroupThe MIFARE4Mobile industry group consists of leading players in the Near Field Communication (NFC)

ecosystem including Ericsson, Gemalto, Giesecke & Devrient, NXP Semiconductors, Oberthur

Technologies, STMicroelectronics and ViVOtech.

The MIFARE4Mobile industry group serves as forum to anticipate the evolution of MIFARE on mobile and

specifies and implements the according MIFARE4Mobile solutions. The aim of the group is to harmonize

and advance the management of MIFARE based applications built on established and proven global

standards such as Global Platform.

This applies to secure elements in different form factors and different mobile phone models.

3.AbbreviationsAPI Application Programming InterfaceGP Global Platform

GPS Global Positioning System

IC Integrated Circuit

ISO/IEC International Organization for Standardization/International Electrotechnical Commission

NFC Near Field Communication

OTA Over the air

POS Point of sales

RFID Radio Frequency Identification

SD Security Domain

SEI Secure Element IssuerSP Service Provider

TSM Trusted Service Manager

UICC Universal Integrated Circuit Card

UID Unique Identifier

WiFi Wireless Fidelity


6/22

6

4. Contactless electronic ticketing systems in use all over the worldWhen contactless electronic ticketing systems became reality more than two decades ago, they

revolutionized the way people used public transport systems.

Contactless technology made transactions faster and much more reliable and significantly improved the

passengers experience of passing through turnstiles and gates.

On top, contactless systems turned out to be very economic with respect to their maintenance costs.

Figure 1 contactless ticketing with smart cards

The first contactless e-Ticketing systems went live in 1996 in Seoul and 1997 in Hongkong. The ticketing

system in Seoul was based on MIFARE Classic 1K using a 13.56 MHz radio frequency.

Hongkongs solution, better known under the brand Octopus, was based on Sonys FeliCa technology.

The 13.56 MHz technology introduced by MIFARE Classic 1K was later on endorsed by the ISO/IEC 14443

standard which covered two schemes: Type A Type B

The main differences between Type A and Type B are in the coding schemes, modulation methods and

protocol initialization.

Both technologies covered by the ISO/IEC 14443 standard are in use all over the world. In contrary, the

Sony FeliCa technology can mainly be found in the Japanese market with some installations in Asia

Pacific.

For the remaining part of the chapter, special focus is kept on ISO/IEC 14443 based smart cards.

Sonys FeliCa format is out of scope for the presented document as Sonys FeliCa technology does not

relate to MIFARE4Mobile.


7/22

7

Looking on the worldwide markets that use ISO/IEC 14443 based contactless smart cards for automated

fare collection one can see that there are mainly two international categories. One is the open MIFARE

architecture platform which was introduced by the Austrian company Mikron in 1994 which was then

acquired by Philips Semiconductors in 1995. Philips Semiconductors became NXP Semiconductors in

2006.

MIFARE based products offer a complete portfolio of contactless smart card ICs which range from

limited-use smart paper tickets up to high security smart card controllers with third party securitycertification (Common Criteria EAL 4+).

In addition, NXP Semiconductors licensees offer programmable hardware (mainly smart controllers) that

complements the portfolio with MIFARE implementations next to 3rd

party operating systems. Such

solutions can host MIFARE based contactless applications in parallel to other applications such as

payment or e-ID (for details on payment, see chapter Trends from tickets to convergence with

banking cards and mobile phones).

The MIFARE family of products is in use in more than 650 cities in more than 50 different countries as of

today1. The second category of smart cards which is based on ISO/IEC 14443 is the Calypso platform

which is used in 90 different cities in 25 different countries2

Apart from MIFARE and Calypso, there is a variety of national standards which mainly use programmable

microcontroller platforms with customized and optimized implementations from local suppliers. To

mention the most important standards, the VDV core application has been developed in Germany, the

SDOA based OV-Chipkaart has been introduced in the Netherlands and the ITSO standard has been

created for the UK market.

.

The remaining chapters of this document are dedicated to explain how the large number of MIFARE

based cities can be made accessible for mobile ticketing through MIFARE4Mobile. The key idea of mobile

ticketing with MIFARE4Mobile is to provide a globally harmonized and standardized interface that makeslocal transit schemes usable through the MIFARE technology platform itself.

Thus, it is the vision of the MIFARE4Mobile industry group to enable global travelling with local public

transport schemes using NFC enabled mobile devices. In addition, bringing MIFARE to mobile devices

correlates with the ambition of UITP to double public transport ridership until 20253

The main potential for improvement is seen with the group of occasional travelers (as well from abroad)

where an affordable and easy-to-use ticketing medium is needed combining smart routing for door-to-

door journeys with instant ticket purchases.

and as a

consequence, contribute to make cities greener and a better place to live.

The next chapter explains how the benefits of mobile devices in public transport can be expanded to

physical access management.

1Source NXP Semiconductors

2Source www.innovatron.fr

3http://www.uitp.org


8/22

8

5. Physical access management -using contactless secure smart cards

The second main application area of contactless technology is access management, which is the focus of

this chapter.

Physical access management systems usually comprise of identity cards, electronic readers (used to read

the cards) and backend systems with specialized databases, software and computers monitoring and

controlling the traffic at various access points to the system.

Traditionally, controlling and coordinating the rights of individuals within an access management system

was based on identity cards checking a photo or name to prove particular permissions of the card holder

when being inspected by a guard or electronic reader.

Similar to automated fare collection for public transport, physical access to buildings and properties

benefited a lot from the introduction of smart cards and in particular from contactless technology.

Smart cards are much more flexible than physical keys and it is much easier to maintain privileges in a

database rather than physical keys and locks. In addition, smartcards are capable of storing multiple

applications and therefore can serve as one single credential enabling access in a number of unrelated

systems. Multi-application can hence be thought as a virtual key ring moving inside the smart card.

Figure 2 Simplified architecture of a physical access management solution

From a security point of view, smart cards address a changed need for asset protection. The working

circumstances were transformed over the last decade into an environment where a lot of fluctuation

occurs mainly driven by temporary contractors. The utmost goal of enterprises still is to protect their

assets and employees against unpermitted access.

With smart card based access management systems, it is possible to increase flexibility and security at

the same time. The flexibility of a smart card makes it possible to remove privileges easily from the

centralized access management database and making it unnecessary to get hold of the smart card itself.


9/22

9

Further to this, smart cards implement highly sophisticated cryptographic protocols based upon a

tamper resistant hardware. Such tamper resistant hardware utilizes among others sensors, clock filters,

cryptographic memory scrambling as well as active shielding against physical probing, which makes it

practically infeasible to clone credentials.

For contactless technology one has to consider two main technology standards:

ISO/IEC 14443 ISO/IEC 15693

While ISO/IEC 15693 is compelling with read ranges of up to one meter (3 feet), ISO/IEC 14443 is well

known as proximity technology (up to 10 cm) largely used in secure applications such as electronic

passports and secure bank cards.

MIFARE products are based on the ISO/IEC 14443 standard and have been widely adopted in contactless

access management systems. In particular, two out of three ISO14443 contactless smart cards used in

physical access benefit from the MIFARE technology today. The trend is clearly going to products in the

MIFARE family that provide high security and that are security certified by independent third parties

according to the international Common Criteria Standard4

With MIFARE4Mobile two out of three access management systems based on existing ISO/IEC14443

compliant credentials will become accessible through mobile devices and will allow for new, more

convenient applications in physical access management.

.

Using MIFARE4Mobile, it gets possible to securely transfer hotel room keys into an NFC enabled phone in

advance to a trip. Especially frequent travelers could enjoy a streamlined trip allowing them to directly

proceed to their hotel room instead of queuing up at the reception desk.

For another example, premium programs at rental car companies already allow today customers to walk

up directly to their car which is unlocked with the car key inside the parking space. However, there is still

a need for control by a guard at the exit barrier of the parking lot for preventing unauthorized usage or

that somebody took the wrong car.

If customers were provided with their personal access permission at booking time similar to the hotel

room case, cars could stay locked in the parking lot and unauthorized use as well as taking the wrong car

could be avoided straight from the beginning.

As MIFARE products are already used for car sharing, MIFARE4Mobile can bring even more comfort in

the future. Mobile devices allow searching for the closest located and available car within the attended

car sharing program. After a permission check of the identity in the car sharing database the (timely

bound) key could then be transferred over the MIFARE4Mobile application to the mobile device.

4http://www.commoncriteriaportal.org/
http://www.commoncriteriaportal.org/http://www.commoncriteriaportal.org/http://www.commoncriteriaportal.org/http://www.commoncriteriaportal.org/


10/22

10

Figure 3 key transfer into MIFARE4Mobile application using TSM interface

6. Trends from tickets to convergence with banking cards and mobilephones

Since the introduction of contactless technology for credit cards in mid 2005, the number of merchants

accepting contactless payments has increased continuously. According to Smart Card Associations the

leading payment brands including American ExpressTM, DiscoverTM, MasterCardTM and VisaTM have been

issuing hundreds of millions of contactless enabled payment cards to date.

Contactless payments make the payment process much quicker compared to the traditional swiping of

magnetic stripe based cards. New business rules and spending limits allow for a payment transaction

with a quick tap without having to sign.

Figure 4 Payment with contactless Bankcard

As the process of payment has become quicker by introducing contactless technology the leading

payment brands have been looking into acquiring transport agencies as merchants. Cutting queues at

ticket counters, providing an easy means of payment for occasional travelers (like tourists) and reducing

the card issuance costs for agencies are amongst the most frequently mentioned arguments for

introducing payment cards.


11/22

11

Convergence is currently seen to take up in two different ways:

Reader at the turnstile accepting tickets and payment at the gate with cards issued by a bank Smart Card media supporting technology for conventional ticketing next to payment capabilities

As such it is possible to accept riders with electronic tickets and payment cards within the same

transport system. Additionally, it enables the individual to use the electronic ticket in his home region for

commuting whereas the payment at the gate option could potentially ease travelling abroad.

However, when ticketing comes to mobile devices by industry initiatives such as the MIFARE4Mobile

initiative, the main advantage of payment applies to electronic ticket systems as well.

In addition to journey planning, tickets can be purchased anywhere at any time and card issuance costs

do not apply. As such, MIFARE4Mobile brings several benefits to transport agencies having the full

freedom of choice which route to go with respect to their own local business model and needs.

7. Eco-systems for mobile ticketing and access managementThere are a number of key elements to be considered when launching NFC mobile ticketing. The

introduction of mobile phones as new ticketing media in the transport scheme brings significant changes

on both the business side as well as on technical side.

The secure element being used in the mobile phone is having a major impact on the business model for

transport companies. Today, most of transport companies are issuing their own contactless cards. With

upcoming NFC enabled phones, they can have their ticketing applications hosted among other

applications in the secure element of the NFC phone.

This secure element can be

an embedded secure element

an UICC-SIM or a secure microSD card

In all cases, transport companies have to come up to a commercial agreement with the secure element

issuer or a TSM (Trusted Service Manager) acting on behalf of the secure element issuer.

On the technical side, they need capabilities for remotely installing and managing their ticketing

application. The roles of installing and managing are usually split between the Secure Element issuer and

the Service Provider and could be handed over to a TSM. The Secure Element Issuer (TSM) is in charge of

controlling and authorizing access to the secure element (SE). It also sets up the environment in the SElike for example creating a security domain for a service provider (TSM). The Service Provider (TSM) is in

charge of managing NFC applications. Once it has been given a security domain, it installs (*) and

personalizes its applications over-the-air. It is also in charge of managing the post-issuance life cycle of its

application, such that it can, for example, lock an application when a phone is declared lost or stolen.

(*) the roles of a SEI TSM and a SP TSM vary depending on the selected GP deployment model (delegated, simple or dual)


12/22

12

Additionally, they need to provide end users with a user interface on the phone allowing passengers to

check their balance or purchase tickets and products. Given the variety of NFC enabled mobile phones to

be introduced on the market, they will need to have their ticketing application to comply with main

phone operating systems. This application is obviously used for managing cards and tickets but can also

be used by transport companies to offer added-value services such as checking when the next bus

arrives, checking the metro map or provide updates on traffic.

This transport application can be aggregated in the so-called mobile wallet usually provided by mobile

network operators and other secure element issuers such as GoogleTM

. This mobile wallet can be seen as

container of virtual cards where many applications can be aggregated offering convenience to end users

when they have multiple virtual cards on their phones.

When it comes to ticket purchase, different scenarios can be considered. End users can purchase tickets

straight from their transport application or from the internet. One of the most convenient ways to top-

up a ticketing application is when the end user can simply do it straight from the phone application with

the fare being charged directly to the phone bill or from an on-line payment system where payment is

confirmed by inserting a PIN or password. This can be seen as an evolution of the already existing SMS

ticket systems currently in use some countries in Europe such as Sweden and Finland.

This requires a connection between the phone application and the ticket reload server either directly (on

an IP connection) or via an SMS.

Beyond the transport operator, there are many players that may be involved in this ecosystem:

1 SP TSM OTA application management by transport operator or by an entity on behalf of the

transport operator e.g. system integrator

2 Secure Element issuer (SEI) provides a secure framework for the transport operator to load its

ticketing application through its SEI TSM and the secure element itself.

3 - SEI TSM either covered by SEI itself or a separate entity operating on behalf of the SEI. OTA Secure

Element management like providing SP TSM access to the Secure Element

4 Application provider provides the phone application for managing tickets and cards as well as

additional value-added services.

5 Transport system integrators provide the integration layer with the transport company back-end

system (i.e. ticket reload server) as well as end-to-end validation including testing with the installed-

base contactless infrastructure


13/22

13

Figure 5 players in the mobile eco-system

8. What is MIFARE4Mobile?The MIFARE4Mobile industry group was created in 2010 in order to standardize how MIFARE technology

(MIFARE Classic, MIFARE DESFire and MIFARE Plus) is used in a secure element with special focus on the

implementation in mobile devices. To be even more precise, the target was to integrate the MIFARE

technology into the Global Platform architecture, which would give the user of the technology many

benefits for free.

The basic problem with early implementations of MIFARE (referred to MIFARE Classic) in mobile devices,

has been that there was no process to create new instances of MIFARE cards and that there has been no

equivalence to the security domain used in Global Platform to separate the interests of the SecureElement Issuer (SEI) and the Application Provider (AP).

These two limitations of these early implementations made it difficult to take the step from pilots and

trials (where everything is pre-defined regarding the number of MIFARE cards and the relationship

between SEIs and APs) to real rollouts where flexibility is needed as relationships change.

In order to go from pilots to real world use cases, MIFARE4Mobile is hence needed.

In addition to the reasons mentioned above, certain interfaces (such as the JavaCard API towards the

MIFARE technology platform) were not harmonized at that time, which made the creation of truly multi-

supplier ecosystems for a SEI difficult when looking at acquiring a Secure Element.


14/22

14

9. MIFARE4Mobile V2.0 principle and conceptsMIFARE4Mobile V2.0 is a specification which is currently under development by the MIFARE4Mobile

industry group and defines interfaces for an application which is called service manager. One or more

service managers are placed in the secure element (embedded, UICC SIM or microSD) and provide a

standardized communication interface towards the mobile wallet and the remote management API.

Standardization of these communication interfaces will allow interoperability and re-usability between

different service providers, mobile devices makes, and secure element vendors and form factors.

Figure 6 TSM and wallet interface of MIFAR4Mobile service manager

9.1. Todays situation with physical smart cardsEvery installation using smart cards has an owner deciding which services will be allowed for installation

on this smart card. For public transport, this owner of the smart card could be a transport operator, an

authority representing more than one transport operator or a system integrator acting on behalf of

those entities. The installation of new applications usually requires the knowledge of a card master keyand thus, is reserved to the owner of the smart card.

It is quite natural that the owner manages the access to the smart card as he usually has to cover the

issuing costs and architects the structure of applications on the medium as well as planning the usage of

available memory.

In almost all cases adding a new third party service to an existing and already issued smart card will not

happen before a business relation or all necessary legal and contractual issues have been settled. Once

completed, the third party service can be installed on the smart card with the permission of the owner.

The third party might get permission rights which allow managing its own application.

The lack of memory on the device as well as missing business relationships are usually among the most

frequently mentioned constraints that lead to the fact that people still carry a variety of cards in their

wallet instead of using one single card for all applications.

Although the eco-system and its relationships within might change over time under the influence of

mobile, having various smart cards might still be the most common case at the beginning.


15/22

15

9.2. Physical smart cards going virtualThe drivers mentioned in the previous chapter help identifying the key elements which are required for

ticketing and access management on NFC enabled devices to allow an easy start in existing eco-systems.

Key requirements that must be considered are:

Functional behavior must be identical to the normally used smart card Performance must be as close as possible to the normally used smart card One to one reuse of memory, application and data structure layout from existing smart cards Ownership of the card media must not change

All the above requirements result in the conclusion that MIFARE4Mobile V2.0 will offer the possibility to

have multiple virtual cards on a secure element. For NFC enabled transactions, virtual cards can be used

like their existing physical counterparts whereas the handling of virtual cards in the mobile wallet will be

much more convenient and flexible.

In most cases, the consumer will only have preselected a MIFARE technology based virtual card to use in

a contactless transaction, following todays behavior of picking one physical card from the wallet.

Nevertheless, MIFARE4Mobile V2.0 technically allows activating more than one MIFARE technology

based virtual card at a time and in addition, supports concurrent co-existence of MIFARE technology

based virtual cards next to other applications such as mobile payment or eID.

The concept of virtual cards as defined by MIFARE4Mobile V2.0 allows:

Multiple cards as if they were a stack of plastic cards Contactless reader devices do not need to support anti-collision as defined by ISO/IEC 14443 Virtual cards can share one UID (recommended),can have their own, or sets of virtual cards can

share common UIDs

Virtual cards with the same UID and non-conflicting ISO/IEC 14443 activation parameters can beactivated concurrently (multiple MIFARE DESFire cards paired with e.g. one MIFARE Classic card)

Provisioning of a virtual card will always be done by the secure element owner (or a SEI TSMacting on behalf of the SEI)

MIFARE4Mobile V2.0 allows multiple Service Providers (or TSMs acting on behalf of them), eachhaving one or more virtual cards

A virtual card can be exclusively managed by a service provider, or a TSM operating on behalf ofone or more service providers. When managed by a TSM, multiple service providers can share

the same virtual card

9.3. Remote Management of virtual cards Remote Management APIThe previous chapter explained the need and concept of virtual cards as defined by MIFARE4Mobile

V2.0. This chapter puts the focus on remote management of virtual cards.

Management of virtual cards is done through the MIFARE4Mobile V2.0 Remote Management API.


16/22

16

Virtual cards follow a lifecycle model similar to their physical counterparts.

The main life cycle stages are:

Creation of a Virtual Cardo During productiono In the field

Deletion of a Virtual CardUsually, creation of a virtual card will be triggered by a handset user action such as buying a ticket from

the web or an online store. At the very initial stage of the purchasing process the ticket provider will

need to verify that an adequate media for hosting this service is available.

If such an adequate media does not exist, a new virtual card and its corresponding service manager must

be created. This will require the involvement of the secure element owner or a third party managing on

behalf of the owner (SEI TSM).

The full system of involved parties and roles is described by Figure 7 Roles and parties involved for

creation of a virtual card.

The following questions need to be answered between the Secure Element Issuer and the requestor ofthe virtual card:

Secure Element Issuero Requested MIFARE technology supported on this secure element?o Enough memory available?o Business relationship with requestor existing (charging for rented space)?o Requested virtual card parameters for creation correct?

Virtual card requestoro does the secure element meet the requirements for

Performance?

Functionality? Security?

o Business relationship existing?o Provide parameters of requested virtual card?

If all questions have been clarified the SEI or the SEI TSM will create an uninitialized MIFARE technology

based virtual card and the corresponding service manager (could be in a separate security domain) with

pre-personalized transport keys. These transport keys are securely transferred to the requestor of the

MIFARE technology based virtual card. Later on the requestor can take over the exclusive management

of the newly created virtual card by changing the transport keys.

The command Create Virtual Card is protected by a message authentication code (MAC) which requires

the knowledge of a key. Among other parameters the Create Virtual card command will allow thechoices as listed below:

UID optiono Inherit UID from secure elemento Request a new UID (involvement of technology provider)o Assign a 4 Byte FNUID for MIFARE Classic only (involvement of technology provider)


17/22

17

Kind of MIFARE Product (MIFARE Classic, MIFARE DESFire, MIFARE DESFire EV1, and laterMIFARE Plus)

Product memory size (1K, 2K, 4K, 8K)Deletion of a virtual card can be either initiated by the handset user (who does not use a product any

longer), by the service provider (if the product has expired) or by the secure element owner or the third

party managing it on behalf of the owner (e.g. service provider got bankrupt).

Figure 7 Roles and parties involved for creation of a virtual card

9.4. User Interaction Wallet APIThe wallet API of MIFARE4Mobile V2.0 defines the parts which are required for the interaction between

a mobile wallet and MIFARE technology based virtual cards.

Most importantly, the wallet API allows to organize and manage the concurrent usability of applications

on the ISO/IEC 14443 contactless interface (refer as well to chapter MIFARE4Mobile and Global

Platform).

Hence, any MIFARE technology based virtual card can be present next to a mobile payment application

or any other applications at the same time.

The business logic of any contactless enabled tapping point (POS, ticket vending machine etc.) will

automatically select the most suitable application among all offered applications provided by an NFC

enabled mobile device.

Even more important, the wallet API allows controlling the visibility of applications at the ISO/IEC14443

contactless interface. Hence, the end user of the mobile device keeps full control on applications that

can be selected for performing a transaction.


18/22

18

In addition, the end user could decide to enable location based activation (e.g. GPS) for any pre-defined

set of virtual cards. End users of MIFARE4Mobile V2.0 enabled handsets will experience new levels of

comfort, as the user defined set of virtual cards, suitable for the current location or region, will be

automatically activated without conscious interaction.

Figure 5 sketches the mobile wallet and the variety of possibilities to switch between the virtual cards or

sets of virtual cards based on the MIFARE technology platform.

Figure 8 Example of a mobile wallet and mechanisms for card activation

The MIFARE4Mobile V2.0 wallet specification covers the elements as listed below:

Provide display related information (e.g. logo, URL, Application family, etc) Provide displayable MIFARE technology platform data (e.g. balance, etc) Activation of a MIFARE service or a group of services Management of conflicts among all applications on the secure element (MIFARE and non

MIFARE technology platform based applications)

o ISO/IEC 14443 activation parameterso Application rules, e.g. legacy infrastructure only allowing one MIFARE applicationo Business rules limitation

9.5. MIFARE4Mobile and Global PlatformGlobal Platform defines proven mechanisms to handle multiple contactless applications and how to

organize them. In order to ease the local management of MIFARE technology platform based

applications, MIFARE4Mobile V2.0 relies on the Global Platform GP2.2 standard.

Compliance with the Global Platform GP2.2 standard allows:

Confidential card content management - allow an application provider to confidentially load,install and personalize an application. Any involved third party shall not be able to access any

clear text or confidential information belonging to the application provider (GP amendment A)


19/22

19

Lifecycle management and personalization of MIFARE4Mobile applications (GP 2.2 ) Remote application management in a standardized way - this allows the deployment of

MIFARE4Mobile on different secure element form factor (embedded, UICC and microSD )

co-existence with other contactless applications - protocol parameter conflict detection andprotocol parameter resolution (GP 2.2 amendment C)

o Standard user interaction managemento Provide display control information, application family etc.o Activation of MIFARE technology platform based application

9.6. SecurityOver the last years security of smart cards has become a major concern and therefore standards were

established to ensure highest levels of security design with standardized and independent evaluation

methods.

To ensure that any licensed implementation of MIFARE across all secure elements meets the same

security level as the existing smart card products, an independent Common Criteria Certification applies.

Since highly sensitive assets are usually protected by a direct and secured communication channel

between the MIFARE technology implementation and the application provider, it has been decided to

exclude the MIFARAE4Mobile V2.0 service manager from security certification.

This approach ensures to keep the best balance between required security of the MIFARE technology

platform implementation and related product development costs and design complexity of the

MIFARE4Mobile implementation.

Hence, sensitive keys which are required to e.g. increase the balance of a card are considered to remain

in the secure backend environment rather than being injected into the MIFAR4Mobile V2.0 service

manager.

This mainly reflects todays situation where systems are using end to end security protocols for sensitive

transactions with physical smart cards.

Less sensitive keys e.g. keys that only allow reading of certain information, however, can still be placed in

the MIFARE4Mobile V2.0 service manager and enable to read information from the wallet API such as

checking a cards balance.

9.7. InteroperabilityInteroperability of MIFARE4Mobile backend and secure element solutions from different vendors will be

a key success factor for a successful worldwide rollout.


20/22

20

Thinking back a couple of years to the time when electronic passports were launched and having in mind

their initial interoperability problems, it becomes obvious that testing for interoperability needs to be

established as soon as possible.

The MIFARE4Mobile industry group drives for highest levels of interoperability by following items:

Test specifications for MIFARE4Mobile V2.0.

Guidance manual for implementation and usageby secure element issuers, application providers and wallet developers.

Establishment of independent test houses for certifyingMIFARE4Mobile V2.0 implementation compliance

9.8. What is planned after the release of MIFARE4Mobile V2.0?There are a couple of topics on the MIFARE4Mobile roadmap which will be pursued right after the

release of MIFARE4Mobile V2.0. In particular they are:

Definition of a Java Card API will streamline the post issuance of MIFARE4Mobile service manager

solutions across all platforms.

Definition of a Java Card API will streamline the post issuance of MIFARE4Mobile servicemanager solutions across all platforms

Inclusion of MIFARE Plus increasing MIFARE4Mobilecoverage concerning the MIFARE product portfolio.

Introduction of virtual card selection providing contactless readers with a quick andprivacy friendly way to automatically select a virtual card without user interaction.

Definition of Web Services API that facilitates the interaction between the multiple actors in theecosystem


21/22

21

10. SummaryIt is out of question, contactless smart cards have changed our lives by introducing more convenience

and security over the last decades. While contactless smart cards increased convenience in public

transport by enabling faster dwell times, they increased the flexibility and security of access

management systems. In this two contactless application fields, the open MIFARE architecture platform

was most widely selected and adopted over the last two decades.

With the increase of NFC enabled handsets in the hands of end users, the demand of making MIFARE

available on mobile devices has increased day by day. Main drivers are the fast growth rate of NFC

enabled handsets and the broad existing infrastructure based on the MIFARE technology.

The MIFARE4Mobile industry group, consisting of leading technology firms in the contactless domain,

has set the goal to standardize the management of MIFARE based applications on NFC enabled mobile

devices. This harmonization targets to create a true multi-vendor and multi-product ecosystem.

The most recent development of MIFARE4Mobile V2.0 supports the management of MIFARE

applications (MIFARE Classic, MIFARE DESFire and MIFARE DESFire EV1) through its wallet and TSM APIs.

Further to this, MIFARE4Mobile V2.0 introduces the support for multiple virtual cards and multiple TSMs

allowing a plurality of service providers to acquire one or more virtual cards.

While virtual cards ensure a maximum compliance with existing infrastructure, MIFARE4Mobile V2.0

leverages from Global Platform 2.2 and its amendments A (confidential content management) and C

(contactless services) making it an easy fit for mobile devices.


22/22

22

11. About the AuthorsDominique Brule - Dominiques current employment is with Gemalto in the role of a head of marketing formobile NFC and TSM. Dominique has several years of experience in semiconductors and mobile software

marketing and focused in the last years especially on TSM, NFC enabled services including MIFARE4Mobile. He

is also co-chairman of the MIFARE4Mobile Industry Group.

Mattias Eld -is the product manager for the Ericsson Trusted Service Manager service. Prior to this, he

worked at Ericsson Research with standardization and business development focusing on M2M and NFC

technologies. Mattias brings several years of experience in mobile industry with him and is the current co-chair

of MIFARE4Mobile.

Jerome Juvin - is currently employed with STMicroelectronics in the role of a marketing manager for securemobile and NFC. Jerome has over 10 years of experience in the semiconductors industry with positions in

engineering, business development and marketing.

Christian Lackner - is working with NXP Semiconductors in the role of a product manager. He has

gained technical knowledge and insights into the semiconductors business over the last 10 years

with positions in R&D management and product management.

MIFARE4Mobile_Whitepaper_V1.01 (1).pdf

Documents

Transcript of MIFARE4Mobile_Whitepaper_V1.01 (1).pdf