Brevet FR2839792A1 — publié le 20031121

cassette audio. 1 2839792 Le domaine de ['invention est celui des cartes et autres objets electroniques portatifs portent une puce dans laquelle vent charges, par exemple sous le langage Java, des programmes d'application dits applets.: Un programme d'application est avantageusement ecrit en un langage, notamment Java, qui est un langage de haut niveau. Afin de le rendre accessible au microprocesseur d'une puce, le programme est compile en un langage de plus teas niveau formant un fichier "class". Apres compilation, ['application est interpretee a ['aide d'une machine virtuelle quton peut considerer comme un preprocesseur, implante par exemple dans une memoire ROM, qui a l'avantage de pouvoir fournir les memes fonctions queues que s oient le s puces et d'autori s er l'ecriture dans le langage de haut niveau qu' est par exemple Java. En fait, comme on dispose dans la carte d'une capacite memoire restreinte, avant chargement de ['application dans la carte, on procede a un pretraitement dioptimi sation du fi chier class pour l 'organi ser et en reduire la tail le et obtenir ainsi un fichier dit fichier CAP. Un fichier CAP, relatif a une application determinee, contient une pluralite de composants dont un composant des methodes. Le composant des methodes comporte des suites organisees de bytecodes et d'autres donnees notamment sur les methodes et ['application, essentiellement stockees dans une memoire E2PROM de la puce. L'invention a un rapport avec des attaques agressives par manipulation de codes intermediaires dits bytecodes des fichiers CAP, qui vont maintenant etre presentes. Comme exemple d'application, on peut considerer ['application de porte- monnaie electronique. Les methodes I1 stagit des diverges fonctions mises en aeuvre par une application. Pour poursuivre le meme exemple, ['application de portemonnaie implique les fonctions d'incrementation, de credit, de debit, de cumul, etc. 2 2839792 Les bytecodes Dans ledomaine, ici particulierement considere, de la programmation Fava, et au niveau d'un fichier CAP, on peut dire que les instructions s'expriment sous un certain langage (bytecode, ou code de bytes, appele autrement code intermediaire, designant aussi bien ce langage qu'un groupe d/instructions) et que ces instructions vent associ ees a de s donnees d' app li cation et de metho de A, B. C, D, avec les bytecodes a, b, c, d respectivement des quatre methodes associees aux champs de donnees a', b', c', d', suivant un champ d'en-tete E, comprenant notamment un drapeau de composant t et des bytes s de longueur (figure 1). Pour fixer les idees, a la methode de "crediter", et touj ours pour reprendre le meme exemple, il faut naturellement associer ['application de porte-monnaie, le nombre de parametres de la methode (egalement appeles arguments) a utiliser la taille de pile necessaire, etc. Ce vent ces types de donnees qui vent associees en a'-d' aux bytecodes a-d. A l'interieur d'un code intermediaire (a-b), une inskuction peut etre directement associee a zero, un ou plusieurs parametres. Considerons par exemple ['instruction 8C (invokespecial) a laquelle le parametre 00 00 est associe. Les octets 00 00 ne representent pas le parametre mais son adresse relative, autrement dit sa reference dans le fichier CAP, adresse qui est resolue au moment du chargement de l'applet dans la puce, pour eviter d'avoir a le faire au moment de ['execution, ce qui prendrait trop de temps, en substituant a l'adresse relative l'adresse reelle dans la memoire de la puce. La resolution s'effectue par un editeur de lien qui "lie" le parametre de ['instruction a une adresse effective dans la memoire de la puce; c'est ce qu'on appelle la liaison (linkage). Mais un instrument utile est associe au composant des methodes, tel que celui de la figure 1, pour aider l'editeur de lien dans la resolution des adresses. Au composant des methodes est done associe un "composant de la localisation des references" (figure 1), qui est un des composants du fcher CAP (composant RLC, remote location component) qui contient les decalages entre references, ou adresses relatives, a resoudre du composant des methodes. 3 2839792 Le premier octet (09) du composant RLC est son drapeau, les deux octets suivant (00 08) concernent la longueur du composant. Les octets qui suivent (00 00) concernent la dimension de la table T1 d'aide a la localisation des parametres definis sur un seul octet - il n'y en a pas dans le composant de la figure 1 - pois (00 04) la dimension de la table T2 d'aide a la localisation des parametres definis sur deux octets - il y en a quatre dans le composant de la figure 1. Le composant RLC de la figure 2 ne comporte done qutune seule table T2 dont on va maintenant expliquer comment elle doit etre lue, apres avoir souligne que les tables contiennent done les informations necessaires a la resolution des parametres. Le premier octet, de rang 1, du champ a' du champ global de la premiere methode (a', a) du composant de la figure 1, est 01. Le rang, du premier octet 00 de l'adresse relative, a deux octets, du parametre associe au premier code 8C du bytecode a, est le rang S. Le premier octet 00, du parametre associe au code suivant 7C du composant, se trouve 6 rangs apres. C'est le saut qu'il faut effectuer pour se positionner sur le parametre suivant a resoudre. Le premier octet 00, du parametre associe au code suivant 8F, se trouve 6 rangs apres. Enfin, le premier octet 00, du parametre associe au code suivant 8C, se trouve 3 rangs apres (02, 8C, 00). On peut done dire que le composant RLC est un instrument d'aide a la liaison qui facilite la determination des adresses a resoudre du composant des methodes. En d'autres termes, ['octet 05 de la table T2 implique qu'il y a une adresse a resoudre dans le composant des methodes. Au cinquieme octet du champ de la premiere methode, se trouve la padre 00 00 qui est l'adresse relative a transformer en adresse reelle, dans la memoire de la puce, effective pour ltexecution, ou se trouve reellement le parametre d'adresse relative 00 00 dans le fichier CAP. Le composant RLC est calcule hors de ['objet electronique portatif et, en tent qu'element du fichier CAP, charge dans la puce de ['objet avec le composant des methodes. Le probleme a l'origine de ['invention, deja evoque plus haut, est le probleme des attaques de bytecodes qui steffectuent generalement par une non resolution de certaines adresses de parametres. Ces attaques consistent souvent a modifier le composant RLC du fichier CAP. L' invention de la presente demande vise a eviter une telle fraude qui permettrait finalement de contourner les tierces applications. On notera que la verification des bytecodes d'applets, au demeurant externe a la carte, n'est d'aucun secours en la matiere puisqutune interruption de la chane de surete du chargement d'une apples permet precisement de charger une apples pirate et d'introduire des codes indesirables. Ainsi, ['invention de la presente demande concerne un procede de chargement d'une apples, dans des moyens memoires d'une puce d'un objet electronique portatif, comprenant un fichier optimise comportant un composant des methodes et un composant de localisation des references (RLC) avec au moins une table (T) d'informations de resolution d'adresses, procede dans lequel on a resolu les adresses relatives dans le fichier optimise des parametres associes aux instructions des codes intermediaires du composant des methodes a ['aide desdites informations du composant RLC, procede caracterise par le fait qu'on assure l'integrite desdites informations de resolution d'adresses du composant RLC avant de resoudre dans la puce les adresses relatives du fichier optimise, en recalculant dans la carte, apres chargement, le sdites informations de resolution d' adresses du composant RLC avant de resoudre les adresses relatives. Grace a ['invention, on est done certain de resoudre correctement tous les parametres. Une manipulation de bytecodes et du composant de localisation de s references externe a la carte n'est absolument plus prej udici able, toutes l es references a resoudre vent bien resolues. On remarquera que la mise en ceuvre de ['invention n'est absolument pas prejudiciable a ['execution de l'applet dont la duree n'est pas modifiee. Ainsi, on s'affranchit ici aussi de toute manipulation externe du composant RLC du fichier optimise qu'on n'utilise plus. Dans une mise en aeuvre encore differente, on resout lesdites adresses relatives par leur remplacement en adresse effective, a la volee, ctest-adire au fur et a mesure des parametres (adresses relatives) trouves en parcourant le bytecode. 2839792 L' invention sera mieux comprise a ['aide de la description suivant presentee c i-de s sous, en reference au dess in annexe, sur le quel: - la figure 1 est une representation d'un composant des methodes; - la figure 2 est une representation d'un composant de localisation de references; - la figure 3 est un schema d'une puce de carte Java; - la figure 4 est un schema illustrant le chargement d'un fichier dans la carte et - la figure 5 est un organigramme de mise en ccuvre du procede de ['invention. En reference a la figure 3, le chargement d'un programme d'application dans lS une puce 10 de carte a puce (Java), pour considerer le domaine prefere de ['invention, s'effectue a partir d'un terminal (ordinateur personnel) 20 a ['aide d'un protocole particulier dit APDU (application protocole date unit). La puce l 0 de la carte est organisee autour d'un microprocesseur 1 relic par un bus 2 a des memoires RAM 3, ROM 4 et E2PROM 5. Incidemment, c'est dans la memoire ROM que vent disposes la machine virtuelle 6 et l'editeur de lien 8. L'entree dans la puce l0 s'effectue par l'intermediaire d'une interface d'entree 7, de dialogue selon le protocole APDU, avec l'environnement d'execution javacard dit JCRE (Java card run time environment). On rappellera encore ici, en reference a la figure 4, qu'un fichier CAP 30 comporte, notamment, un composant des methodes 31 constitue d'une pluralite de codes intermediaires 32 associes a des parametres (33), en fait, leurs references ou adresses relatives 34 dans une autre partie 35 du fichier 30. Apres chargement 36, ici dans la memoire 5 de la carte 10, chaque code intermediaire 32, grace a l'editeur de lien 8, est associe avec l'adresse reelle 37 du parametre (33) dans la memoire. Les tirets sur la figure 4 signifient que les elements representes appartiennent a des pluralites de tels elements. Selon ['invention, le fichier CAP 30, avec son composant des methodes 31 et ses codes intermediaires 32 avec leurs parametres associes 33, est charge dans la puce 10, ainsi d'ailleurs que le composant RLC 38, qui ne va pas etre utilise. Au lieu d'utiliser le composant de localisation des references pour resoudre toutes les references du composant des methodes, on utilise le procede de calcul decrit dans l'organigramme de la figure 5. Ce calcul des tables s'effectue a ['aide d'un programme qui est ici extrait du convertisseur de fichier (conversion du fichier class en fichier CAP), en ayant prealablement charge dans la carte, par exemple lors de sa creation, une table composant T contenant pour chaque instruction de bytecode javacard existante specifiee dans la norme Javacard les informations necessaires a la resolution des parametres de ce bytecode ainsi que les informations necessaires pour passer a l'analyse diune instruction de bytecode suivante. En reference a ltorganigramme de la figure 5, et en considerant de fa,con generale une table Tj et un bytecode B du composant des methodes, les etapes suivantes vent successivement mises en ceuvre par l'editeur de lien (8) avec le microprocesseur (1). L'editeur de lien 8 se positionne (1) sur le premier bytecode dont les parametres vent a resoudre. L'editeur va analyser la table T; pour associer les parametres aux instructions du bytecode pointe (2). En d'autres termes, il "recherche" ce bytecode dans la table Tj. Si un premier parametre (adresse relative) a un octet doit etre resolu pour ce bytecode (3), l'editeur saute a ce "parametre" dans le composant des methodes, en lisant la valeur du saut dans la table (Tj), lit le "parametre" et le remplace (4) par la valeur effective pour ['execution. Si non (5), l'editeur saute tout de suite aux eventuels parametres a deux octets. Si un parametre suivant a un octet doit encore etre resolu, l'editeur recommence (6) et saute a ce parametre dans le composant des methodes et ainsi de suite. Si non (7), ltediteur saute aux eventuels parametres a deux octets. Si un premier parametre (adresse relative) a deux octets doit etre resolu pour ce meme bytecode (8), l'editeur saute a ce parametre dans le composant des methodes, en lisant la valeur du saut dans la table (Tj), lit le "parametre" et le remplace (9) par la valeur effective pour ['execution. 7 2839792 Si non (10), et a supposer qu'il n'y ait pas de parametres a plus de deux octets, l'editeur saute (11) au bytecode suivant eventuel en lisant la valeur du saut dans la table.: Si un parametre suivant a deux octets doit encore etre resolu, l'editeur recommence (12) et saute a ce parametre dans le composant des methodes et ainsi de suite. Si non (13), et a supposer toujours qu'il n'y ait pas de parametres a plus de deux octets, liediteur saute (11) au bytecode suivant eventuel. S'il reste encore un bytecode a analyser, l'editeur de lien 8 retourne (14) a l'etape 2. Si non, il va a l'etape fin (15). Il n'a ete jusqu'ici question que de langage Java. Naturellement, ['invention n'est pas limitee a un tel langage. D'autres vent parfaitement envisageables, comme par exemple le langage C#. Enfin, comme objets electroniques portatifs, on peut songer, en dehors des cartes a puce, aux organisateurs personnels, terminaux telephoniques cellulaires, etc. 8 2839792 REVENDICATIONS 1.- Procede de chargement d'une apples, dans des moyens memoires (5) d'une puce (10) d'un objet electronique portatif, comprenant un fichier optimise (30) comportant un composant des methodes (31) et un composant de localisation des references (RLC) (38) avec au moins une table (T) d'informations de resol ution d' adresses, pro cede dans leque l on a resolu l es adresses relative s (34) dans le fichier optimise (30) des parametres (33) associes aux instructions des codes intermediaires (32) du composant des methodes (31) a ['aide desdites informations du composant RLC (38), procede caracterise par le fait qu'on assure l'integrite desdites informations de resolution d'adresses du composant RLC (38) avant de resoudre dans la puce (10) les adresses relatives du fichier optimise, en recalculant dans la carte, apres chargement (36), lesdites informations de resolution d'adresses du composant RLC (38) avant de resoudre les adresses relatives. 2.- Procede selon la revendication l, dans lequel, apres chargement (36), on resout lesdites adresses relatives a la volee, l'une apres l'autre. 3.- Procede selon l'une des revendications l et 2, dans lequel la resolution des adresses relatives du fichier optime, apres chargement, s'effectue par un editeur de lien (8). 4.- Procede selon l'une des revendications l a 3, dans lequel, on a prealablement charge dans la carte un composant Tj contenant pour chaque instruction de bytecode javacard existante specifiee dans la norme Javacard les informations necessaires a la resolution des parametres de ce bytecode ainsi que les informations necessaires pour passer a l'analyse d'une instruction