WO2013098117A1

WO2013098117A1 - A method to manage contactless communication in a user device

Info

Publication number: WO2013098117A1
Application number: PCT/EP2012/075897
Authority: WO
Inventors: Fernando Rodriguez Sela; Jesús ROSA; Ignacio Barandalla Torregrosa
Original assignee: Telefonica, S.A.
Priority date: 2011-12-27
Filing date: 2012-12-18
Publication date: 2013-07-04
Also published as: ES2409807A2; ES2409807B1; ES2409807R1

Abstract

In the method of the invention said contactless communication is performed by an applet of a service provider, said applet is installed in a user device and said applet accesses to a memory of said user device in order to perform said contactless communication. It is characterised in that it comprises: giving access to a plurality of applets of said user device to said memory by means of a service manager entity, said plurality of applets being installed in said user device; and storing information of services providers of said plurality of applets in an isolated way using Universal Integrated Circuit Card security of said user device, each of said a plurality of applets having a different security domain wherein said information is stored.

Description

A method to manage contactless communication in a user device

Field of the art

The present invention generally relates to a method to manage contactless communication in a user device, said contactless communication performed by an applet of a service provider, said applet installed in a user device and said applet accessing to a memory of said user device in order to perform said contactless communication, and more particularly to a method that comprises giving access to a plurality of applets of said user device to said memory by means of a service manager entity, said plurality of applets being installed in said user device and storing information of services providers of said plurality of applets in an isolated way using Universal Integrated Circuit Card security of said user device, each of said a plurality of applets having a different security domain wherein said information is stored.

Prior State of the Art

Calypso is a smartcard contactless proprietary technology widely used in transports on some countries.

MiFare is a widely deployed and most extended proprietary technology (owned by NXP, previously Philips) for contactless communications. Its lower layers are based on ISO 14443 [2] but has proprietary memory organization and commands, as well as security authentication and encryption.

Given the fact that most contactless systems that exist today are based on this technology its emulation within the SIM+mobile handset environment became a strong requirement for wide adoption.

MiFare Protocol is a proprietary protocol that uses (in some modes) hardware based stream-cipher for very fast processing. Due to the overall encryption of the full communication and the strong timing requirements, the MiFare messages have to be tunneled through the Contactless Frontend (CLF) using the Contactless Transmission Mode (CLT-Mode) on the Link-Layer specified in [3].

In order to be able to work in these systems the CLF needs to work on CLT mode and the Universal Integrated Circuit Card (UICC) will have to emulate a MiFare memory. There are different cases of MiFare: - MiFare Classic: it is a memory card with some access security. This memory must be implemented in the card. An external reader will then be able to access it through the CLF and CLT as if it were any other MiFare card.

- The UICC must also implement a way for applications stored in the card to use and manage this memory (SmartCard Web Server User Interface, or any other application that makes use of the data in the MiFare memory). A known Application Programming Interface (API) must be used for this matter. The UICC will present a central entity to manage the MiFare memory specially in avoiding collisions in the use of MiFare sectors and their access keys.

- MiFare DESFire: is similar to the existing smartcard structures. It also supports most commands according to ISO 7816 [4]. The card must implement an emulation of this system.

MiFare4Mobile (or M4M) is a technology that provides an end to end solution for delivering MiFare applications to the Near Field Communication (NFC) mobile phone including management of application lifecycle, content modification and display of information in the Service User Interface (Ul).

Nowadays, the only M4M implementation has been made by Gemalto.

NXP described an API for the communication with the Ul as well as with the Over-The-Air (OTA) platform, as it will be shown in Figure 1.

The main components of the structure presented are:

- MiFare4Mobile Service Manager, managing MiFare applications and related data. It acts as a sort of JavaCard/GP (GlobalPlatform) card manager for MiFare applications.

- User Interface or "Wallet", as the graphical user interface for the Service Manager

- Proxy application, establishing the connection between backend system and the M4M Service manager. It will relay the relevant M4M commands from the back-end platform to the Service Manager.

It must be noted that the specification does not cover the implementation of these elements but only the interface between them (the APIs mentioned before: Remote management MiFare API and Ul MiFare API). This leaves the implementation open and undefined including the way in which the SP must work to provide an applications etc.

This API specification is divided into two: - Trusted Service Manager (TSM) API, which includes all the commands to install applications. The format of the commands is similar to those of GP's specification but is actually outside GP and does not include Security Domains (SD). The commands are: INSTALL, ACTIVATE, DELETE, GETDATA and STORE DATA (for application management), INITIALIZE UPDATE and EXTERNAL AUTHENTICATE (for SCP02 security channels) and PUTKEY and PUTMIFAREKEYS (for MiFare security management).

- Wallet API, including commands to get MiFare information from the Wallet: ACTIVATE, RETRIEVE DATA and VERIFY PIN and CHANGE PIN.

