Rapport de stage du dea d’Informatique de Lyon








télécharger 152.95 Kb.
titreRapport de stage du dea d’Informatique de Lyon
page6/7
date de publication31.01.2018
taille152.95 Kb.
typeRapport
ar.21-bal.com > droit > Rapport
1   2   3   4   5   6   7

3.3Le simulateur d’applets Java Card

3.3.1Le modèle



Ses acteurs

Les principaux acteurs lors d’une transaction entre une carte à puce et un CAD sont :

  • l’utilisateur qui choisit quelle application et quelle opération il souhaite effectuer.

  • le CAD. Son rôle est d’attendre la commande de l’utilisateur, de la transmettre codée dans l’APDU à la carte. Puis il doit attendre la réponse de la carte (une APDU de réponse). Les deux APDUs seront affichées décodées à l’utilisateur.

  • la carte à puce qui contient le JCRE et les applications possibles (dans notre cas les applets PurseFr et FrequentFlyer). Son rôle est d’attendre une commande du CAD, de l’exécuter et de renvoyer une réponse.


Nous avons décidé de simuler l’ensemble de ces acteurs pour pouvoir tester des applets Java Card sur une station de travail. Pour cela, nous avons codé en Java le comportement de chaque acteur.

Son architecture

Pour simplifier notre modèle dans une première approche, nous avons décidé de simuler seulement les événements synchrones i.e. les actions de l’utilisateur sur le lecteur de carte. Donc tous les événements asynchrones comme une coupure de courant ou un retrait de carte ne sont pas encore gérés par notre modèle. Mais nous en avons tenu compte lors de la phase de conception afin de faciliter leur intégration future lors de l’évolution de notre modèle.

Chaque acteur (User, CAD, JCRE) est modélisé par un Thread Java (cf. Figure 7).






Figure 7 Schéma du modèle adopté

Nous avons choisi de représenter les différents acteurs par des Threads pour représenter au mieux la réalité et pour permettre la gestion future des coupures de courant ou des retraits de carte. En effet, dans la réalité un utilisateur est indépendant du lecteur de carte. Il peut à tout moment retirer sa carte ou taper sa commande sur le lecteur. Donc le lecteur est un processus en attente d’actions de l’utilisateur. Le JCRE de la carte est aussi un processus en attente d’APDU de commande.

Nous avons aussi choisi de représenter les applets de la carte par des threads. En effet, il est envisagé dans le futur d’introduire du multithreading sur une carte à puce. De plus, cela nous permettait de séparer les contextes d’exécution des objets contenus sur la carte et donc d’avoir une meilleure visualisation de ce qui se passe sur la carte.

Le JCRE doit être le plus générique possible pour pouvoir référencer n’importe quel type d’applet contenue par la carte.
Son fonctionnement

Nous avons choisi un mode de fonctionnement maître/esclave permettant d’avoir un déroulement séquentiel. C’est pourquoi un seul Thread est actif à un instant donné comme nous le montre la Figure 8.


Figure 8 Déroulement séquentiel de l’exécution de notre programme

Description des différentes phases

Tous les threads (User, CAD, JCRE) sont créés, démarrés, puis suspendus (méthode invoquée : suspend()) en attente d’être réveillés (méthode resume()).

  1. Le thread User est réveillé. Il simule un utilisateur i.e. envoie une action au CAD. Le thread User réveille le Thread CAD pour lui envoyer une action ou une demande d’installation d’applet et se suspend (i.e. attend la réponse à son action).

  2. Le thread CAD fabrique une APDU de commande en fonction de l’action demandée, l’envoie au JCRE, le réveille et se suspend (l’exécution d’une action peut prendre 2 transactions si l’applet indiquée n’est pas déjà sélectionnée car il faudra au préalable la sélectionner sur la carte avant de pouvoir exécuter l’action).

  3. Quand le thread JCRE se réveille, il regarde si l’APDU de commande demande une sélection ou non. Si c’est une sélection, il desélectionne l’applet courante et demande la sélection de l’applet indiquée (l’APDU contient l’AID d’une applet). Sinon il réveille l’applet courante et se suspend. Dans les 2 cas, il est suspendu, en attente de la réponse de l’applet.

  4. Quand l’applet est réveillée, la méthode indiquée (i.e. soit process(), select() ou deselect()) est exécutée. Lors de l’exécution de la méthode process() une APDU de réponse est créé. L’applet réveille le Thread JCRE et se suspend.

  5. Le JCRE envoie l’APDU de réponse attendue par le CAD. Il réveille le CAD et se suspend.

  6. Le CAD affiche l’APDU, réveille le Thread User et se suspend (i.e. attente d’une nouvelle action).


Son Implémentation

