0% ont trouvé ce document utile (0 vote)
954 vues16 pages

Carte À Puce PDF

Transféré par

btsdsi
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
954 vues16 pages

Carte À Puce PDF

Transféré par

btsdsi
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

Systme embarque

Raliser par : Encadr par :


-EL ABDELLOUI BOUAZZA -Mr. BROURI ADIL

-EL KHADERI MERYEM


Sommaire
Remerciements.1
Introduction gnrale .......2
Chapitre1 : Gnralit sur les systmes embarqus..........3
1- Types de systme embarqu .........3
2-caractristique de systme embarqu ............3
3-Architecture gnrale (composants possibles) ..........4
4-systme dexploitation ..........4
Chapitre2 : carte puce.........5
Introduction...........5
I-Gnralit sur la carte puce..............5
1-dfinition ...........5
2-Composition de la carte puce..........5
3-Principe de la carte puce..........5
4-Description technologique.........6
II- JavaCard.......7
1-definition............7
2-Architecture de javacard........7
3-Les avantages apports par java card.....8
4-Cration dune appelet de javacardion d'une applet Ja9
5-Installation des appelets...................11
6-conclusion........13
Bibliographie..14
Remerciements

Nous remercions en premier lieu Dieu tout puissant de nous avoir accord
la puissance la volont pour achever ce travail.

Par amour et respect nous prsentons nos sincres remerciements notre


respectueux professeur ADIL BROURI d'avoir accept de diriger ce travail
et de nous avoir accompagns toujours avec un mot d'encouragement
positif et optimiste et avec un sujet extrmement important.

1
Introduction gnrale
Un systme embarqu est un systme alliant lectronique et informatique enfoui dans un
environnement fortes contraintes (faible consommation, capacit mmoire rduite, temps
rel, scurit, robustesse).

Les systmes embarqus sont omniprsents et jouent un trs grand rle dans le
quotidien : smartphone, satellite, carte bancaire, voiture, TGV, avion, camra, drone, GPS,
console multimdia

Dans un contexte mondial de forte comptitivit, les systmes embarqus


reprsentent un facteur de diffrenciation majeur pour un trs grand nombre de secteurs
dactivits : lnergie, les transports, la dfense, laronautique, la sant, le multimdia, les
tlcoms, les cartes puce, la production, la logistique et llectronique grand public. La
tendance est soutenue avec une croissance du march de lembarqu de +6 +12% par an
dans le monde.

Les comptences et expertises ncessaires sur les systmes embarqus sont nombreuses,
varies et peu rpandues. Lassimilation des notions de scurit des systmes (robustesse, intgrit,
confidentialit) ainsi que la virtualisation logicielle et matrielle permettant de faire cohabiter sur la
mme puce des applications critiques et non-critiques constituent de vritables atouts diffrenciants
trs recherchs par les entreprises.

Les enseignements de la majeure Systmes embarqus aronautique et automobile


contribuent pleinement dynamiser linnovation dans les domaines des transports
intelligents, de laide la personne, de la mobilit durable, de lhospitalisation domicile, ou
bien de la matrise de la consommation.

2
Chapitre1 : Gnralit sur les systmes embarqus
1- Types de systme embarqu
On utilise un systme embarque dans le domaine traditionnel tel que l'industrie
arospatial, automobile, lectronique, tlcommunication, et portableetc. Mais
cela fournit un peu d'informations ce qui concerne comment un systme serait
conu. Il est donc difficile de classifier prcisment le systme embarqu. Pour bien
classifier, on prsente quelques critres que peuvent fournir l'information actuelle
sur la structure du systme : la taille, contrainte de temps, capacit du rseau, et
degr de linteraction dutilisateurs

2-caractristique de systme embarqu


