Dans cette section, nous allons pr´esenter la plate-formeJava Card, l’une des derni`eres plates-formes pour carte `a puce, et la plus populaire. Con¸cue par Schlumberger,Java Card a ´et´e repris en 1996 par Sun Microsystems afin de compl´eter son offre de d´eveloppement bas´ee sur la technologie Java au domaine de la carte `a puce. Autour de nombreux industriels, le Java Card Forum [69], qui est `a l’origine des premi`eres sp´ecification de Java Card, a pour but de faire connaˆıtre, d’exploiter et de d´evelopper la plate-formeJava Card.
Cette plate-forme est articul´ee autour du langage Java (plus pr´ecis´ e-ment dans sa version actuelle d’un sous-ensemble deJava), d’une machine virtuelle appel´ee Java Card Virtual Machine (JCVM) [121], d’un environ-nement d’ex´ecution appel´e Java Card Runtime Environment (JCRE) [120], d’un ensemble de librairies accessibles par des Application Programmer In-terface (API)s [119] et d’un v´erificateur de bytecode appel´e ByteCode Ve-rifier (BCV). L’articulation de ces diff´erents composants est donn´e dans la figure 2.1.
La version actuelle du langage Java Card est num´erot´ee 2.2, toutefois, nous d´ecrirons dans la suite la version 2.1.1 de cette plate-forme. Les nou-veaut´es apport´ees par la version 2.2 concernent la mise-`a-jour de certaines APIs et la possibilit´e de retirer des applettes de la cartes, d’appeler des m´ethodes distantes (Remote Method Invocation), d’ajouter un dispositif de gestion de la m´emoire.
2.2.1 Le langage
Le langage Java Card peut se r´esumer `a un sous-ensemble de Java au-quel on aurait retir´e les fonctionnalit´es trop gourmandes en calcul ou en espace m´emoire pour ˆetre exploit´ees sur une carte `a puce. Il s’agit donc d’un langage `a objet, fortement typ´e, sans pointeurs explicites, `a exceptions, `a h´eritage de classe simple et `a h´eritage d’interface multiple. La similitude avec le langage Java est si grande que le code source Java Card est ´ecrit dans le syntaxe Java et compil´e par l’interm´ediaire d’un compilateur Java standard (le code source doit cependant se contenter de n’utiliser que les fonctionnalit´es support´ees par Java Card). Le programme compil´e porte, comme en Java, la d´enomination d’applette (ou applet) et offre une porta-bilit´e comparable aux programmes Java de par l’utilisation d’un ensemble de code octet commun.
Par rapport au langageJava, et pour des raisons d’occupation m´emoire, le langageJava Card n’autorise pas les types de donn´ees dits larges, tels que
Applet 1 Applet
JCVM JCRE n
Processeur
Gestionnaire d’Exceptions Sélecteur
Couche Native APIs Java Card APIs Propriétaires
Mémoire
Pare−feu
Fig. 2.1 –Architecture de la plate-forme Java Card.
les nombres flottants (il n’y a pas en standard d’unit´e de calcul `a virgule flottante sur le microprocesseur des cartes `a puce), les chaˆınes de caract`eres, les tableaux dont les ´el´ements sont eux-mˆemes des tableaux, et la gestion du type des entiers ´etendus (le typeInt) est optionnelle.
Parmi les fonctionnalit´es Java non support´ees se placent le ramasse-miettes (garbage collector, du moins dans la version 2.1.1), les dispositifs de clonage, de finalisation et de s´erialisation des classes, le fonctionnement multi-tˆaches (multi-threading). Le chargement dynamique des classes dispa-raˆıt au profit d’une liaison statique des classes avant leur t´el´echargement sur la carte, il n’est en effet pas possible de t´el´echarger des classes durant l’ex´ e-cution d’un programme. Enfin, le gestionnaire de s´ecurit´eJavaest remplac´e par un mod`ele de s´ecurit´e sp´ecifique `a Java Card et li´e au v´erificateur de code octet.
A titre de comparaison, le code n´` ecessaire `a l’impl´ementation en Java Card des chaˆınes de caract`ere, des nombres flottants et du gestionnaire multi-tˆache prendrait plus de place en m´emoire que l’espace ROM dispo-nible.
Le fichier CAP Les programmesJava Card ne sont pas repr´esent´es comme les programmesJava par un fichierclassfile. Le fichier classfile produit par la compilation du code source subit une transformation (dans le sens de la simplification) par le Java Card CAP File Builder afin d’adapter le format de programmes aux ressources minimalistes disponibles sur la carte `a puce. Le programme au format Converted APplet (CAP) qui r´esulte de cette phase de transformation est directement ex´ecutable, a d´ej`a subi l’´edition de lien et contient simplement les informations n´ecessaires `a son ex´ecution.
2.2.2 La machine virtuelle
La machine virtuelleJava Card est bas´ee sur les notions de piles pour la manipulation des valeurs et de tas pour le stockage des objets. Elle comporte un contexte d’ex´ecution par m´ethode appel´ee.
Tout comme la machine virtuelle Java, elle ex´ecute du code sous forme de codes octet, c’est-`a-dire une repr´esentation par des mn´emoniques d’ins-tructions ´el´ementaires, avec ´eventuellement des op´erandes. Ces codes octet seront ensuite traduits dans le langage du microprocesseur de la carte `a puce par le syst`eme d’exploitation, qui associe `a chaque code octet un compor-tement calculatoire correspondant `a sa s´emantique. Les codes octet dans le langageJava Card sont au nombre de 185.
Une description plus en d´etails de la machine virtuelle Java Card est
donn´ee, avec sa formalisation, dans le chapitre 3.
2.2.3 L’environnement d’exécution
L’environnement d’ex´ecutionJava Card peut ˆetre compar´e au chef d’or-chestre de la carte `a puce. Il est pr´esent d`es le d´ebut de vie de la carte, s´electionne les programmes `a ex´ecuter sur la carte et est amen´e `a prendre le contrˆole de l’ex´ecution par dessus la machine virtuelle, notamment lors d’op´erations en rapport avec la s´ecurit´e. Il assure ´egalement un certain nombre de services aux applettes pr´esentes sur la carte.
La vie d’une appletteJava Card Apr`es un chargement d’une applette sur la carte `a puce, l’environnement d’ex´ecution peut agir sur celle-ci par un ensemble de m´ethodes devant ˆetre impl´ement´e par toute applette. Le JCRE initialise d’abord l’applette apr`es son installation. `A partir de ce moment, il peut s´electionner une applette pour lui signifier qu’elle peut s’ex´ecuter, la d´eselectionner ou lui transmettre un signal APDU (voir plus bas) `a inter-pr´eter.
Les transactions Une transaction est un m´ecanisme permettant de rendre un ensemble d’op´erations atomique. Par exemple, il est important que lors d’une transaction bancaire les donn´ees sur la transaction soient mises `a jour enti`erement, ou bien pas du tout. Le JCRE offre alors un support aux applettes pour restaurer les donn´ees `a leur ´etat avant la transaction lorsque celle-ci n’a pas termin´e normalement (la carte a ´et´e arrach´ee du lecteur par exemple).
Les objets transients Les applettes requi`erent parfois que les donn´ees des objets soient temporaires (transientes), c’est-`a-dire qu’elles ne persistent pas d’une session d’utilisation de la carte `a une autre. Ce type de donn´ees est particuli`erement adapt´e aux calculs interm´ediaires ou manipulant des don-n´ees sensibles (telles que des cl´es cryptographiques) . Bien que Java Card ne supporte pas le mot-cl´e Java transient, le JCRE permet, par l’appel de m´ethodes sp´ecifiques, de d´eclarer certains objets comme transients. Cela interdit alors de les stocker dans la m´emoire persistante (EEPROM) et de restaurer leur valeur durant les phases de transaction d´ecrites pr´ec´ edem-ment.
Les APDUs Le JCRE est aussi responsable des communications avec le ter-minal CAD. Ces communications se font sous forme d’Application Protocol
Data Unit (APDU)s dont la structure est d´efinie par la norme ISO 7816. Il existe deux cat´egories d’Application Protocol Data Unit (APDU)s : les AP-DUs de commande et les APAP-DUs de r´eponse. Les premiers sont envoy´es du lecteur vers la carte et contiennent une commande `a ex´ecuter et les derniers sont envoy´es en r´eponse de la carte vers le lecteur. Le JCRE se charge des tampons d’entr´ee/sortie pour les APDUs, de l’interpr´etation de ceux-ci et de leur ´eventuelle r´epartition aux applettes pr´esentes sur la carte.
Pare-feu Le m´ecanisme de s´ecurit´e deJava Card repose sur un mod`ele de pare-feu (firewall), diff´erent du mod`ele du bac `a sable (sandbox) de Java.
Chaque applette Java Card se voit associer un contexte lors de sa cr´eation,
`
a chaque instant, un seul contexte est actif (celui de l’applette courante), et aucune applette ne peut acc´eder directement `a des champs ou des objets d’un contexte diff´erent. Ce cloisonnement disparaˆıt si l’objet acc`ede `a des variables statiques, `a des tableaux d´eclar´es comme globaux ou bien `a des instances de classe d´eclar´ees comme points d’entr´ee (ceci est contrˆol´e par le JCRE dans les codes octet correspondant `a ces fonctions). Dans les autres cas, les applettes de contexte diff´erent peuvent s’´echanger des objets impl´ e-mentant l’interfaceShareable, dans une proc´edure toujours contrˆol´ee par le JCRE.
2.2.4 La vérification de bytecode
Parmi les dispositifs de s´ecurit´e des plates-formes Java ou Java Card figure la v´erification de code octet. Celle-ci a normalement lieu avant le chargement d’un programme pour la plate-formeJava cependant, en raison des capacit´es limit´ees des processeurs, elle survient dans le cas deJava Card en dehors de la carte `a puce, avant la phase de transformation du programme.
Des recherches r´ecentes ont toutefois rendu possible une v´erification sur la carte mˆeme.
Cette v´erification consiste d’une part en une v´erification structurelle du programme visant `a assurer sa bonne formation et d’autre part en une ana-lyse statique du code du programme. Cette anaana-lyse est la composante la plus complexe de la v´erification car elle doit assurer, entre autres, que les valeurs qui seront manipul´ees lors de l’ex´ecution auront le type attendu et qu’aucun d´ebordement de la m´emoire ne se produira.
Une description plus pr´ecise de cette v´erification, ainsi que l’´etat de l’art dans le domaine et sa formalisation, sera donn´ee dans le chapitre 5.