Le programme se compose de 10 classes :

  • la classe Root (thread principal) sert uniquement à créer les Threads User, JCRE et CAD.

  • La classe User simule un utilisateur exécutant des actions sur un lecteur de carte.

  • La classe CAD. Son rôle est de traduire les actions de l’utilisateur soit en APDU de commande pour la carte soit en installant une nouvelle application sur la carte.

  • La classe JCRE. Cette classe gère les applets contenues sur la carte. Elle sert d’interface entre le lecteur de carte et les applets.

  • La classe PurseFR. Cette applet permet la gestion d’un porte-monnaie électronique.

  • La classe FrequentFlyer. Cette applet gère les miles bonus octroyés par une compagnie aérienne lors de l’achat d’un billet d’avion

  • La classe APDU. Cette classe permet une représentation simplifiée des APDUs.

  • La classe Applet, l’ancêtre de PurseFr et FrequentFlyer. Elle contient la méthode run() des threads qui permet de rendre la gestion des threads invisible pour ces sous-classes.

  • La classe Object utile pour l’interprète (elle ne contient que la déclaration du constructeur).

  • La classe Thread aussi utile pour l’interprète (elle contient juste la déclaration du constructeur et de la méthode start()).


Vue la longueur de notre programme (environ 500 lignes), seulement les parties les plus intéressantes des classes User (Tableau 4), CAD (Tableau 5), JCRE (Tableau 6), Applet (Tableau 7) et PurseFr (Tableau 8) sont présentées et commentées. L’annexe A contient l’ensemble du programme.


class User extends Thread {…

Public void run() {

Cad.installAppli(PurseFr.AID, 1000);

cad.sendAction(PurseFr.AID, PurseFr.PURSE_FR_WITHDRAW, 100);

cad.installAppli(FrequentFlyer.AID, 0);

cad.sendAction(FrequentFlyer.AID, FrequentFlyer.GAIN_MILES, 5000);}…}

Commentaires

Cette classe simule l’utilisateur. Sa première action est de faire installer par sa banque l’application PurseFr avec comme montant initial 1000 francs sur sa carte. Puis il se sert de sa carte pour payer son essence (retrait de 100 francs). Il décide ensuite de faire installer l’application Frequent Flyer par sa compagnie aérienne car il souhaite pouvoir conserver les miles de son voyage en Suède offerts (gain de 5000 miles). Ainsi il pourra, un jour, avoir un voyage gratuit

Chaque appel à la fonction sendAction envoie au CAD l’AID de l’applet sur laquelle l’opération indiquée doit être faite et attend sa réponse.

La fonction installAppli permet de simuler le chargement dynamique du code d’une applet sur une carte déjà en service.

Tableau 4 Une partie de la classe User