Faible cot
Un assez grand nombre de produits dembarqu sont sur les marchs o l'utilisateur ne
veut pas payer le supplmentaire pour la performance ou fonctionnalit de plus, Les
concepteurs ont donc d concevoir avec des rapports optimaux entre le prix et la
performance Le rsultat de ceci est que les ressources disponibles sont minimaux
possibles. Cest pour quoi un systme embarqu a rarement plus de quelques Mga
octets de mmoire disponible.
Faible consommation
La minimisation de la consommation est essentielle pour les systmes autonomes
afin de maximiser l'autonomie des batteries. Une consommation excessive augmente le
prix de revient du systme embarqu car il faut alors des batteries de forte capacit.
Faible encombrement et faible poids
Ils doivent cohabiter sur une faible surface lectronique analogique, lectronique
numrique. Notamment, cest trs important pour les applications portables o lon
doit minimiser la taille et les poids.
Fonctionnement en Temps Rel (Rponse de temps)
Les applications embarques, comme des applications de systme de contrle, sont
vnement conduit et doivent rpondre rapidement ces vnements.
Peut-tre, Un systme embarque a besoin des oprations de calcul doivent tre
faites en rponse un vnement extrieur. Cest une caractristique pour quelques
domaines spciaux.
Environnement

3
Ils sont soumis de nombreuses contraintes dictes par l'environnement telles que la
temprature, lhumidit, les vibrations, les chocs, les variations dalimentation, les
interfrences RF, la corrosion, l'eau, le feu, les radiationsetc.

3-Architecture gnrale (composants possibles)


Comme vous savez l'architecture de systme normal, un ordinateur se compose de
trois couches: Application, Systme d'exploitation, et Matriel. De mme, un systme
embarque dispose de 3 couches. Chaque couche a la mme fonctionnalit qu'un
systme normal. Mais, Il y a des diffrences de sous composants du systme. Deux
premires couches, Il s'agit du logiciel. Cependant, Ce n'est pas un systme qui
contient tous les composants comme le systme complet. Car le but de conception
est de servir quelques tches spcifiques, et de concentrer un unique travail. Le
systme d'exploitation est une couche logicielle sur laquelle on va se placer
l'ensemble des applications lances par les utilisateurs.

