Evolution du rôle de la carte à microprocesseur dans

les systèmes d'information distribués

Didier Donseza, Sébastien Jeanb, Sylvain Lecomteb
(a)
Laboratoire d'Automatique et de Mécanique Industrielle et Humaines

Université de Valenciennes - Le Mont Houy, BP311

59304 Valenciennes Cedex, France

e-mail : donsez@univ-valenciennes.fr
tel : 03 27 14 85 20
fax : 03 27 14 11 83
(b)
Laboratoire d’Informatique Fondamentale de Lille

Recherche et Développement du Dossier Portable

Bât. M3, cité scientifique - 59 655 Lille Cedex, France
e-mail : {jean,lecomte}@lifl.fr
tel : 03 20 43 47 14
fax : 03 20 43 47 12

Résumé :
Le Web et les Codes Mobiles modifient profondément la conception des systèmes d'information et de leurs
applications. Le concepteur doit notamment intégrer des besoins de sécurité, mobilité et disponibilité. Dans cet
article, nous étudions comment la carte à microprocesseur, qui est un composant informatique très sécurisé, peut
répondre aux nouveaux besoins des systèmes d'information distribués. Pour cela, il convient de donner aux cartes un
rôle plus central que celui de simple serveur de données. Nous étudions donc la possibilité, pour une carte, d'être
client, et même d'être pilote d'une application distribuée.

Mots Clés : Carte à microprocesseur, Applications distribuées, Sécurité, Mobilité

Abstract :
Web and mobile code deeply modify information systems and applications design. The designer must
particularly integrate security, mobility and availibility needs. In this article, we study how smartcard, which is an
highly secure computing component, can assume the new distributed information systems needs. In order to assume
these new properties, smartcards must be casted for a new part, much more central than a simply data server one. At
the end of this article, we study the possibility for smartcard to be client, and even more a pilot, for a distributed
application.

Keywords : Smartcard, Distributed applications, Security, Mobility

1 Introduction
Depuis la création des cartes à microprocesseur en 1974, suivant les concepts énoncés par
Roland Moréno, les technologies, tant logicielles que matérielles, ont beaucoup évoluées. Si bien
que tout un chacun dispose maintenant d' une ou plusieurs cartes dans son portefeuille (on peut
notamment citer les cartes bancaires, les cartes pré-payées de téléphonie, ou les cartes de santé).
Une carte à microprocesseur [ISO87][ISO88] est constituée d’un micromodule
monolithique contenant un microprocesseur (le plus puissant est un RISC 32 bits), de la mémoire
ROM pour le système d’exploitation (64 Ko maximum), de la mémoire de travail RAM (1 Ko),
et un support stable pour contenir les données et les programmes (type EEPROM, 64 Ko au
maximum). La sécurité de l’ensemble est assurée par un bloc de sécurité interdisant le
fonctionnement de la carte en cas d’utilisation dans des conditions anormales.
Actuellement, les cartes sont principalement utilisées dans trois applications différentes :
le paiement, la sécurisation des accès (physique ou logique) et les dossiers portables. Pour
assurer la sécurité des échanges avec l’extérieur, la carte dispose de fonctions (matérielles ou
logicielles) de chiffrement. Il est important de noter que les cartes les plus récentes permettent
l’utilisation de plusieurs services (une carte peut par exemple contenir une application GSM et
un PME1).
Ces trois domaines d’applications intéressent principalement les secteurs :
• de la finance : les banques utilisent les cartes de paiement,
• de la téléphonie mobile : les prestataires de service GSM et Iridium utilisent
des cartes d’accès logique à leur réseau,
• et de la médecine : la carte santé permet de véhiculer le dossier médical du
patient.
Ces dernières années, la carte à microprocesseur connaît un fort développement, et les
besoins de sécurisation des paiements sur les réseaux distribués devraient conforter cette
avancée.
Pour cela, il a fallu intégrer les cartes dans les systèmes distribués « classiques ». Un
exemple de cette intégration est le projet OSMOSE [VAND97]. Dans ce projet, les services
présents dans une carte sont accessibles via un médiateur CORBA [OMG98] (cf. Figure 1).

1
PME : porte-monnaie électronique
 Services Carte
Appli.
Client

Dépôt
d’inter-
-faces
Invocation Stubs Card Object
Dynamique IDL Adapter

