Les cartes multi-services

Nous avons deja beaucoup parle de cartes multi-services depuis le debut de ce memoire. Cependant, les realisations faites jusqu'a ce jour concernaient uniquement des cartes contenant plusieurs applications, mais toutes parfaitement isolees les unes des autres.

Il s'agit ici de denir des modeles d'execution permettant la cooperation entre plusieurs services installes sur la m^eme carte a microprocesseur. Cette cooperation peut se faire de deux manieres:

{ Par communication Externe: La carte est alors reliee a un terminal qui fait d'abord appel a un service, puis a un autre (cf. gure II.1.2)

{ Par communication Interne: Un service carte fait appel a un autre service carte. Il se pose alors des problemes de communication entre services (c'est a la carte de gerer ce type de problemes).

Nous allons voir dans cette partie des exemples de cartes multi-services, ainsi que leurs principes de fonctionnement. Nous terminerons par les problemes encore en suspens dans ce type d'application carte.

3:Mais pouvant ^etre deconnecte de maniere impromptue, suite a la sortie de la zone de couverture

1.3.1.1 Des exemples d'applications

De maniere a mieux illustrer notre propos dans cette section, nous allons com-mencer par etudier quelles pourraient ^etre les applications mettant en jeu plusieurs services d'une m^eme carte a microprocesseur.

Parmi les services les plus souvent installes dans les cartes a microprocesseur, on trouve le PME et l'application GSM (Identication, agenda, etc.). Un premier exemple d'application utilisant simultanement plusieurs services d'une m^eme carte est le paiement d'un achat gr^ace a un PME, pendant une communication GSM (cette communication pouvant ^etre utilisee comme connexion a un reseau sans l) (cf. gure II.1.1). System RD2P Prestataire de Téléphonie Mobile Commerçant PME GSM

Fig. II.1.1 - Exemple d'application utilisant plusieurs services carte

Dans cet exemple, le GSM sert en fait de terminal de paiement pour le commer-cant. Le porteur est authentie aupres de son prestataire de telephonie et aupres du commercant gr^ace a l'application GSM de sa carte a microprocesseur.

Une autre application peut consister dans le rechargement du PME gr^ace au service((Carte Bancaire))installe sur la m^eme carte (sans que les deux appartiennent necessairement a la m^eme banque).

Comme on peut le voir, il est facile d'imaginer des applications mettant en jeu plusieurs services d'une seule et m^eme carte (carte sante permettant de payer sa consultation, application de recharge d'un credit telephonique a l'aide d'un PME, etc...). Pour que cela soit possible, nous allons maintenant etudier le principe de la cooperation de services carte entre eux.

1.3. APPLICATIONSFUTURES 51

1.3.1.2 Cooperation Externe

Le modele d'application decrit par la gure II.1.1 a de nombreuses consequences sur le modele d'execution des services internes a la carte.

Lecteur

Carte _APDU

Service 1 Service 2 Service 1

Fig. II.1.2 - Principe d'utilisation de plusieurs services

Dans le cadre d'une application utilisant plusieurs services d'une carte a micro-processeur, l'echange carte / terminal sera constitue de plusieurs sessions (cf. gure II.1.2).

En eet, si on reprend l'exemple precedent, a l'ouverture de la communication, la carte va echanger des informations avec le prestataire de telephonie mobile (Ser-vice 1) pour que l'utilisateur se connecte au reseau sans l. Puis, l'utilisateur va desirer faire un achat gr^ace a son PME. Alors, la carte eectue des echanges avec le commercant (Service 2) pour assurer le paiement de l'achat. Pendant le temps de l'achat, le prestataire de telephonie mobile doit pouvoir intervenir sur la carte (maintien de la connexion, depassement de temps de communication, etc...). Enn, apres l'achat, le service de telephonie reprend seul la main.

1.3.1.3 Cooperation Interne

Les cartes multi-services existantes ont actuellement des services completement cloisonnes (les services ne peuvent pas echanger de donnees ou partager des objets entre eux).

Cependant, la presence de plusieurs services dans une m^eme carte peut inciter a briser cet isolement, pour les faire cooperer. Prenons l'exemple de la gure II.1.3. Dans ce cas, la carte recoit un ordre APDU de son terminal demandant l'execution de l'application 1. Le systeme de la carte lance donc le service correspondant a cette application. L'invocation une methode de l'objet 2 de cette application 1, provoque l'appel a une application partagee (appelee Application 2). Le but de ce partage d'objets est a la fois d'eviter des duplications de programme a l'interieur de la carte a microprocesseur, mais aussi de faciliter la mise en commun de donnees.

Un exemplede partage d'objet entre services est celui des applications de delite. De plus en plus de grands groupes s'associent pour distribuer des cartes a micro-processeur de delite. Plusieurs prestataires peuvent passer un accord pour grouper leur ore de points de delite. Le compteur additionnant ces points doit donc ^etre partage entre toutes les applications des dierents prestataires.

Application 1

Objet 1 Objet 1 ^{Objet 1}

Carte à microprocesseur

Système

Application 2 Application 3

Objet 2 ^{Objet 2}

Fig. II.1.3 - Exemple de partage de donnees entre applications

Un tel partage pose des problemes de droit d'acces aux services: dans la gure II.1.3, le service 2 peut donner le droit au service 1 de l'utiliser, sans que le service 1 ai des droits sur le service 3 (la conance n'est pas transitive: le service 3 peut faire conance au service 2, le service 2 au service 1, et le service 3 peut ^etre en desaccord avec le service 1). L'execution d'une application 1 telle qu'elle est denie dans notre schema pose donc probleme.

Une autre maniere de limiter la duplication de code a l'interieur de la carte a microprocesseur est l'utilisation de bibliotheques, qui viennent enrichir le langage de programmation de la carte a microprocesseur.

Le principal avantage d'une utilisation de bibliotheque, par rapport au partage d'objet, est de limiter la duplication de code, sans pour autant augmenter les pro-blemes d'acces concurrents a un objet. De plus, la gestion des droits d'acces se trouve facilitee.

Cependant, une telle cooperation ne permet pas le partage de donnees. Par exemple, la mise en commun d'un PME n'est pas possible avec la seule utilisation de bibliotheques.

Dans ce memoire, nous ne traiterons pas plus en avant les problemes de securite lies aux communications entre des services carte, et nous nous concentrerons sur la denition d'une carte capable de gerer des transactions utilisants plusieurs services. Pour cela, nous considererons que les problemes de securite lies au partage des objets dans la carte sont resolus (par des accords entre les dierents prestataires qui ont installe les services).

1.3.1.4 Problemes poses

Les nouvelles applications basees sur les cartes multi-servicesposent de nombreux problemes.

1.3. APPLICATIONSFUTURES 53 oblige a eectuer des changements de contexte dans la carte. En eet, la carte a microprocesseur actuelle est mono-t^ache: un seul service s'execute a la fois. En outre, de par la taille de la RAM disponible dans les cartes a microprocesseur, un changement de contexte d'execution oblige un vidage complet (((Flush)) en anglais) de la memoire volatile sur le support non volatile.

Cependant, la gestion de plusieurs contextes applicatifs dans la carte peut s'ave-rer insusante. En eet, l'execution de plusieurs services dans la carte, pouvant en plus partager des donnees, peut poser des problemes d'acces concurrents a ces don-nees. Dans l'exemple propose (gure II.1.2), les deux prestataires (le commercant et celui de la telephonie) accedent a des services dierents de la carte a micropro-cesseur. Cependant, il se peut aussi qu'ils essayent d'acceder au m^eme service (par exemple le PME), ce qui pose des problemes de contr^ole des acces concurrents aux donnees de ce service.

Le dernier point problematique concerne le partage d'objet entre deux services installes dans une m^eme carte. En eet, le contr^ole sur la concurrence des acces a un objet partage est beaucoup plus problematique, et peut ^etre rapproche des pro-blemes de contr^ole de concurrence des transactions embo^tees vues dans le chapitre precedent (le service appele par le terminal, peut ^etre vu comme la transaction mere, et l'appel par ce service a des methodes d'un autre service, comme l'execution d'une sous transaction).