enabling electronic ticketing and access management applications on mobile devices

MIFARE4Mobile

2012

MIFARE4Mobile Industry Group 1 29 Feb 2012

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.

Abstract
Contactless 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 secure element, 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 to issue and manage cards and their contents (such as a top up transaction) the wallet interface will enable the consumer to interact with the cards

In 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.

Table of Contents

Abstract ......................................................................................................................................................... 3 1. 2. 3. 4. 5. 6. 7. 8. 9. Introduction........................................................................................................................................... 5 MIFARE4Mobile Industry Group ........................................................................................................... 5 Abbreviations ........................................................................................................................................ 5 Contactless electronic ticketing systems in use all over the world ....................................................... 6 Physical access management - using contactless secure smart cards .................................................. 8 Trends from tickets to convergence with banking cards and mobile phones ................................. 10 Eco-systems for mobile ticketing and access management ................................................................ 11 What is MIFARE4Mobile? .................................................................................................................... 13 MIFARE4Mobile V2.0 principle and concepts ..................................................................................... 14 9.1. 9.2. 9.3. 9.4. 9.5. 9.6. 9.7. 9.8. 10. 11. Todays situation with physical smart cards................................................................................ 14 Physical smart cards going virtual ............................................................................................... 15 Remote Management of virtual cards Remote Management API ........................................... 15 User Interaction Wallet API ...................................................................................................... 17 MIFARE4Mobile and Global Platform ......................................................................................... 18 Security ........................................................................................................................................ 19 Interoperability............................................................................................................................ 19 What is planned after the release of MIFARE4Mobile V2.0?...................................................... 20 Summary.......................................................................................................................................... 21 About the Authors ........................................................................................................................... 22

1. Introduction
This 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 Group

The 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. Abbreviations
API GP GPS IC ISO/IEC NFC OTA POS RFID SD SEI SP TSM UICC UID WiFi Application Programming Interface Global Platform Global Positioning System Integrated Circuit International Organization for Standardization/International Electrotechnical Commission Near Field Communication Over the air Point of sales Radio Frequency Identification Security Domain Secure Element Issuer Service Provider Trusted Service Manager Universal Integrated Circuit Card Unique Identifier Wireless Fidelity 5

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

When 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.

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 security certification (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 today 1. 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 countries 2. 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 makes local 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 2025 3 and as a consequence, contribute to make cities greener and a better place to live. 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-todoor journeys with instant ticket purchases. The next chapter explains how the benefits of mobile devices in public transport can be expanded to physical access management.
1 2

Source NXP Semiconductors Source www.innovatron.fr 3 http://www.uitp.org

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. 8

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 Standard 4. 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.

http://www.commoncriteriaportal.org/

Figure 3 key transfer into MIFARE4Mobile application using TSM interface

6. Trends from tickets to convergence with banking cards and mobile phones
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.

10

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 management

There 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 SE like 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)

11

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 topup 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 installedbase contactless infrastructure

12

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 Secure Element 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 multisupplier ecosystems for a SEI difficult when looking at acquiring a Secure Element.

13

9. MIFARE4Mobile V2.0 principle and concepts

MIFARE4Mobile 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 cards

Every 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 key and 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. 14

9.2.

Physical smart cards going virtual

The 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 be activated 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 TSM acting on behalf of the SEI) MIFARE4Mobile V2.0 allows multiple Service Providers (or TSMs acting on behalf of them), each having one or more virtual cards A virtual card can be exclusively managed by a service provider, or a TSM operating on behalf of one 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 API

The 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. 15

Virtual cards follow a lifecycle model similar to their physical counterparts. The main life cycle stages are: Creation of a Virtual Card o During production o In the field Deletion of a Virtual Card Usually, 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 of the virtual card: Secure Element Issuer o 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 requestor o 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 the choices as listed below: UID option o Inherit UID from secure element o Request a new UID (involvement of technology provider) o Assign a 4 Byte FNUID for MIFARE Classic only (involvement of technology provider) 16

Kind of MIFARE Product (MIFARE Classic, MIFARE DESFire, MIFARE DESFire EV1, and later MIFARE 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 API

The 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.

17

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 parameters o Application rules, e.g. legacy infrastructure only allowing one MIFARE application o Business rules limitation

9.5.

MIFARE4Mobile and Global Platform

Global 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) 18

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 and protocol parameter resolution (GP 2.2 amendment C) o Standard user interaction management o Provide display control information, application family etc. o Activation of MIFARE technology platform based application

9.6.

Security

Over 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.

Interoperability

Interoperability of MIFARE4Mobile backend and secure element solutions from different vendors will be a key success factor for a successful worldwide rollout.

19

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 usage by secure element issuers, application providers and wallet developers. Establishment of independent test houses for certifying MIFARE4Mobile 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 service manager solutions across all platforms Inclusion of MIFARE Plus increasing MIFARE4Mobile coverage concerning the MIFARE product portfolio. Introduction of virtual card selection providing contactless readers with a quick and privacy 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 the ecosystem

20

10.

Summary

It 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.

21

11.

About the Authors

Dominique Brule - Dominiques current employment is with Gemalto in the role of a head of marketing for mobile 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 secure
mobile 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.

22