Noyau ORB

Figure 1 : La carte dans les systèmes distribués

Les problèmes de panne liés à l’utilisation des cartes dans les systèmes distribués ont été
résolus par l’utilisation de mécanismes transactionnels, permettant d’assurer les propriétés
ACID2 à des applications distribuées ayant des cartes à microprocesseur comme partenaire
(projet COST-STIC [LECO98]).
Dans cet article, nous allons poursuivre l' examen de l' intégration de la carte dans les
systèmes distribués, en étudiant les nouveaux besoins des applications distribuées, en terme de
sécurité, de sûreté de fonctionnement, et de mobilité des composants.
Ensuite, nous décrirons les nouveaux rôles possibles pour les cartes à microprocesseur, en
étudiant notamment la place de ces cartes dans les systèmes distribués (serveur, client, ou
coordinateur de certaines phases de l' exécution de l' application).
Et enfin, nous conclurons en traitant des conséquences sur les applications distribuées, de
l' arrivée de nouveaux composants, tels que les étiquettes électroniques, qui permettent à ces
applications d' atteindre une qualité de service en terme de sécurité ou de sûreté difficile à obtenir
actuellement.

2 Besoins des Systèmes d' Information Largement Distribués

Le Web et les Codes Mobiles (Applets Java, Contrôles ActiveX, Agents mobiles [C98],
…) ont d' ore et déjà profondément modifié la conception des systèmes d' information et de leurs
applications. Auparavant, dans l' approche Client/Serveur (ou même dans l' approche Trois-Tiers),
l' exécution d' une application entraînait l' exécution d' une partie de son code sur le client et
l' exécution de l' autre (ou des autres) partie(s) sur un (ou plusieurs) serveur(s). La partie serveur
est invoquée par des requêtes à distance (Remote Procedure Call, Remote Method Invocation) de
la partie cliente. Dans ce contexte, le concepteur d' application considère que l' ensemble des
codes s' exécutant sur le (ou les) serveur(s) sont administrés par l' organisation (entreprise, …) qui
déploie ces services. Alors, l' ensemble des composants logiciels et matériels se font
mutuellement confiance pourvu qu' ils soient sur un des serveurs de l' organisation et que les
différents composants soient interconnectés entre eux par un réseau fiable.

2
ACID : Atomicité, Cohérence, isolation, Durabilité
 Dans le contexte du Web et des codes mobiles, l' exécution d' une application nécessite
l' exécution de codestéléchargés sur le client et les serveurs. Ces codes téléchargés (applets chez
l' usager, agents mobiles chez le commerçant, …) ont des origines diverses (éditeurs de logiciels,
…) et ne sont pas obligatoirement produits par les organisations qui déploient les services
proposés aux usagers. Plusieurs organisations peuvent être engagées dans l' exécution de
l' application. L' exemple d' une application de commerce électronique illustre cette situation : 4
organisations sont présentes le temps de l' application (un usager acheteur, un usager vendeur, la
banque de l' acheteur et la banque du vendeur). Dans ce contexte, le concepteur d' application
considère un ensemble de composants logiciels et matériels qui vont coopérer pendant la durée
de l' application et qui à priori ne se font pas forcément confiance mutuellement.
D' autre part, l' usager de l' application est de plus en plus nomade et peut initier
l' application depuis n' importe quel point d' accès à son réseau de service (par exemple,Web,
le
une chaîne de TV par abonnement, …). Ces points d' accès offerts à l' usager seront de plus en
plus des terminaux nomades comme le téléphone GSM couplé à (ou intégré dans) un assistant
personnel (PDA : Personal Digital Assistant), ou bien des terminaux anonymes comme une
borne téléphonique dans un lieu public ou une Set Top Box (STB : terminal de TV interactive ou
de WebTV) dans sa chambre d' hôtel.
L'u sager doit pouvoir commencer une application depuis un terminal, l' interrompre, puis
la reprendre depuis un autre terminal afin de la terminer. Ce type de service imposera très
vraisemblablement un fort développement avec les agents mobiles intelligents [NAKA97].
L'u tilisateur lance un agent à la recherche d' une information, se déconnecte et sereconnecte
depuis un autre poste ou depuis un autre endroit pour y récupérer le résultat
[CARL98][CARL97]. L' interruption de la connexion avec les serveurs peut être volontaire de la
part de l' usager. Par conséquent, elle ne doit pas être obligatoirement traitée par les autres
composants de l' application comme une erreur.
De même, l' usager doit pouvoir initier l' application avec seulement une partie des
composants. Ce mode de fonctionnement se produit quand il se trouve dans un lieu dépourvu de
point d' accès au réseau ou quand une panne a lieu sur le réseau (encombrement, perte de ligne,
…). Ce mode de fonctionnement est aussi souhaité par le concepteur, quand réunir l' ensemble de
ses composants entraîne des communications coûteuses en temps de réponse et en argent.
Le concepteur doit donc désormais intégrer dans la conception de l' application les trois
nouveaux besoins suivants qu' il négligeait jusqu' à présent : la sécurité, la mobilité et la
disponibilité. Nous allons maintenant détailler ces besoins, et proposer des solutions dans
lesquelles la carte tient une place centrale dans la conception de l' application.