However both M4M specification and Gemalto's implementation of the Service

Manager poses the threat of giving too much power to one TSM, as Gemalto proposes a closed structure in which it is only through Gemalto^'s platform that we can access MiFare applications. They will control what is installed, and will control the security keys. Moreover M4M does not support MiFare DESFire.

The existing solutions don't cover some important topics:

Privacy and security

- All Service Provider (SP) information passes through the Service Manager

- All SP configuration information is into the same security domain

No MultiTSM support

- Only 1 TSM is supported

- All SP shall use the same TSM

Description of the Invention

It is necessary to offer an alternative to the state of the art which covers the gaps found therein, particularly related to the lack of proposals which really provide a multi Security Domain environment in which it is possible to provide independence to the service providers and to the Mobile Network Operator themselves.

To that end, the present invention provides a method to manage contactless communication in a user device, said contactless communication performed by an applet of a service provider, said applet installed in a user device and said applet accessing to a memory of said user device in order to perform said contactless communication.

On the contrary to the known proposals, the method of the invention, in a characteristic manner it comprises: - giving access to a plurality of applets of said user device to said memory by means of a service manager entity, said plurality of applets being installed in said user device; and

- storing information of services providers of said plurality of applets in an isolated way using Universal Integrated Circuit Card security of said user device, each of said a plurality of applets having a different security domain wherein said information is stored.

Other embodiments of the method of the first aspect of the invention are described according to appended claims 2 to 14 and in a subsequent section related to the detailed description of several embodiments.

Brief Description of the Drawings

The previous and other advantages and features will be more fully understood from the following detailed description of embodiments, with reference to the attached drawings (some of which have already been described in the Prior State of the Art section), which must be considered in an illustrative and non-limiting manner, in which:

Figure 1 shows current MiFare5Mobile NXP structure.

Figure 2 shows the proposed Telco MiFare Mobile Management structure, according to an embodiment of the present invention.

Figure 3 shows and advanced versions of the proposed Telco MiFare Mobile Management structure, according to an embodiment of the present invention.

Figure 4 shows in details the components and interfaces of the "Telco MiFare Mobile Management" (T3M) structure, according to an embodiment of the present invention.

Figure 5 shows the flow diagram for service provider swapping, according to an embodiment of the present invention.

Figure 6 shows the flow diagram for service provider tag reading, according to an embodiment of the present invention.

Detailed Description of Several Embodiments

The "Telco MiFare Mobile Management" (T3M) has been designed as a solution to manage all MiFare and Calypso flavors on a mobile handset. This solution was designed to be more Mobile Network Operator (MNO) friendly and also to be a very secure solution so a trusted environment for the Service Provider has been defined.

The T3M uses the UICC (SIM) security to store the contactless application (like MiFare or Calypso) information of a SP in an isolated way.

T3M has multi-TSM support and all SP information is managed by the SP applet so no security keys flows through the Service Manager.

A generic scheme is shown in Figure 2.

A specific T3M structure has been created in order to be able to deploy MiFare services when no current standard is available. This structure could be used as the selected one for standardization and wide adoption.

The main objectives when defining the T3M structure are:

- Multiapplication support: NXP defined a multi-application solution for the MiFare cards using the MiFare Application Directory (MAD) directory. These solutions are limited to one MiFare memory and all Service Providers should share the same memory area. The proposed solution allows each SP to define its own memory structure as well as MAD applications are also supported.

- Service Provider privacy: In the current implementations all SP must store their codecs in the same Security Domain and only one applet access to the SP private data in the MiFare memory. The proposed solution isolates each SP in its own SD and also the Service Manager acts only as a director giving the access to the shared resource (MiFare memory) to each service provider applet.

- OTA Management: For the T3M solution, the OTA management was mandatory and fullfills the GP and M4M specifications.

A more advanced version can add support for DESFire, Calypso and Classic 7 and 4 bytes UID, as shown in Figure 3.

The main components in the T3M solution are:

1. T3M Service Manager

- Orchestrates MiFare application management and provides security.

- Interfaces with the wallet through a proprietary API and through a

MiFare4Mobile Wallet API (i.e.: activate/deactivate application puts MiFare SP data in the MiFare emulation, read/write data of a given application, get a list of available MiFare applications). - It can interface with the OTA management platform for MiFare specific data update commands following M4M TSM API. However most management of the applets can be done directly via the GP platform.

- It does NOT hold or transport at any point any SP data or keys.

2. T3M Service Provider

- Holds the SP MiFare keys. They can be produced dynamically inside the applet or personalized using remote GP procedures or contactless APDU commands.

- Its instantiated in a SP specific GP SD for secure management and personalization.

- Its load and installation can be done through the usual GP channel.

- Holds a memory map of the MiFare application that will be loaded inside the MiFare memory emulation when the application is activated and the SP applet is commanded to do so by the Service Manager. The load is done directly by the SP applet, thus no information goes through the Service Manager. It uses javacardx.external to do so.

