Brevet FR2836569A1 — publié le 20030829

Espace mémoire pour données d'application téléchargées dans une carte à puce La présente invention concerne la gestion d'un espace mémoire destiné à mémoriser des cadres de données d'une application téléchargée qui a été écrite dans un langage de haut niveau orienté objet et qui est exécutée dans un objet électronique portable du type carte à puce. Comme montré à la figure 1, la carte à puce CP, dite également carte à microcontrôleur, contient un microprocesseur PR, une mémoire MO du type ROM, une mémoire non volatile de données de machine MDM de type EEPROM et une mémoire à accès aléatoire MDE de données échangées avec l'extérieur de type RAM. Tous les composants PR, MO, MDM et MDE sont reliés par un bus interne BU. La mémoire MO contient des instructions en code natif d'un système d'exploitation OS (Operating System) et des pseudocodes d'une machine virtuelle VM qui s'appuie sur le système d'exploitation, et au moins des applications internes d'authentification et de communication. La mémoire non volatile MDM contient essentiellement des données liées au système d'exploitation et accessibles par codes natifs et des données liées à la machine virtuelle VM et accessibles par pseudocodes ainsi que les pseudocodes et les données d'application. La mémoire MDM contient également des données personnelles liées au possesseur de la carte à puce. La mémoire MDE de type RAM contient essentiellement des données échangées avec le monde extérieur à la carte à puce CA, notamment avec une plate-forme d'accueil, tel qu'un terminal TE doté d'un lecteur de carte à puce LE, à travers une liaison LI à contact ou sans contact. En particulier, la mémoire MDE contient des données au moins d'une application téléchargée, telle qu'une applet AP. L'applet a été initialement écrite en langage de haut niveau, tel que le langage Java, ou plus particulièrement le langage Java Card, puis compilée en langage intermédiaire. L'applet est composée d'instructions appelées pseudocodes (bytecodes) qui sont prêtes à être exécutées par la machine virtuelle VM qui constitue un interpréteur dans la carte à puce. Par exemple, lorsque la carte à puce est une carte de paiement, le terminal est un terminal bancaire ou un terminal point de vente, ou lorsque la carte à puce est un module d'identité d'abonné téléphonique amovible SIM (Subscriber Identity Module), le terminal est un radiotéléphone cellulaire mobile. Selon d'autres variantes, l'objet électronique portable au lieu d'être une carte à puce peut être un assistant numérique personnel PDA ou un porte-monnaie électronique. L'invention est dirigée plus particulièrement vers la gestion d'un espace mémorisé EM de taille TEM alloué à des cadres de données d'application mémoire MDE du type RAM de l'objet électronique portable, tel que la carte à puce CP à laquelle on se référera dans la suite. L'applet AP est téléchargée depuis un serveur à travers le terminal d'accueil TE et la liaison LI pour être exécutée principalement dans la carte. Selon la technique antérieure, l'espace mémoire EM réservé à des cadres de données d'une applet compilée AP est organisé en une pile PI ayant une taille prédéterminée TP Chaque cadre Cn introduit sur la pile inclut une méthode invoquée respective Mn de l'application AP. Ainsi l'invocation d'une méthode Mn+l dans l'application AP sous le contrôle du processeur PR provoque l'empilement d'un cadre respectif Cn+l sur le dessus de la pile PI dans laquelle sont maintenus empilés les autres cadres Ml à Mn. Les méthodes s'invoquent les unes les autres, la méthode Mn invoquant la méthode Mn+l et la méthode Mn+l ne pouvant que retourner à la méthode précédente Mn, en dépilant et écartant la méthode Mn+l du dessus de la pile PI, ou pouvant invoquer une nouvelle méthode Mn+2. Seulement la méthode Mn+l dans le cadre supérieur Cn+l de la pile est active. Chaque cadre Cn est composé successivement d'une première partie de variable locale VLn ayant une taille fixe respective prédéterminée, d'une deuxième partie de données de machine virtuelle DMn ayant une taille fixe respective prédéterminée, et d'une troisième partie d'opérande OPn ayant une taille variable. La partie VLn contient aucune, une ou plusieurs variables locales qui sont déclarées lors de l'implémentation de la méthode Mn dans l'espace mémoire EM et avant l'exécution de la méthode Mn. Les variables locales servent à l'exécution de la méthode Mn, leur nombre n'étant pas modifié mais leurs valeurs étant modifiées au cours de l'exécution de la méthode. La taille de la première partie VLn est donc fixe et prédéterminée avant l'exécution de la méthode Mn. Les variables locales peuvent être la désignation de l'objet dont la méthode est appelée, des paramètres de la méthode et d'autres variables locales. Les données de machine Java Card dans la partie DMn, appelées également données de système (system data), permettent à la machine virtuelle de revenir à la méthode précédente Min-1 et en particulier de positionner convenablement le pointeur de pile PP dans l'espace mémoire EM au niveau de la méthode Min-1 où la méthode courante Mn avait été appelée. Les opérandes dans la troisième partie OPn du cadre Cn sont des valeurs utilisées par la machine virtuelle pour exécuter les prochaines opérations et en particulier utilisées comme argument de l'appel de la méthode Mn+l. Comme indiqué à la figure 2 par un chevauchement CHn+l de la partie d'opérande OPn de la méthode Mn et de la partie de variable locale VLn+l de la méthode suivante Mn+l, des opérandes de la méthode Mn peuvent devenir des valeurs locales de la méthode immédiatement sus-jacente Mn+l lors de l'implémentation de la méthode Mn+i, et inversement le résultat de la méthode Mn+l peut devenir un opérande de la méthode immédiatement sous-jacente Mn lors du retour à celle-ci. Pour une méthode, telle que la méthode Mn+1, soit appelée et donc pour que le cadre de données Cn+l puisse être construit, l'information de taille maximale Tn+l qu'est susceptible d'atteindre la méthode appelée Mn+l au cours de son exécution est précalculée lors de la création du pseudo-code de l'application à l'extérieur de la carte, puis chargée avec l'applet dans la carte. De plus, un vérificateur VER dans le terminal d'accueil TE recalcule la taille maximale Tn+l qu'est susceptible d'atteindre la méthode appelée Mn+l au cours de son exécution, puis vérifie qu'elle correspond à celle précalculée dans le pseudocode de l'application. Avant d'implémenter la méthode Mn+l dans l'espace mémoire EM alloué à l'applet AP, la machine virtuelle ajoute la taille Tn+l-CHn+l à la somme courante des tailles Tel-0 à Tn-CHn des cadres de méthode déjà empilés en la pile PI, c'est-à-dire à la taille TPI de la pile afin de la comparer à la taille TEM. Si T+l-CH+i + TPI > TEM est vérifiée, un débordement de pile DB (overflow en anglais) est détecté comme montré à la figure 2, et la machine virtuelle signale une erreur. En revanche, si la taille Tn+i-CHn+l de la méthode appelée Mn+l est compatible avec la portion vide restante supérieure dans l'espace mémoire EM, le cadre Cn+l de la méthode Mn+l est écrit pour exécuter celle-ci. Inversement, lorsqu'une méthode, telle que la méthode Mn+l, est exécutée, le pointeur PP de la pile PI doit rester dans la partie d'opérande OPn+l et ne doit jamais en sortir pour pointer des données de machine virtuelle dans la partie intermédiaire DM+i. Dans le cas contraire, un"dépassement inférieur"DI (underflow en anglais) de la partie OPn+i survient comme montré à la figure 3. Pour surmonter ce défaut, certains vérificateurs vérifient initialement, avant l'implémentation d'une méthode Mn+l sur la pile PI qu'un dépassement inférieur ne surviendra jamais en testant tous les chemins possibles dans la méthode avant son exécution afin que tout empilement dans la partie supérieure OPn+l ne soit pas suivi d'un dépilement plus grand jusqu'à atteindre la partie de données de machine DM+l. Si le test de l'un des chemins signale un dépassement inférieur, le vérificateur VER refuse la méthode Mn+l et signale une erreur. Cependant, il arrive parfois que les fonctions du vérificateur soient écartées par une introduction malveillante de pseudocodes dans l'applet AP. L'applet non vérifiée est alors téléchargée dans la carte à puce. Dans ce cas, tout excès d'empilement de méthode au-dessus de la pile PI dans l'espace mémoire EM provoque un débordement DB. Si l'exécution d'une méthode Mn+l cause un dépassement inférieur DI après dépilage de la partie d'opérande OP+i, des données de machine dans la partie DMn+l sont atteintes, ce qui modifie le contexte de la méthode invoquante Mn. Les données de machine virtuelle dans la partie DMn du cadre Cn de chaque méthode ne doivent pas être modifiées et être sujettes à des attaques par l'implémentation d'apples par des développeurs peu scrupuleux. Par le biais particulièrement d'un dépassement inférieur, les données de machine virtuelle peuvent être modifiées pour retourner à la méthode exécutée avec des paramètres choisis, par exemple pour exécuter des codes choisis avec un contexte déterminé. L'invention vise à remédier aux conséquences de ces attaques particulièrement lorsque les méthodes d'applet ne sont pas préalablement vérifiées avant leur implémentation dans la mémoire de données échangées dans un objet électronique portable. A cette fin, un espace mémoire alloué à une pile de cadres de données d'application téléchargée dans un objet électronique portable, chaque cadre comportant successivement au moins une partie de données de machine et une partie d'opérande ayant une longueur variable lors de l'exécution du code associé au cadre, est caractérisé en ce qu'il est composé d'un premier espace mémoire alloué à l'empilement des parties de données de machine, et d'un deuxième espace mémoire alloué à l'empilement des parties d'opérandes, les premier et deuxième espaces mémoires étant disjoints et ayant des pointeurs indépendants. Même lorsque l'applet constituant l'application téléchargée et comprenant les méthodes dont les parties sont réparties dans les premier et deuxième espaces mémoires, n'est pas vérifiée, tout code "malicieux"introduit dans l'une des parties d'opérande de l'applet incluses dans le deuxième espace mémoire n'aura aucune conséquence sur les parties de données de machine virtuelle sensibles dans le premier espace mémoire. En général, chaque cadre (frame) d'une méthode peut contenir une partie de variable locale. Dans cette réalisation, le deuxième espace mémoire contient les parties de variable locale empilées alternativement avec les parties d'opérande. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations préférées de l'invention en référence aux dessins annexés correspondants dans lesquels : - la figure 1 est un bloc-diagramme schématique déjà commenté d'une carte à puce liée à un terminal d'accueil ; - les figures 2 et 3 montrent schématiquement des piles dans un espace mémoire alloué à des méthodes d'applet respectivement lors d'un débordement et d'un dépassement inférieur, selon la technique antérieure déjà commentée ; et - la figure 4 montre schématiquement deux espaces mémoires alloués à des méthodes d'applet selon l'invention. Selon une réalisation préférée de l'invention, l'objet électronique portable est une carte à puce CP telle que décrite précédemment en référence à la figure 1, à l'exception de l'organisation de l'espace mémoire alloué à des cadres (frames) de données Cn contenant des méthodes Mn d'une applet compilée téléchargée AP dans la mémoire MDE de type RAM de la carte. Comme montré à la figure 4, l'espace mémoire est selon l'invention scindé en deux espaces mémoires disjoints EM1 et EM2. Les pointeurs PP1 et PP2 des espaces mémoires EM1 et EM2 sont complètement indépendants : le pointeur PP1 ne peut pas atteindre l'espace EM2 et le pointeur PP2 ne peut pas atteindre l'espace EM1. Tout débordement (overflow) ou dépassement inférieur (underflow) dans l'un des espaces mémoires EM1 et EM2 ne peut pas influencer le contenu de l'autre espace mémoire. Dans la figure 4 sont seulement représentés trois cadres Con-1, Cn et Cn+l de méthodes Mon-1, Mn et Mn+l en haut d'une pile de l'applet AP, chaque cadre comportant une partie de variable locale VL-i, VLn, VL+l, une partie de données de machine virtuelle Din-1, DM, DM+i et une partie d'opérande Pn-lt OPn, OPn+1. Le premier espace mémoire EM1 est propre à recevoir les données sensibles à protéger constituées par les parties de données de machine virtuelle DMn des cadres Cn des méthodes Mn d'applets. Le deuxième espace mémoire EM2 est disponible pour les premières parties VLn contenant des variables locales des méthodes Mn et ayant des tailles fixes respectives et pour les troisièmes parties OPn contenant des opérandes des méthodes Mn et ayant des tailles variables respectives, dans les cadres d'applet Cn. La taille T2 du deuxième espace mémoire EM2 est bien souvent plus grande que la taille Tl du premier espace mémoire EM1. L'empilement alternatif des parties de variable locale VL1 à VLn+l et des parties d'opérande OP1 à OPn+l dans l'espace mémoire commun EM2 permet de conserver le chevauchement CH entre la partie de variable locale VLn d'une méthode Mn et la partie d'opérande OPn+i de la méthode sus-jacente M+ lorsque cette dernière est implémentée. Quand par exemple la méthode Mn est invoquée alors que la pile d'applet contient les méthodes Ml à Mn-1 avec les parties de données de machine virtuelle DMi à DMn-1 empilées dans l'espace mémoire EM1 et avec les paires de partie de valeur locale et de partie d'opérande VL-OP à VLn-1-OPn-1 empilées dans l'espace mémoire EM2, la machine virtuelle VM incrémente d'abord le pointeur PP2 pour écrire la partie de variable locale VLn sur la pile dans l'espace mémoire EM2, puis incrémente le pointeur PP1 pour écrire la partie de données de machine virtuelle DMn dans l'espace mémoire EM1. Finalement, la machine virtuelle VM incrémente à nouveau le pointeur PP2 pour écrire la partie d'opérande OPn au fur et à mesure de l'exécution de la méthode Mn dans l'espace mémoire EM2. Inversement, le dépilage de la méthode Mn pour revenir à la méthode sous-jacente Mn-l s'effectue par un effacement successivement de la partie OPn dans l'espace EM2, de la partie DMn dans l'espace EM1 et de la partie VLn dans l'espace EM2. Lorsqu'un débordement DE (overflow) survient, par exemple lors de l'implémentation du cadre Cn+l de la méthode Mn+i, ce qui résulte d'un débordement seulement dans l'espace EM2 par la partie d'opérande OPn+l, toutes les données de machine DM à DMn+l empilées dans l'espace mémoire EM1 restent intactes : les données de machine ne sont pas affectées. Lorsqu'un dépassement inférieur DI (underflow) survient par exemple lors du dépilage de la partie d'opérande OP+i de la méthode active Mn+l sur la pile, le pointeur PP2 de l'espace mémoire EM2 pointe dans la partie de variable locale sous-jacente VLn+l, sans atteindre les données de machine DMn+l dans l'autre espace mémoire EM1. Pour ces deux défauts, les données de machine virtuelle sensibles empilées dans l'espace mémoire EM1 ne sont affectées selon l'invention et sont donc bien protégées. En condition normale dans la machine virtuelle VM, les débordements dans les deux espaces mémoires EM1 et EM2 sont surveillés, en comparant la taille Tl de l'espace mémoire EM1 à la somme de la taille prédéterminée de la partie de données de machine DMn+l de la méthode courante Mn+l à implémenter et la taille de la pile des parties de données DM] à DMn des méthodes précédentes Mi à Mn dans l'espace mémoire EM1, et en comparant la taille T2 de l'espace mémoire EM2 à la somme de la taille maximale respective de la partie de variable locale OPn+i de la méthode courante Mon+1 la taille prédéterminée respective de la partie de variable locale VLn+i de la méthode courante moins le chevauchement CMn+l, et la taille de la pile des couples de partie de variable locale et de partie d'opérande VOL -OPE à VLn-OPn des méthodes précédentes Ml à Mn dans l'espace mémoire EM2. La méthode courante est refusée lorsque l'une des sommes excède la taille de l'espace mémoire respectif. Encore en condition normale lors d'un dépassement inférieur DI par dépilage de la partie d'opérande, le pointeur PP2 ne pourra sortir de la partie d'opérande OPn+l de la méthode active Mn+l que pour entrer dans des parties inférieures VL1 à VLn+l et O i à OPn qui ne sont pas sensibles, contrairement aux parties de données de machine virtuelle DM à DMn+l dans l'autre espace mémoire EM1. L'invention n'est pas limitée à la séparation très prononcée des espaces mémoires EM1 et EM2 illustrée à la figure 4. En variante, les espaces mémoires EM1 et EM2 sont contigus et leurs pointeurs PP1 et PP2 varient en sens opposé, par exemple l'un croît vers le haut et l'autre croît vers le bas. Selon une autre réalisation qui peut être combinée à la première, la séparation des espaces mémoires peut être améliorée en choisissant deux espaces dont les instructions d'accès par le processeur PR sont différentes. REVENDICATIONS 1-Espace mémoire alloué à une pile de cadres de données d'application téléchargée dans un objet électronique portable (CP), chaque cadre (Cn) comportant successivement au moins une partie de données de machine (DMn) et une partie d'opérande (OPn) ayant une longueur variable lors de l'exécution du code associé au cadre (Mn) r caractérisé en ce qu'il est composé d'un premier espace mémoire (EM1) alloué à l'empilement des parties de données de machine (DMn), et d'un deuxième espace mémoire (EM2) alloué à l'empilement des parties d'opérandes (OPn), les premier et deuxième espaces mémoires étant disjoints et ayant des pointeurs (PP1, PP2) indépendants. 2-Espace mémoire selon la revendication 1, dans lequel chaque cadre (Cn) comprend en outre une partie de variable locale (VLn), caractérisé en ce que le deuxième espace mémoire (EM2) contient les parties de variable locale (VLn) empilées alternativement avec les parties d'opérande (OPn). 3-Espace mémoire selon la revendication 1 ou 2, dans lequel les instructions d'accès des premier et deuxième espaces mémoires (EM1, EM2) sont différentes.