4-systme dexploitation :
Un systme d'exploitation est un programme qui gre le matriel. Il sert d'intermdiaire entre
l'application logiciel et le matriel informatique (priphriques, capteurs, moteurs...)1. La diversit
des systmes d'exploitation disponibles offre des constructions et proprits particulires qui
permettent de rpondre des objectifs trs varis2 . part pour les tches trs simples
(l'ordonnancement, la commutation de tches, entres/sorties, ...), une application embarqu
besoin d'un systme d'exploitation adapt rpondant au contraintes pour tre install sur le
systme embarqu (espace mmoire par exemple). Le systme d'exploitation doit aussi disposer
des fonctionnalits requises pour la tche qu'il aura excuter. Les systmes d'exploitation pour
PC sont conus avec une interface homme-machine particulire (cran-clavier-souris). Dans le
cadre d'un systme d'exploitation embarqu, l'interface homme-machine pour pouvoir interagir
avec peut tre spcifique (clavier digicode, crans de smartphones...), voire inexistante (cartes
de crdits, cartes Sim, ..), auquel cas on utilise une machine intermdiaire (bornes, tlphones4).
tant la plupart du temps hors de porte humaine, un systme d'exploitation embarqu doit avoir
un niveau de robustesse bien au-dessus des exigences d'un systme d'exploitation de bureau5.
Les systmes d'exploitation embarqus ncessitent une trs grande fiabilit, ainsi que de bonnes
performances.[1]

4
chapitre2 : carte puce

Introduction
La carte puce est aujourd'hui un support trs rpandu pour stocker des informations. Ces
exemples les plus courants sont les cartes bancaires, les cartes tlphoniques et les cartes SIM
contenues dans les GSM. Il s'agit en fait d'une simple carte de plastique dans laquelle est
intgre une puce lectronique.
Il en existe diffrents types dont la smartcard et plus particulirement la javacard.
Toutes les cartes puces possdent des ressources trs limites disponibles pour lexcution
dapplications. Aujourdhui, le moyen le plus sr pour assurer un niveau de scurit satisfaisant
reste la carte puce.Cependant, le dveloppement dapplications pour carte puce a toujours
t difficile et rserv des experts.Il a donc fallut dvelopper un langage qui soit la fois fiable,
robuste, peu gourmand en ressources et bien sr simple. Cest en 1996 que Sun Microsystems
Inc propose une solution aprs des essais mens par Schlumberger : le JavaCard. est un
systme de programmation de cartes puces bas sur une version allge du langage Java.

I-Gnralit sur la carte puce


1-dfinition
Une carte puce est un rectangle en plastique d'une paisseur d'1 mm qui porte un intgr
capable de mmoriser de faon scurise une srie d'informations. Ce circuit intgr s'appelle
une puce.

Invente en 1974-03-25 par Roland Moreno

2-Composition de la carte puce


Elle rassemble un microprocesseur (8 bits et 4 MHz), une mmoire morte ou ROM, une mmoire
de stockage et une mmoire vive d'une taille variable selon la somme et la complexit des
informations qu'elle va contenir. Le premier brevet concernant un tel dispositif a t dpos
par Roland Morenoen 1974.

3-Principe de la carte puce


La carte puce, mono ou multiapplicative, sert d'instrument d'identification personnelle. Badge
d'entre, carte vitale, ou carte SIM, elle acte une identit ou une appartenance. Utilise sur des
cartes bancaires, elle est preuve ou source de paiement. Sa lecture par des quipements
spcialiss est ralise avec ou sans contact avec la puce. Les cls USB font partie de cette
famille de produits : ce sont des objets portatifs dots d'une mmoire. Nanmoins, la cl USB ne
possde pas de circuit protgeant l'accs la mmoire, la diffrence d'une carte puce dont la
fonction principale est la protection des donnes. Celle-ci est assure grce un code
confidentiel dit Pin pour Personal Identification Number.

5
Avant d'tre mise en circulation, la carte puce est encode afin d'inscrire dans la puce les
informations personnelles de l'utilisateur. Elle comporte aussi des donnes imprimes sur ces
deux faces : nom de l'organisme, photo ou identit du porteur de la carte. Une de ces faces
comporte galement un cryptogramme. Ces trois chiffres sont un degr de scurit
supplmentaire pour identifier le porteur de carte dans les transactions en ligne.

4-Description technologique
Une carte puce ou smart card est constitue d'un CPU, de mmoire RAM (ses donnes seront
perdues quand celle-ci sera retire du lecteur), d'une mmoire ROM (o est pr-enregistr en
usine le systme d'exploitation), et d'une EEPROM (qui conserve les donnes qui y sont inscrites
mme aprs que la carte n'est plus lectriquement alimente). En cela, il s'agit
d'un ordinateur classique, rduit la taille d'une puce.
Elle permet la communication, le stockage et l'excution de code avec un haut degr de scurit.
Les circuits logiques qui composent la puce supervisent la transmission des donnes via
interface srie pour faire communiquer la carte vers l'extrieur et notamment un lecteur. Comme
pour n'importe quel autre systme d'exploitation, comme le DOS, les fonctions et les instructions
d'un COS ne sont pas dpendantes d'une application en particulier mais se veulent tre
gnriques pour un ensemble de besoins communs toute application dsirant fonctionner dans
un environnement de carte puce. Et tout comme le DOS, ce type d'OS n'est pas conu pour
fournir d'interface graphique.

Environnement matriel

i-dessus une illustration simpliste d'une carte puce. Le schma montre qu'elle est compose :
D'une partie logique avec un CPU et un NPU (spcialis pour la partie rseau) mais plus
gnralement on pourrait employer le terme de MPU ou (en) Multi-core processor.
Cette partie logique est le sige de l'excution du code applicatif que ce soit l'OS comme
les applicatifs installs dans la carte.
D'une partie mmoire qui permet de stocker l'information volatile (mmoire RAM) durant
l'excution du code. De la EEPROM qui stocke soit des applicatifs ou des donnes qui

6
peuvent tre modifies pendant le fonctionnement de la carte mais qui ne doivent pas
tre perdus aprs la perte d'alimentation. Et la mmoire ROM qui stockera le code,
notamment l'OS, ou les donnes figs en usine durant la conception de la puce.
Une partie communication qui permet la communication avec l'extrieur et notamment le
lecteur de carte puce. Le schma prsent ci-dessus montre un seul type de
communication extrieur avec un contacteur physique, mais d'autres types de
communication1 sont possibles comme les ondes radios mais aussi les ondes
lumineuses.
Le systme d'exploitation est ainsi localis essentiellement au niveau de la mmoire ROM, sous
une forme non altrable, et pour ventuellement certaines de ses fonctions modifiables dans
l'EEPROM. Il offre les fonctions pour contrler les diffrents lments de la carte et la
communication avec le lecteur.[2]

II- JavaCard
1-definition
Toutes les cartes puces sont caractrises par des ressources trs limites disponibles pour
l'excution d'applications. En outre, l'explosion des rseaux de tlcommunication et des
transactions lectroniques ont augment le besoin en applications sans ngliger la scurit.
Aujourd'hui, le moyen le plus sr pour assurer un niveau de scurit satisfaisant reste la carte
puce. Cependant, le dveloppement d'applications pour carte puce a toujours t difficile et
rserv des experts.
Il a donc fallut dvelopper un langage qui soit la fois fiable, robuste, peu gourmand en
ressources et bien sr simple. C'est en 1996 que Sun Microsystems Inc propose une solution
aprs des essais mens par Schlumberger : le JavaCard. est un systme de programmation de
cartes puces bas sur le langage Java et la Java Virtual Machine. Java Card est une version
pure du langage Java s'adaptant aux environnements rduits des cartes puces.
L'environnement minimum ncessaire au fonctionnement de l'API Java Card est un processeur
300 KIP, 12 KO ROM,4 KO EEPROM, et 512 Octets de RAM. Un certain nombre de
composants, par exemple les tableaux multidimensionnels, les Threads et le garbage collector ...,
ont t enlevs.

2-Architecture de javacard

7
L'architecture de la JavaCard est compose de plusieurs couches. les Native Methods
contiennent un ensemble de fonctions bas niveau qui permettent au Java Card Runtime
Environnent (JCRE) de grer les ressources physiques de la carte telles que les entres-sorties,
la gestion de la mmoire ou le coprocesseur cryptographique. Ces mthodes sont compiles en
code excutable ddi au processeur de la carte.L' interpreter est le coeur de l'architecture
JavaCard sur la carte.
C'est le moteur d'excution des Applets ou Cardlets. Il excute les programmes en convertissant
le code pr-compil en appel aux mthodes natives. Il fournit une couche d'abstraction entre les
ralits physiques de chaque carte et le code fourni par le Converter (compilateur JavaCard),
ce qui rend les programmes JavaCard compltement indpendant de l'environnement utilis,
condition d'utiliser une carte de type JavaCard. Les Standard Class Libraries ou encore le
Javacard Framework est un ensemble d'API. L'API contient l'ensemble de classes qui sont les
outils de bases pour crer une Applet.

Cet ensemble (Native Methods, Interpreter et les Standard Class Libraries) est appel JCRE. Il
est contenu dans le masque des JavaCard et est donc inamovible.

3-Les avantages apports par java card


Les avantages apports par Ja.
Voici les principaux avantages du langage qui justifie le choix de ce standard en ce qui concerne
la programmation des cartes puces.
Langage de haut niveau orient objets :
Il possde donc tous les avantages de ce type de langage (encapsulation des donnes,
hritage...).Il permet une structuration plus naturelle du code et donc plus comprhensible. Le
concept d'hritage permet la rutilisation du code.La cration de librairies est simplifies : les
packages. Auparavant, le dveloppement de programmation carte tait ralis en assembleur ou
en C. Cela tait moins souple et plus technique. La mise au point de programmes sera plus
rapide et les temps de dveloppement seront sensiblement rduits.

Ce langage accrot la scurit : gestion stricte de la mmoire, pas d'arithmtique de pointeur,


access scope (vrification des accs) des membres d'un objet, langage fortement typ.
Write Once, Run Anywhere :
Le code d'un programme JavaCard est universel au sens o il est excutable sur n'importe quelle
machine virtuelle JavaCard. Le JavaCard n'introduit rien de spcifique et respecte la norme ISO-
7816 dans le dialogue avec un lecteur de carte.
Plate-forme multi applicative :
JavaCard possde un modle de scurit qui permet plusieurs applications de coexister en
scurit sur la mme carte. Chaque applet possde son espace de mmoire propre (sandbox).
Une carte peut contenir une application bancaire, un accs pour tlvision satellite, un carnet de
sant...
Partage de donnes entre applications :
Les diffrentes applications prsentes sur une carte peuvent accder des donnes d'une autre
application si le programme a t envisag via le firewall. Seul le JCRE peut accder toutes les
donnes. Une applet peut contenir les identifiants de scurit sociale qui peuvent tre utiles pour
une applet mis par la mutuelle du dtenteur.
Scurit des donnes :
Comme nous l'avons vu, le JCRE gre strictement la mmoire de chaque Applet de faon
tanche. L'API JavaCard intgre les outils de base pour des applications d'authentification et de

8
signature. Les donnes sensibles sont dtenues par le JCRE : certificat, code PIN... Nul ne peut
les lire directement.
Souplesse :
Le fait que les Applets soient charges dans une EEPROM, permet de les mettre jour en
effaant l'ancienne version et en chargeant la nouvelle. Cette volutivit rend une carte
pleinement rutilisable, alors qu'auparavant les applications taient directement inclues dans le
masque et donc non modifiables. Les modifications et chargement d'Applet font appel des
mcanismes scuriss par le Card Manager .
4-Cration dune appelet de javacardion d'une applet Ja
Voici un schma reprsentant les diffrentes tapes pour crer une applet et l'excuter.

Schma d'une applet :


Pour dvelopper une application JavaCard, il faut tout d'abord importer ses bibliothques. Les
bibliothques sous Java s'appellent des packages. Le programmeur a la charge de dclarer les
bibliothques aux quelles il souhaite accder pour son programme. La bibliothque de base pour
l'API JavaCard est le package javacard.Framework. Ce Package contient les classes
indispensables la ralisation telles que :
APDU (Application Protocol Data Unit), qui est le format de communication entre la carte
et le monde extrieur.
Applet, c'est de cette classe que doivent tendre toutes les Applets.
AID (Application Identifier), c'est un identifiant qui est associ une Applet.
Les Exceptions, qui permettent d'envoyer des Status Word d'erreur.

L'interface ISO-7816, qui contient les Status Word de base et les positions des lments d'une
APDU. Il existe aussi un package scurit (javacard.security) qui contient les fonctions de
chiffrement usuelles (MD5, SHA, DES ...) et de signature. Lorsque le JCRE reoit une APDU de
slection, il cherche activer une applet correspondante. Une applet tant une instance de la
classe javacard.Framework.Applet, toute applet devra
tendre de cette classe. Ce mcanisme d'extension permet aussi d'utiliser les mthodes de la
classe Applet ou bien de les surcharger. La surcharge d'une mthode consiste rcrire le code
de celle-ci, afin de modifier son comportement. Les mthodes implmenter obligatoirement sont
pour ne pas avoir le comportement par dfaut de la classe Applet :
install()
process()
select()

9
deselect()
La fonction install() est appele par le JCRE pour crer et enregistrer (par la mthode register())
une instance d'applet auprs de celui-ci.
Les AID servent d'identificateur pour le JCRE. Chaque AID d'une applet prsent sur la carte doit
tre unique et correspondre la norme ISO-7816.
Une applet est slectionnable seulement aprs avoir t enregistre par le JCRE.
La fonction process() est la fonction principale de l'applet, c'est celle qui va collecter toutes les
APDU entrantes. Elle envoie ces APDU vers les mthodes qui correspondent l'octet
d'instruction (INS). Le principal travail d'un programmeur se situe dans la gestion du dialogue
entre la carte et le lecteur. C'est dans cette mthode qu'il doit tre gr.
La fonction select() est appele par le JCRE pour rendre active et initialiser une instance d'applet.
Comme dfini dans la norme ISO-7816, toute Applet doit rester slectionnable. Il ne faut pas
bloquer la slection.
La fonction deselect() est appele par le JCRE pour dsactiver l'applet en-cours et faire les
possibles oprations ncessaires avant la dslection (Ex : Clture d'une transaction).
La Compilation:
La compilation des programmes JavaCard commence par l'utilisation d'un compilateur Java du
JDK standard. Il n'y pas de compilation pour la plate-forme JavaCard mais une traduction du
bytecode vers un autre format ddi JavaCard.

La compilation et la conversion se font en deux tapes. La compilation est laisse la charge au


compilateur java classique, seule la conversion est prise en charge par les outils du JDK
JavaCard.
Les classes de l'API JavaCard doivent tre importes et dfinies dans le ClassPath du
compilateur Pour pouvoir faire l'dition des liens. Le compilateur javac ne tient pas en compte le
fait que JavaCard soit un sous ensemble de Java et ne renvoie pas de message d'erreurs lors de
la compilation.
La vrification est faite lors de la conversion. Lors de la conversion, voici les taches accomplies
Par le converter :
Vrifier que les images charges des classes Java sont correctes.
Vrifier la conformit par rapport au langage JavaCard (vu ci-dessus).
Initialiser les variables statiques.
Rsoudre les rfrences symboliques des classes, mthodes et champs vers une forme
plus compacte et mieux adapte la carte.
Optimiser le bytecode en tirant avantage obtenu au chargement et l'dition des liens.
Allouer l'espace ncessaire et crer les structures de donnes pour reprsenter les
classes auprs de la machine virtuelle Le fichier issu de la conversion (bytecode
JavaCard) est appel cap file .
Machine Virtuelle
Une fois le code compil, on se retrouve avec un fichier .class. Une tape supplmentaire est
ncessaire pour que l'applet passe du monde extrieur vers la carte puce.
La machine virtuelle JavaCard est implmente en 2 parties : la off-card et la on-card. La
partie Off-card est appele Java Card Converter. Elle permet le chargement des classes et de la
rsolution des rfrences. Elle vrifie et convertit le byte-code. La partie On-card qui a pour tche
d'interprter le byte-code comme nous l'avons vu prcdemment.
Aprs un reset, le JCRE entre dans une boucle d'attente. L'applet ne peut pas communiquer
directement avec le monde extrieur. Tout ce dialogue passe par le JCRE. De plus, le JCRE peut
interrompre l'excution d'une applet lors du lancement d'une exception. Les applets ne lancent
pas les exceptions mais demandent au JCRE de le faire pour elles. On peut parler d'une
prminence du JCRE sur les applets.

Exemple simple d'applet JavaCard

10
Voici un exemple simple d'applet java. Dans un premier temps l'instanciation de la class l'applet
s'enregistre auprs du JCRE grce la mthode register(). Ensuite elle se contentera de
rpondre au APDU, en renvoyant ceux-ci.
public class HelloWorld extends Applet
{
private byte[] echoBytes;
private static final short LENGTH_ECHO_BYTES = 256;
/**
* Only this class's install method should create the applet object.
*/
protected HelloWorld()
{
echoBytes = new byte[LENGTH_ECHO_BYTES];
register();
}
/**
* Installs this applet.
* @param bArray the array containing installation parameters
* @param bOffset the starting offset in bArray
* @param bLength the length in bytes of the parameter data in bArray
*/
public static void install(byte[] bArray, short bOffset, byte bLength)
{
new HelloWorld();
}
/**
* Processes an incoming APDU.
* @see APDU
* @param apdu the incoming APDU
* @exception ISOException with the response bytes per ISO 7816-4
*/
public void process(APDU apdu)
{
byte buffer[] = apdu.getBuffer();
short bytesRead = apdu.setIncomingAndReceive();
short echoOffset = (short)0;
while ( bytesRead > 0 ) {
Util.arrayCopyNonAtomic(buffer, ISO7816.OFFSET_CDATA,
echoBytes, echoOffset, bytesRead);
echoOffset += bytesRead;
bytesRead = apdu.receiveBytes(ISO7816.OFFSET_CDATA);
}
apdu.setOutgoing();
apdu.setOutgoingLength( (short) (echoOffset + 5) );
// echo header
apdu.sendBytes( (short)0, (short) 5);
// echo data
apdu.sendBytesLong( echoBytes, (short) 0, echoOffset );
}
}

5-Installation des appelets


Installation des applets
Une JavaCard lorigine contient le JCRE et tout le systme du constructeur de la carte. Le
JCRE est crit dans la ROM de la carte : cest le masque de la carte. Il est donc inviolable. Le
code des applets est stock sur la carte gnralement en EEPROM.
Linstallation

11
Linstallation dune applet se fait alors que le JCRE tourne. Cela se passe en deux phases.
1. chargement du code de lapplet (cap file) sur la carte
2. cration dune instance de lapplet
Pour installer lapplet, l'installeur prend le fichier .cap et tlcharge le contenu du fichier sur la
carte. L'installeur crit le contenu dans lEEPROM et fait les liens entre les classes dans le fichier
.cap et les classes rsidant sur la carte. Il cre et initialise les donnes qui seront utilises par le
JCRE en interne pour se servir de lapplet. Si lapplet ncessite plusieurs package, chaque fichier
.cap correspondant un package sera charg sur la carte. Ldition de liens se fait statiquement
linstallation et donc pour faire cette dition on a besoin de toutes les dpendances .

Cot scurit: Lapplet Firewall

Les applications JavaCard peuvent provenir de fabricants diffrents, et ne doivent pas pouvoir
communiquer entre elles. Ces applications sont appeles des applets identifis uniquement par
leur AID (Application Identifier) isoles entre elles par un applet firewall.
Celui ci partage le systme d'objet javacard en espaces d'objets protgs et spars appels
contextes. Le firewall est la barrire entre les contextes. Quand un applet est instanci, la JCRE
lui assigne un contexte mais aussi un groupe de contexte dans lequel peut se trouver plusieurs
applets.
Les applets dans un mme groupe peuvent se voir. Le firewall isole galement le contexte du
JCRE
RPC et systmes objets rpartis

12
6-conclusion
Les systmes enfouis, embarqus et mobiles tant des systmes informatiques invisibles, ils
partagent bien videmment un grand nombre de caractristiques communes avec les systmes
informatiques classiques. Pour les produits bas de gamme, on retrouve beaucoup des
caractristiques des premiers systmes base de microprocesseurs des annes 1980. Pour les
systmes multiprocesseurs sur puce haut de gamme, il y a beaucoup de caractristiques
communes avec les multicurs ou clusters de multicurs sur les aspects conception matrielle,
logicielle et systme, les problmes de conception et de validation. La spcificit des systmes
embarqus est lensemble des contraintes particulires que nous avons passes en revue : cot,
encombrement, nergie, fiabilit, etc. qui particularise les problmes de conception et de
ralisation. Parmi les systmes embarqus, les systmes critiques ont de plus en plus
dimportance dans certains domaines, comme on peut le voir avec laugmentation continue des
systmes lectroniques dans lautomobile et les possibilits quils permettent (voiture sans
chauffeur).
Ces systmes deviennent de plus en plus rpandus dans la vie courante, des objets de...

13
Bibliographie

[1]:http://zeineb-medimagh.developpez.com/tutoriels/javacard/introduction-
javacard/#LI-A

[2]:https://fr.wikipedia.org/wiki/Syst%C3%A8me_d'exploitation_pour_carte_%C3
%A0_puce

14

Vous aimerez peut-être aussi