2.1 La Sécurité
Ces nouvelles applications engagent de nombreux composants fournis et administrés par
de nombreuses organisations qui à priori ne se font pas toutes confiance. Il convient donc
d' établir un espace de confiance afin d' initier l' application. Avec l' exemple du paiement
électronique d' un achat, un espace de confiance assure :
• à l' acheteur d' obtenir la marchandise achetée et d' être débité du montant exact
de sa commande,
• et au vendeur d' être crédité en retour du même montant.
L' espace de confiance est créé àl' initialisation de l' application, et est maintenu jusqu' à sa
terminaison. Cet espace doit être aussi assuré quelles que soient les conditions de
fonctionnement. Par exemple quand les banques ne sont pas joignables ou qu' elles ne sont pas
contactées, l' espace se restreint au terminal du vendeur, et à celui de l' acheteur (figure 2).
En terme de sécurité, la carte à microprocesseur de paiement (Carte Bancaire) est émise
par une organisation (les banques) auprès de son porteur (l' acheteur et/ou le vendeur). Elle assure
l' authentification du porteur auprès des composants des autres organisations quand l' ensemble
des composants est engagé dans l' application (modeOnline). L' espace de confiance est alors
établi par une des deux banques. La carte permet aussi l' établissement d' un espace de confiance
quand une partie seulement des composants est engagée (mode Offline). Elle enregistre alors les
ordres signés et échangés par les composants participant à l' application afin d' éviter toute
répudiation ultérieure. La carte devra aussi sécuriser les terminaux anonymes sur lesquels
l' usager se connectera pour y initier ou continuer ses applications.

Acheteur Acheteur
Vendeur Vendeur
(porteur) (porteur)

Banque Banque Banque Banque

Acheteur Vendeur Acheteur Vendeur
(émetteur) (émetteur)

Mode Online Mode Offline

Figure 2 : Espaces de Confiance

2.2 La Mobilité
Désormais, l' usager est un "nomade" qui utilise à la fois un terminal mobile et/ou des
terminaux anonymes mis à sa disposition dans les lieux publics, sa chambre d' hôtel, … Ce type
de terminaux pose le problème de la durée de la connexion de l' usager au réseau. La partie Client
ne reste pas connectée au restant des composants qui sont engagés dans l' application initiée.
L' avancement de l' application doit pouvoir être repris à reconnexion
la de l' usager afin de la
poursuivre.
Dans ce cas, le contexte nécessaire à la reprise ne peut être conservé sur le terminal. La
carte à microprocesseur apporte la possibilité de conserver ce contexte de manière persistante et
de rétablir le contexte quand la carte est de nouveau insérée dans le lecteur du nouveau terminal.

2.3 La Disponibilité
Dans le contexte de large distribution, il ne sera pas toujours évident ou même
souhaitable de disposer de l' ensemble des composants pour initier et même pour continuer une
application. Ce type de conception est déjà classique avec les paiements par carte bancaire qui
définissent deux modes de fonctionnement : le mode Online dans lequel le réseau Carte Bleue est
contactée pour demander une confirmation et le mode Offline dans lequel la carte signe seule le
paiement. Dans des applications plus générales, le concepteur pourra définir quel est le
fonctionnement de l' application quand la configuration ne comporte que quelques composants
disponibles, et quelles sont alors les conditions d' utilisation. Par exemple dans le cas d' un
paiement électronique sans que les banques soient engagées, les composants nécessaires sont au
minimum les terminaux de l' acheteur et du commerçant et la condition d' utilisation est un seuil
maximum d' achat cumulé par l' acheteur.
Dans ce contexte, la carte à microprocesseur permet d' embarquer les configurations de
composants, leurs interactions et les conditions de fonctionnement des configurations. La carte,
en tant qu' organe de sécurisation, est aussi chargée de vérifier la condition d' utilisation de la
configuration. La carte peut dans un mode Offline, embarquer une partie du code et des données
nécessaires pour que les terminaux puissent les charger et les exécuter. Par exemple, des
composants pourraient être une applet qui permettrait aux terminaux de l' acheteur d' afficher
l' interface (GUI) de sélection de la source d' argent (porte-monnaie électronique ou carte
bancaire).

3 Une nouvelle utilisation des cartes à microprocesseur

Les problèmes précédemment cités dans les systèmes distribués, ainsi que les avancées
technologiques des cartes à microprocesseur, nous poussent à donner à ces cartes un rôle de plus
en plus central dans les applications.
Dans cette partie, nous allons étudier trois nouvelles possibilités d’utilisation des cartes.
Tout d’abord, nous verrons la carte cliente, qui va accéder à des informations distribuées sur le
réseau. Puis, nous nous intéresserons à la définition d’une carte capable d' initier une application
distribuée, et enfin, nous terminerons cette partie, par l' application du principe d' une carte qui
pilote la validation d' une transaction distribuée par une carte.

3.1 Vers une Carte Cliente

Jusqu' à maintenant, la carte a toujours été considérée comme un serveur soit de données
(pour des cartes comme la CQL [GRIMO92], qui contient des tables SQL), soit de code (pour
des cartes qui contiennent, par exemple, des Porte Monnaie Electronique). Ce principe était bien
adapté au protocole de communication de la carte T=0 [ISO89]. Dans ce protocole, les ordres
sont toujours émis du lecteur vers la carte et jamais dans l' autre sens : l' application sur le terminal
envoie via le lecteur une requête au serveur (c' est à dire la carte); celle-ci effectue un traitement,
et retourne un résultat comme acquittement.
Aujourd' hui, les capacités de la carte, tant au niveau matériel, qu' au niveau logiciel,
évoluent très rapidement. Nous proposons ici, un exemple d' application ou la carte peut être vue
comme le client de l' application distribuée, en s' affranchissant des contraintes du protocole. Nous
comparons cette nouvelle vision d' une application carte, à l' architecture classique
« » des
applications actuelles.
 Banque
4

3 2 Vendeur
Banque 3 5
1 Vendeur
4
2

Figure 3 : Exemple d’application avec carte cliente

Dans la figure 3, nous présentons un exemple d' application, où :

• 1er cas : la carte est serveur (figure 3 (a)). Dans ce cas, la carte est serveur de
l' application de paiement du commerçant. Ce dernier commence par contacter la carte pour
obtenir un certificat (1), en réponse à cette requête, la carte envoie son certificat (2). Après
cela, le commerçant n' a plus qu' à contacter la banque pour demander le débit du compte, en
fournissant le certificat de la carte. Dans cette solution, la carte se contente de donner son
certificat, sans pouvoir agir contre l' utilisation de ce certificat par le commerçant. Le
principal avantage de cette méthode est la simplicité du code embarqué dans la carte, et une
réplication limitée au strict minimum du code. Cette organisation des applications est bien
adaptée aux cartes actuelles.
• 2nd cas : la carte est cliente (figure 3 (b)) d' une banque, et d' un vendeur. L' intérêt de
ce cas de figure, est que toutes les requêtes transitent par la carte. C' est donc bien l' objet qui
veut effectuer la transaction qui dirige le tout : lorsque l' on veut acheter un bien avec sa carte,
tout doit passer par la carte. Dans un premier temps, la carte est introduite dans le lecteur, et
initialisée par ce dernier (étape 1). En réponse à cette initialisation, la carte envoie une
requête vers la banque pour demander le débit du compte (2). En réponse, la banque renvoie
un certificat à la carte (3). Après, la carte contacte le commerçant, en lui fournissant le
certificat, et en demandant l' achat (4). Pour terminer l' application, le commerçant valide la
vente à la carte (5). Toutes les informations circulent donc par la carte, qui est l' élément
sécurisé du réseau.

La carte ne doit donc plus être considérée uniquement comme un serveur d' une
application distribuée (que ce soit de code ou de données). Elle est maintenant suffisamment
puissante, en terme de processeur, en terme de mémoire, et en terme de fonctionnalité pour être,
si cela est nécessaire, cliente d' une application. Le protocole de communication de la carte peut
être étendue pour que les composants logiciels d' une carte puissent émettre des requêtes vers
l' extérieur de la carte. Ce type d' extension a déjà été réalisée avec les DMI qui masquent au
développeur les ordres T=0 [VAND98].

3.2 Vers une carte pilote

La notion de carte cliente constitue déjà une avancée de la vision que l' on pouvait avoir
de la carte à microprocesseur, c' est à dire un serveur portable de données sécurisées. Le concept
de carte pilote repose sur le modèle Client / Serveur dans la mesure où la carte pilote est amenée
à jouer les deux rôles au cours de l' exécution d' une application distribuée. Nous pouvons définir
la carte pilote comme une carte capable de contrôler de manière sûre et sécurisée tout ou partie
de l' exécution d' une application distribuée. Par exemple, la sûreté peut être assurée par la
maîtrise de la synchronisation et de la terminaison des différents composants. La sécurité peut
être assurée par la journalisation des ordres signés échangés par les composants pour prévenir de
toute répudiation. Il est alors sous-jacent qu' une carte pilote utilise le protocolebi-directionnel
utilisé par les cartes clientes. Elle émet des requêtes de contrôle vers les autres composants qui
sont à l' intérieur ou à l' extérieur de la carte. Dans ce qui suit, nous allons essayer de montrer que
la notion de carte pilote offre une approche nouvelle pour appréhender les problèmes de
confiance.

A l' heure actuelle, il apparaît un problème de confiance dans 2 classes de situations :

• Les applications distribuées multi-partenaires intégrant des cartes. Les différents
partenaires, qui peuvent ne pas se connaître, sont alors réunis dans le but d' effectuer
une action commune. Dans ce cas, le problème de confiance est inter-partenaires.
• L'u tilisation par un usager nomade de terminaux anonymes. Les terminaux anonymes
peuvent être définis comme des machines reliées à un réseau et adaptées pour
accueillir des cartes ou des couples carte/lecteur. L' exemple type du terminal
anonyme est un des PC d' uncybercafé disposant d' un navigateur et connecté à
Internet, ou bientôt une borne d' accès dans tous lieux publiques. L' utilisateur ne peut
pas faire d' hypothèses sur le niveau de sécurité des terminaux qu' il va rencontrer.
Lorsque le besoin de sécurité devient primordial, utiliser de manière aveugle ce type
de terminaux n' est alors pas envisageable. Ici le problème de confiance est un peu
différent du précédent : les différents partenaires qui peuvent intervenir se font à
priori confiance, la non-confiance se situe entre l' utilisateur et le matériel qu' il est
amené à utiliser.

Une application multi-partenaires peut être illustrée par l' exemple d' une application de
paiement (figure 4). Les 5 partenaires sont l' acheteur (A) qui est le porteur de la carte (C), la
banque (BA) qui a émis la carte de l' acheteur, le vendeur (V) chez lequel A effectue un achat et
la banque (BV) de ce dernier.
On peut schématiser la confiance dans cette application comme suit :
 Carte Carte
Acheteur Acheteur Acheteur Acheteur
Vendeur Vendeur
(porteur) (porteur)

Banque Banque Banque Banque

Acheteur Vendeur Acheteur Vendeur
(émetteur) (émetteur)

Mode Online Mode Offline

Figure 4 : Schéma de confiance d' une application

La première façon de résoudre l' absence de confiance entre l' acheteur et le vendeur est de
recourir à un tiers de confiance qui peut être une des deux banques ou une organisation
indépendante (comme VISA ou Amex). Cependant, parmi les solutions reposant sur les tiers de
confiance, il n' existe pas toujours d' interaction forte avec l' acheteur. Si aucun mécanisme fort de
confirmation n' est proposé à l' acheteur, ce dernier ne peut empêcher une fraude éventuelle du
vendeur qui peut essayer de falsifier le montant de la transaction, ou encore tenter de reproduire
l' opération.
Une autre solution est de donner à la carte le rôle de coordinateur du paiement. Puisque la
carte fait partie des espaces de confiance de chaque partenaire, ce rôle semble assez naturel. Cela
permet de garantir le montant de l' achat, à condition de prendre comme hypothèse que les saisies
et affichages sur le terminal ne sont pas frauduleuses. Ceci exclut également une possible
reproduction de l' opération, à l' insu de l' acheteur, puisque l' achat ne peut pas être mené en
l' absence de la carte. Nous développerons dans la suite les principes de mise en œuvre de
mécanismes transactionnels qui peuvent être placés au dessus de cette coordination.
Dans le cas des terminaux anonymes, le problème de confiance est différent. Prenons
comme exemple l' accès à des services distants. On considère que l' usager (que nous confondrons
ici avec le porteur) est abonné à des services distribués sur Internet, les informations d' accès et de
personnalisation étant stockées sur la carte.
Une méthode simple pour s' identifier auprès d' un service auquel un utilisateur s' est
abonné est d' utiliser un couple identificateur,
( mot de passe). Si l' on ne considère pas les
problèmes de sécurité liés au transport de l' information sur le réseau, cette solution semble
satisfaisante si l' utilisateur peut avoir confiance dans le terminal à partir duquel il souhaite
accéder au service. Cependant, cette approche se révèle inexploitable lorsque le niveau de
sécurité du terminal n' est pas connu. Si un "cheval de Troie" sur le terminal surveille les
opérations qui y sont effectuées, le couple (identificateur, mot de passe) peut alors être aisément
récupéré et utilisé de manière frauduleuse, à l' insu de l' utilisateur.
L' apport de l' approche pilote permet d' apporter une réponse plus satisfaisante dans ce cas
puisqu' elle s' abstrait du niveau de sécurité du terminal. Considérer la carte comme le pilote de
l' application revient ici à laisser la carte initier et instaurer le dialogue avec le service distant, en
n' utilisant le terminal que comme une passerelle vers le réseau. Pour être plus précis, le terminal
ne fait que transmettre des requêtes signées ou confidentielles dans les 2 sens, sans pouvoir à
priori connaître la nature des opérations qui sont en train d' être menées. Il reste cependant
quelques problèmes à résoudre, que nous pouvons soulever grâce à l' exemple ducybercafé.
Premièrement, comment garder confidentielles les données sensibles qui doivent être saisies par
l' utilisateur du service : c' est le cas notamment du mot de passe ou du PIN code. Enfin, comment
s' assurer de l' intégrité des affichages sur le terminal : par exemple des prix, … Des travaux sont
actuellement en cours pour apporter des solutions à ces problèmes.

3.3 La carte gestionnaire de transactions

Nous avons mené des travaux pour intégrer les cartes à microprocesseur comme
partenaire de transactions distribuées [LECO98]. L' architecture logicielle utilisée pour cette
intégration est extrapolée (pour des raisons de capacité des cartes) à partir de l' architecture
présentée par la figure 5.

Service
Appli.
Recouvrable
Services Carte
IIOP

OTS

O.T.S.

Figure 5 : Architecture COST-STIC

La nécessité de pouvoir traiter des transactions à l' intérieur des cartes à microprocesseur,
vient principalement de l' émergence de nouvelles applications dans le monde des cartes . On peut
notamment citer :
• les applications multi-services carte, où plusieurs services, s' exécutant sur une ou
plusieurs cartes, coopèrent pour former une application,
• les applications sur plusieurs connexions de la carte : de part sa nature, les connexions
de la carte dans son terminal sont courtes et éphémères. Il est donc intéressant de
pouvoir gérer l' exécution d' une application sur plusieurs connexions de la carte,
• et en particulier, la participation de la carte à des transactions distribuées sur un
réseau non sécurisé.
Jusqu' à maintenant, nous avons principalement étudié les possibilités, pour une carte, de
participer à une transaction en tant que fournisseur de service sécurisé (un prototype basé sur
l' architecture CORBA, munie de son service transactionnel OTS[OMG97] a été réalisé dans ce
sens), ou en tant que client.
L' approche d' une carte pilote, présentée dans la partie précédente, nous offre la possibilité
de donner aux cartes à microprocesseur un rôle plus important dans le traitement des transactions
: celui de coordinateur de la validation distribuée, supportant un algorithme du type de la
validation à deux phases [OSI96].
Cette approche a comme principal avantage de sécuriser la validation des transactions. Le
moteur de validation est embarqué dans la carte qui est de confiance , ce qui permet d' éviter la
répudiation du protocole de validation par un des composants.
4 Conclusion
Dans cet article, nous avons présenté l' intérêt de considérer la carte à microprocesseur
comme un organe central et moteur dans les applications distribuées afin de répondre aux
nouveaux besoins de ces applications qui sont la Sécurité, la Mobilité et la Disponibilité.
Cependant, nous avons également vu qu' il reste des problèmes en suspens auxquels le
seul concept d' une carte pilote ne peut pas apporter de réponse. Il faut donc que le
développement de ce nouveau rôle, plus central, de la carte soit accompagné d' autres outils,
d' autres éléments sécurisants, afin de pouvoir tirer parti de cette approche (sécurisation des
périphériques d' Entrées/Sorties).
L' intégration des cartes à microprocesseur dans les systèmes distribués est un premier pas
pour la prise en compte, par ces systèmes, de nouveaux composants informatiques qui offrent de
nouvelles perspectives en terme de gestion de la mobilité des objets.
Un exemple de tels composants sont les étiquettes électroniques, qui peuvent être lues et
écrites à distance (c' est à dire sans contact physique avec un terminal). Il va donc devenir
possible d' exécuter des transactions largement distribuées sur les objets étiquetés : si on prend
l' exemple d' achat de stock (un peu comme cela se fait aux halles de Rungis), chaque marchandise
pourra disposer de sa propre étiquette électronique, et sera donc capable de participer
directement à la transaction de vente (échange de titre de propriété).

5 Bibliographie
[C98] IEEE Communications Magazine, july 1998, Vol. 36 No. 7, « Mobile Software
Agents for Telecommunications »
[CARL98] David Carlier, "Représentation permanente, coordonnée par une carte à
microprocesseur, d' un utilisateur mobile", Thèse à l' université de Lille 1, janvier
1998.
[CARL97] David Carlier, Didier Donsez, "Permanent Network Representation for Mobile
User", OPODIS, International Conference on Principles Of Distributed Systems,
France, décembre 1997.
[GRIMO] Edward Gordons, Georges. Grimonprez, "A Card as element of a distributed
database", IFIP WG 8.4 Workshop, Ottawa, 1992.
[LECO98] Sylvain Lecomte, "COST STIC : Des Cartes Orientés Services Transactionnels et
des Systèmes Transactionnels Intégrant des Cartes" Thèse à l' université de Lille 1,
novembre 1998.
[ISO87] International Standard Organisation (ISO), "Cartes d' identification – Cartes à
circuits intégrés à contacts – Partie 1 : Caractéristiques physiques", Norme ISO
7816-1, 1987.

[ISO88] International Standard Organisation (ISO), "Cartes d' identification – Cartes à

circuits intégrés à contacts – Partie 2 : Dimensions et emplacements des contacts",
Norme ISO 7816-2, 1988.
[ISO89] International Standard Organisation (ISO), "Cartes d' identification – Cartes à
circuits intégrés à contacts – Partie 3 : Signaux électroniques et protocoles de
transmission ", Norme ISO 7816-3, 1989.
[NAKA97] Y. Nakamura and G. Yamamoto, « An Electronic Marketplace Framework Based
on Mobile Agents », IBM Research, Tokyo Research Laboratory, Research
Report, RT-0224, 1997.
[OMG97] Object Management Group, "Object Transaction service", CORBA services
Specifications, décembre 1997.

[OMG98] Object Management Group, "CORBA 2.2/IIOP Specification", july 1998.

[OSI96] International Standard Organisation (ISO), "Distributed Transaction Processing

OSI-TP", Norme ISO/IEC 10026, 1996.
[VAND97] Jean-Jacques Vandewalle, "OSMOSE : Modélisation et Implémentation pour
l' interopérabilité de services carte à microprocesseur par l' approche orientée
objet", Thèse à l' université de Lille 1, mars 1997.
[VAND98] Jean-Jacques Vandewalle, Eric Vetillard, "Developing SmartCard based
Applications Using JavaCard", CARDIS' 98, Third Smartcard Research and
Advanced Application Conference, Belgique, septembre 1998.