- Defines a set of tags with data that can be accessed by the Service Ul.

- There will be a generic T3M MiFare SP applet in order to provide security when there is no application selected.

This implementation of a MiFare application environment fulfils the requirements set before providing SP security independence (according to GP), multi- application, remote access and a User Interface API.

Advantages of the invention

- More privacy: Each service provider's information resides into an isolated security domain inside the UICC.

- More secure: Each service provider manages their information without needing a parent cardlet to manage the memory.

- The MiFare memory is protected when no other Mifare application is active.

- Multi TSM support.

A person skilled in the art could introduce changes and modifications in the embodiments described without departing from the scope of the invention as it is defined in the attached claims. ACRONYMS

API Application Programming Language

CLF Contactless Frontend

CLT Contactless Transmission

GP Global Platform

M4M MiFare for Mobile

MNO Mobile Network Operator

NFC Near Field Communication

OTA Over The Air

SP Service Provider

T3M Telco Mifare Mobile Management

TSM Trusted Service Management

Ul User Interface

UICC Universal Integrated Circuit Card

UI D User Identifier

REFERENCES

[1] NXP MI FARE4Mobile Interface Specification V1.01

[2] ISO/IEC 14443-1 , ISO/IEC 14443-2, ISO/IEC 14443-3, ISO/IEC 14443-4

[3] ETSI TS 102 613 Smart Cards; UICC - Contactless Front-end (CLF) Interface;

Part 1 : Physical and data link layer characteristics v 7.8.0 (2010-04)

[4] ISO/IEC 7816

Claims

'\ .- A method to manage contactless communication in a user device, said contactless communication performed by an applet of a service provider, said applet installed in a user device and said applet accessing to a memory of said user device in order to perform said contactless communication, characterised in that it comprises:

- giving access to a plurality of applets of said user device to said memory by means of a service manager entity, said plurality of applets being installed in said user device; and

2. - A method as per claim 1 , wherein said contactless communication is carried out by means of MiFare technology and said memory is a MiFare memory.

3. - A method as per claim 2, comprising allowing each service provider of said one or more applets to define its own memory structure or using MiFare Application Directory structures.

4. - A method as per claim 2 or 3, comprising providing, said service manager entity, an interface with a wallet of said user device through a proprietary Application

Programming Interface, or API, and through a MiFrae4Mobile Wallet API, said wallet being a graphical user interface of said user device.

5. - A method as per claim 4, comprising providing, said service manager entity, an interface with an On The Air, or OTA, platform for MiFare specific data update commands using a MiFare4Mobile Trusted Service Management API.

6. - A method as per any of previous claims 2 to 5, comprising instantiating a service provider repository in a service provider specific global platform, or GP, security domain for secure management and personalization.

7. - A method as per claim 6, comprising loading and installing said service provider repository through a GP channel.

8. - A method as per claim 7, comprising, said service provider repository:

- holding service providers MiFare keys; and/or

- holding a memory map of a MiFare application that will be loaded in said MiFare memory when said MiFare application is activated and said service manager entity commands it to the applet associated to said MiFare application, wherein said load is done directly by said applet with no information going through said service manager entity.

9.- A method as per claim 8, comprising performing said load by means of a javacardx.external.

10.- A method as per claim 8 or 9, comprising generating said MiFare keys dynamically inside an applet, using remote GP procedures or using contactless Application Protocol Data Unit commands.

1 1 . - A method as per any of previous claims 6 to 10, comprising defining a generic service provider repository in order to provide security when none MiFare application is selected.

12. - A method as per any of previous claims 6 to 1 1 , comprising performing a service provider swapping by performing the next steps:

- sending, said service manager entity, an unload message to the repository service provider of current active service provider;

- sending, said repository service provider of current active service provider, a read sector data message to said MiFare memory;

- storing, said repository service provider of current active service provider, a sector data received from said MiFare memory in a database;

- sending, said repository service provider of current active service provider, a remove sector data message to said MiFare memory and a set transport keys message;

- sending, said service manager entity, a load message to a repository service provider of a different service provider;

- reading, said repository service provider of a different service provider, a data sector from a database;

- sending, said repository service provider of a different service provider, a write sector data message to said MiFare memory; and

- performing a set active service provider instruction in said service manager entity.

13.- A method as per any of previous claims 6 to 1 1 , comprising performing a service provider tag reading by performing the next steps:

- sending, said service manager entity a get tag message to a repository service provider;

- performing a get sector and block instruction in said repository service provider; - sending, said repository service provider, a read data to said MiFare memory; and

- sending, said repository service provider, data received from said MiFare memory to said service manager entity.

14.- A method as per any of previous claims 6 to 14, comprising adding support to said service provider repository for DESFire, Calypso and Classic 7 and 4 bytes User Identifier.