Class CAD extends Thread {…

Public void run() {

While (true) {

sendActionToCard();

if (action == SELECT) {

if (apdu.sw1 == JCRE.OK) {

currentAID = AID;

apdu.setCommandApdu(JCRE.PROCESS_CLA, ins, NOTHING, commandData);

sendActionToCard();

}

else

currentAID = JCRE.NO_SELECTED_APPLET;

}

user.resume();

suspend();}…}

Commentaires

Cette classe simule le lecteur de carte qui traduit l’action demandée en APDU de commande standardisée en fonction des informations données lors de l’appel de la méthode sendAction().

Tableau 5 Une partie de la classe CAD


Class JCRE extends Thread {…

Public void run() {

while (true) {

/*// Select APDU*/

if (apdu.cla == SELECT_CLA && apdu.ins == SELECT_INS) {

if (selectedAppliAID != NO_SELECTED_APPLET) {

sendCommandToAppletAndWaitResponse(DESELECT, selectedAppliAID);

selectedAppliAID = NO_SELECTED_APPLET;

}

sendCommandToAppletAndWaitResponse(SELECT, apdu.p1);

if (apdu.sw1 == OK)

selectedAppliAID = apdu.p1;

} else { /*// Process APDU*/

if (selectedAppliAID != NO_SELECTED_APPLET)

sendCommandToAppletAndWaitResponse(PROCESS, selectedAppliAID);

else

apdu.sw1 = IMPOSSIBLE;

}

cad.apdu.copyResponseApdu(apdu);

cad.resume();

suspend(); /*Wait a CAD action*/ }…}

Commentaires

Cette classe simule le runtime de la carte. Son rôle est d’attendre une commande du CAD pour sélectionner, desélectionner les applets de la carte ou leur envoyer les commandes de l’utilisateur contenues dans les APDUs.

Tableau 6 Une partie de la classe JCRE


class Applet extends Thread {…/*//Java Card Applet*/

public void run() {

byte commandCode;

boolean selectOk;

while (true) {

commandCode = JCRE.self.commandCode;

if (commandCode == JCRE.SELECT) {

selectOk = select();

if (selectOk == true)

JCRE.self.apdu.sw1 = JCRE.OK;

Else

JCRE.self.apdu.sw1 = JCRE.IMPOSSIBLE;

} else

if (commandCode == JCRE.DESELECT)

deselect();

else

if (commandCode == JCRE.PROCESS)

process(JCRE.self.apdu);

JCRE.self.resume();

Suspend(); }…}…}

Commentaires

Cette classe décrit les Applets Java Card de notre modèle où chaque applet est un Thread. Donc chaque fois que l’on fait un resume() (pour réveiller le thread) sur une de nos applets, on exécute ce run() générique qui appelle la méthode appropriée de l’applet (i.e. soit process(), deselect() ou select()) et qui s’occupe de la gestion des Threads.

Tableau 7 Une partie de la classe Applet


class PurseFr extends Applet {

protected final static byte AID = 126;

/*//Possible Instructions*/

protected final static byte PURSE_FR_DEPOSIT = 1;

protected final static byte PURSE_FR_WITHDRAW = 2;

protected final static byte PURSE_FR_BALANCE_CHECK = 3;



public static PurseFr install(APDU apdu) {

return new PurseFr(apdu);}
public void process(APDU apdu) {

if (apdu.ins == PURSE_FR_DEPOSIT)

purseDeposit(apdu);

else

if (apdu.ins == PURSE_FR_WITHDRAW)

purseWithdraw(apdu);

else

if (apdu.ins == PURSE_FR_BALANCE_CHECK)

purseBalanceCheck(apdu);}…

Commentaires

Voici l’exemple d’une applet Java Card avec ses méthodes process() et install() ainsi que sa liste d’actions possibles (PURSE_FR_DEPOSIT, …). Chaque fois d’un développeur d’applet voudra tester une applet, il n’aura qu’à insérer son code Java Card, sans le modifier, dans le programme de notre modèle comme pour cette applet PurseFr. Puis il devra modifier légèrement la méthode run() de User pour installer son applet sur la carte et pour exécuter des actions. Il n’aura pas à s’occuper de la gestion des threads.

Tableau 8 Une partie de la classe PurseFr

3.3.2Modifications de la sémantique


Nous avons modifié la sémantique Java, en particulier, sur l’entrelacement des threads. En effet, une sémantique small-step classique, après chaque pas d’instruction élémentaire, recherche un autre thread à exécuter (simulation de la concurrence). Le modèle décrit permet d’avancer dans l’exécution d’un thread jusqu’à sa mort ou sa suspension comme nous le montre la spécification dans le set exec_activity du Tableau 9 (les modifications ont été mises en gras dans ce set. Le set treat_next_inst_if_not_suspended a été créé spécialement pour la sémantique Java Card ainsi que le set send_apdu qui sert à communiquer avec l’environnement.


set exec_activity is

--C : Deals with the execution of the thread activity.

--C : The first reference 'OThId1' is the current "executing" thread

--C : identifier. The second one 'ObjId1' is the current object identifier.

judgement Object_L, C_Var_L, O_Id, O_Id |- Activity -> Object_L, C_Var_L;

judgement Object_L, C_Var_L, O_Id, O_Id |- Clr :> Object_L, C_Var_L, T_Status;

judgement Object_L, C_Var_L, O_Id, O_Id, Clr

|- Inst -> Object_L, C_Var_L, Env, Clr, Comp_Exp, T_Status;



Dead_thread:

send_object_struct(ObjL1, ClVarL1) &

update_thread_status(ObjL1, ClVarL1, OThId1, dead() -> ObjL1_1) &

update_activity_in_object_l(ObjL1_1, OThId1,

clr(OThId1, Mode, MethName, env(pair_l[], locs[]), inst_l[]), ClVarL1

-> ObjL1_2)

----------------

ObjL1, ClVarL1, OThId1, ObjId1

|- clr(OThId1, Mode, MethName, env(ParL, LocL), inst_l[]) :> ObjL1_2,

ClVarL1, dead() ;

Do

send_dead(ObjL1_2, OThId1) & delete_a_given_thread_from_stack(OThId1);
General_rule:

delete_a_given_thread_from_stack(OThId1) &

ObjL1, ClVarL1, OThId1, ObjId1, clr(OThId1, Mode, MethName, Env1,

inst_l[Inst.InstL])|- Inst ->

ObjL1_1, ClVarL1_1, Env1_1, Clr2, Val, ThStatus1 &

Update_activity_in_object_l(ObjL1_1, OThId1, Clr2, ClVarL1_1 -> ObjL1_2)

& update_thread_status(ObjL1_2, ClVarL1_1, OThId1, ThStatus1 -> ObjL1_3)

& send_object_struct(ObjL1_3, ClVarL1_1) &

treat_next_inst_if_not_suspended(ObjL1_3, ClVarL1_1, OthId1, ObjId1

|- ThStatus1, Clr2 -> ObjL1_4, ClVarL1_2, ThStatus2)

----------------

ObjL1, ClVarL1, OThId1, ObjId1

|- clr(OThId1, Mode, MethName, Env1, inst_l[Inst.InstL]) :>

ObjL1_4,ClVarL1_2, ThStatus2 ; …

end exec_activity;
set treat_next_inst_if_not_suspended is

judgement

Object_L, C_Var_L, O_Id, O_Id

|- T_Status, Clr -> Object_L, C_Var_L, T_Status;
Not_suspended_thread:

send_current(ObjL1, OThId1) &

exec_activity(ObjL1, ClVarL1, OThId1, ObjId1 |- Clr

:> ObjL1_1, ClVarL1_1, ThStatus1_1)

----------------

ObjL1, ClVarL1, OThId1, ObjId1

|- ThStatus1, Clr -> ObjL1_1, ClVarL1_1, ThStatus1_1 ;

provided not_eq(ThStatus1, suspended(_));
Suspended_thread:

send_apdu(ObjL, OThId, Clr)

----------------

ObjL, ClVarL, OThId, ObjId

|- suspended(ThStatus), Clr -> ObjL, ClVarL, suspended(ThStatus) ;

end treat_next_inst_if_not_suspended;

Tableau 9 Spécification sémantique des threads de notre modèle

3.3.3Résultats obtenus lors de cette simulation


Lors du déroulement de l’interprétation de notre programme, certaines structures sémantiques sont affichées incrémentalement pour faciliter la mise au point des applets Java Card.
Fenêtres communes Java/ Java Card

L’environnement Java offre quatre fenêtres de résultats dont une (cf. Figure 9) qui montre l’évolution des états (suspended, runnable, etc.) des Threads par l’utilisation de couleurs, les dépendances des objets créés par le programme, les variables locales et les attributs des objets (cf. l’objet PurseFr).


Figure 9 Fenêtre graphique contenant tous les objets de notre modèle

Fenêtres spécifiques Java Card

Pour mettre au point une application Java Card, il est utile de visualiser les APDUs transmises entre le CAD et la carte (cf. Figure 10). Ainsi on peut espionner la ligne de communication entre ces deux entités et afficher les informations transitant sur cette ligne (i.e. les APDUs de commande du CAD vers le JCRE et des APDUs de réponse entre le JCRE et le CAD). Cette même information est affichée « décodée » dans une autre fenêtre (cf. Figure 11). simulant l’écran LCD (Liquid Cristal Display) du CAD pour être comprise. De cette manière, notre outil permet aux développeurs d’applets de mettre au point des applets Java Card ainsi que l’interface du CAD.
Il a fallu spécifier comment notre structure d’APDUs devait être construite dans la sémantique de notre interprète et à quels moments ces informations devaient être affichées dans les fenêtres de résultat

Pour pouvoir afficher cette même structure de deux manières différentes (i.e. selon si c’est l’écran LCD du CAD ou bien l’espion réseau), il fallait écrire deux pretty-printers différents.


Figure 10 L’espion réseau montrant les APDUs échangées entre la carte et le lecteur de carte


Figure 11 Ecran LCD du CAD (APDUs décodées pour l’utilisateur)
1   2   3   4   5   6   7

similaire:

Rapport de stage du dea d’Informatique de Lyon iconRapport de stage 2ème année dut informatique
«Les travaux dont IL est question dans le présent document ont été exécutés durant un stage de formation effectué au Centre international...

Rapport de stage du dea d’Informatique de Lyon iconRésumé Ce rapport concerne mon stage de fin d’étude de Master 2 Informatique...

Rapport de stage du dea d’Informatique de Lyon iconRapport de stage
«Etudes Référentiels Internet» (eri) pour avoir eu la gentillesse de m’accepter en stage

Rapport de stage du dea d’Informatique de Lyon iconRapport de stage

Rapport de stage du dea d’Informatique de Lyon iconRapport de stage

Rapport de stage du dea d’Informatique de Lyon iconRapport de stage

Rapport de stage du dea d’Informatique de Lyon iconRapport de stage

Rapport de stage du dea d’Informatique de Lyon iconRapport de stage

Rapport de stage du dea d’Informatique de Lyon iconRapport de stage

Rapport de stage du dea d’Informatique de Lyon iconRapport de stage








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com