FR3010814A1 - Procede et systeme de securisation d'un environnement d'execution informatique contre les attaques par confusion de type - Google Patents

Abstract

L'invention concerne la sécurisation d'un environnement d'exécution, notamment Java Card, contre des attaques par confusion de type. Des zones mémoires stockent des données de types variés (entier ou référence) manipulées par des bytecodes Java. On associe, à chaque donnée à stocker dans une zone mémoire, une information de type représentative du type de cette donnée, par exemple en ajoutant un bit à la représentation binaire de la donnée stockée, bit dont la valeur et la position dans la représentation binaire dépendent respectivement du type de la donnée et de la zone mémoire de stockage. En variante, une structure similaire à celle prévue pour stocker les données peut être prévue pour mémoriser de façon abstraite, à l'aide d'un bit, le type des données stockées. Puis on utilise l'information associée à une donnée manipulée par une instruction pour détecter un conflit de type entre la donnée et un type de l'instruction.

Description

DOMAINE DE L'INVENTION La présente invention concerne le domaine de la sécurisation informatique et plus particulièrement un procédé et un système de sécurisation d'un environnement d'exécution informatique.

CONTEXTE DE L'INVENTION La sécurité des systèmes informatiques est soumise à rude épreuve par une grande variété d'attaques développées au cours des dernières décennies. Les attaques par confusion de type ont été développées pour mettre à mal la sécurité des environnements d'exécution informatiques reposant sur des données typées, en particulier lorsqu'un type de donnée, c'est-à-dire avec un type particulier, est fortement protégé. C'est le cas par exemple dans les plateformes Java Card conformes à la norme ISO 7816 - Java Card 3.0, où des données de type référence à un objet ou une applet sont mémorisées. Les données de type référence contiennent généralement une valeur d'adresse mémoire, par exemple Ox7FFF, indiquant à quelle adresse mémoire est stocké l'objet ou l'applet auquel elles font référence. Une telle donnée de type référence est généralement attribuée/affectée par l'environnement d'exécution informatique, par exemple la machine virtuelle Java dans les plateformes homonymes, à tout nouveau objet instancié à partir d'une classe de définition. Généralement l'affectation est incrémentale. Cependant, la manipulation d'un objet ou d'une applet est interdite dans ces plateformes Java Card, en empêchant d'accéder aux données de type référence à cet objet ou applet, notamment en interdisant certaines instructions basiques ou bytecodes (autrement connu sous la terminologie pseudo-code Java) sur ces données de type référence. On rappelle ici que le langage de programmation Java utilisé pour la plateforme Java Card est un langage intermédiaire de programmation permettant un développement d'applications indépendamment des architectures matérielles sur lesquelles doivent être exécutées ces applications. Une application écrite dans le langage de programmation Java peut être compilée en pseudo-code Java, c'est-à-dire dans un langage intermédiaire de programmation exécutable par une machine virtuelle Java sur des plateformes ayant des caractéristiques matérielles différentes. A contrario, les données de type primitives, c'est-à-dire ne faisant référence à rien (incluant par exemple les données de type virgule flottante ou float, les données de type entier ou integer, short ou long, les données de type booléen) sont facilement manipulées à l'aide d'instructions basiques ayant le même type que ces données. En effet, les instructions basiques peuvent être typées ou non typées. Lorsqu'elles sont typées, un type, entier ou référence par exemple, leur est affectée correspondant au type autorisé de leur opérande par exemple et autorisant donc uniquement la manipulation de données ayant le même type. En pratique c'est lors de la compilation de l'application que des vérifications sont menées quant à la compatibilité du type de l'instruction basique avec les données qui serviront d'opérande. Notons que certaines instructions basiques peuvent mettre en oeuvre à la fois des données de type entier et des données de type référence, par exemple l'instruction Java Card <putfield_s #i> permettant de dépiler un entier de la pile d'opérandes et de le stocker dans l'attribut #i de l'objet dont la référence est à dépiler ensuite de la pile d'opérandes. Les attaques par confusion de type consistent alors pour l'attaquant à forcer ou « caster» une donnée de type primitive, généralement un entier, sur une donnée de référence à un objet. Ainsi en manipulant la donnée de type entier, l'attaquant manipule également la donnée de référence. Il peut ainsi modifier la valeur d'adresse mémoire pour accéder à d'autres objets instanciés en mémoire ou d'autres applets, et du coup récupérer les valeurs d'attributs de ces autres objets ou accéder à des applications sécurisées. Les références étant affectées parmi un ensemble restreint de références, généralement les premières références jusqu'à un nombre maximal d'instanciations simultanées d'objets, il est aisé de déterminer la référence d'un autre objet. Cela est d'autant plus vrai que les plateformes Java Card sont généralement mises en oeuvre dans des dispositifs, type cartes à puce, dotés de peu de ressources et présentent donc un espace mémoire de travail confiné, partagé entre plusieurs applets exécutées par la même machine virtuelle JCVM. Ces attaques par confusion de type sont susceptibles d'affecter hautement la sécurité des systèmes informatiques car les attributs peuvent contenir des valeurs secrètes mais également les applications accédées peuvent être des applications de paiement, donc sensibles. Notamment, dans les plateformes Java Card, la machine virtuelle JCVM est activée tout le temps en mémoire non volatile ROM, signifiant que les instances d'objets sont permanentes. Une éventuelle attaque est donc susceptible d'engendrer des risques sur un plus long terme, contrairement notamment à la technologie Java classique où les instances d'objets sont détruites de la mémoire volatile RAM par exemple à l'extinction du dispositif.

Les attaques par confusion de type sont possibles car certains environnements d'exécution informatiques ne vérifient pas le type des données entre une entrée (par exemple d'une méthode) et une sortie. Par exemple, la pile d'opérandes dans la plateforme Java Card a une largeur de deux octets permettant uniquement le stockage similaire des données codées sur deux octets qu'elles soient de type entier ou référence (la majorité des types de donnée selon Java Card, par exemple entier short, entier integer, référence, booléen, sont codées sur deux octets). En pratique, des applications malveillantes seules ou combinées à des injections de fautes peuvent être utilisées pour introduire des confusions de type dans les plateformes informatiques.

Dans le cas de Java Card, certaines zones mémoires sont partagées par plusieurs applications Java. Ainsi, à l'aide de ces confusions de type, une application malveillante ou détournée par injection de faute peut accéder aux données sensibles d'une autre application. On distingue également les attaques par confusion directe de type et celles par confusion indirecte de type. L'attaque par confusion directe de type consiste à directement manipuler une donnée de type référence comme valeur d'entier (vice et versa), par exemple en affectant la valeur d'une première variable de type entier à une deuxième variable de type référence. Bien que les compilateurs ne permettent pas une telle affectation, l'établissement d'une séquence d'instructions illégales est toujours possible par des personnes mal intentionnées. L'attaque par confusion indirecte de type consiste, quant à elle, à manipuler une donnée de type référence comme valeur d'entier au travers de deux ou plus instances d'objets différents (vice et versa), l'un contenant un attribut de type référence et l'autre un attribut de type entier. Dans ce cas, la confusion de type naît du forçage d'un objet sur l'autre, permettant de manipuler l'attribut de type référence à l'aide de l'attribut de type entier de l'autre objet. Il existe donc des attaques de plusieurs sortes : uniquement applicatives (applications malveillantes seules) et par confusion directe de type, d'autres combinées (applications malveillantes et injection de fautes) et par confusion directe de type, d'autres uniquement applicatives et par confusion indirecte de type, et d'autres encore combinées et par confusion indirecte de type, elles-mêmes divisées en deux sous-ensembles : celles reposant sur une injection de faute sur les données (faute injectée pour modifier une valeur stockée), et celles sur une injection de faute sur le code (faute injectée pour force l'exécution du code ou des bytecodes à son avantage). Il existe quelques solutions protégeant les environnements d'exécution informatiques contre certaines de ces attaques. A titre d'exemple, la vérification d'instructions basiques (la plateforme Java Card inclut par exemple un vérifieur de bytecode Java Card) vérifie statiquement qu'un fichier binaire satisfait aux règles du langage de programmation et notamment aux règles de syntaxe et de type des données. Par exemple, la succession de deux instructions basiques manipulant la même donnée mais typées différemment sera interdite. Cette solution apparaît efficace contre les attaques uniquement applicatives, mais pas contre celles où une faute (postérieure à la vérification du bytecode) est injectée. Egalement, la publication « Mitigating Type Confusion on Java Card » (Dubreuil et al., International Journal of Secure Software Engineering, Vol. 4, No. 1, pp. 19-39, 2013) décrit une solution reposant sur la ségrégation des données de type référence et celles de type entier dans chaque pile d'opérandes utilisée par une méthode Java. Les données de type référence sont ajoutées et retirées par le haut de la pile, alors que les données de type entier le sont par le bas de la pile. Egalement, lorsqu'il ne reste qu'un opérande dans la pile (accessible aussi bien par le haut que le bas de la pile), l'attaque par confusion de type est toujours possible.

Cette solution est efficace contre les attaques par confusion directe de type, mais reste inefficace contre celles par confusion indirecte de type. En outre, cette approche pose des difficultés pour le traitement des instructions basiques non typées (par exemple <dup> ou <ifeq> en Java), car dans ce cas il est impossible de savoir si la dernière donnée à utiliser doit être récupérée par le haut ou le bas de la pile.

Enfin, la solution décrite dans « Java Card Combined Attacks with Localization-Agnostic Fault Injection » (J. Lancia, Proceedings of CARDIS '12, Vol. 7771 of LNCS, pp. 31-45, 2013) propose d'ajouter des informations d'intégrité sur les instances d'objet afin de détecter une modification de valeur d'attribut résultant d'une injection de faute. De fait, cette solution n'est pas efficace contre les autres attaques combinées (par injection de faute sur l'exécution du code) et contre celles qui sont uniquement applicatives. Le tableau en Figure 1 résume cette situation de l'état de l'art de ces quelques solutions à l'encontre des attaques par confusion de type (voir les trois premières colonnes : « Vérif. ByteCode », « Ségrégation dans OS » et « Information d'intégrité »). Les différentes solutions de l'état de l'art sont donc très partiellement efficaces contre l'ensemble des attaques connues par confusion de type. D'ailleurs, la combinaison de ces solutions ne permet pas de protéger de façon efficace un environnement d'exécution informatique contre l'ensemble des attaques connues. RESUME DE L'INVENTION La présente invention vise à pallier tout ou partie de ces inconvénients, notamment pour proposer des solutions de protection plus efficaces que celles connues, tendant notamment à une sécurisation hautement efficace contre l'ensemble des catégories connues d'attaques par confusion de type. A cet effet, un premier objet de l'invention concerne un procédé de sécurisation d'un environnement d'exécution informatique, en particulier Java Card, comprenant une pluralité de zones mémoires prévues pour stocker des données manipulées par des instructions basiques de lecture ou écriture sur ces zones mémoires, les données manipulées pouvant être d'au moins deux types différents, en particulier un type entier (integer, short ou long) et un type référence à un objet, caractérisé en ce qu'il comprend les étapes suivantes : associer, à chaque donnée à stocker dans une zone mémoire, une information supplémentaire de type représentative du type de ladite donnée à stocker ; et utiliser l'information de type associée à une donnée manipulée par une instruction basique en cours d'exécution, pour détecter un conflit de type entre la donnée manipulée et un type de l'instruction basique.

Le procédé selon l'invention permet d'améliorer la sécurisation des systèmes informatiques contre les attaques par confusion de type car désormais le type des données n'est plus perdu au niveau des zones mémoires, comme c'est le cas dans les solutions connues. Cette amélioration est obtenue par l'association d'une information de type pertinente à chaque donnée stockée en mémoire et l'utilisation de cette information pour détecter un conflit de type. Le type de la donnée est donc explicitement stocké en mémoire. Ainsi, une attaque par confusion de type est efficacement détectée dès lors qu'une instruction basique typée « entier » tente de manipuler une donnée stockée dont l'information de type associée indique qu'il s'agit d'une référence (vice et versa). En outre, elle permet de conserver la compatibilité avec des instructions basiques non typées comme décrit après. Corrélativement, un deuxième aspect de l'invention concerne un système de sécurisation d'un environnement d'exécution informatique, en particulier Java Card, comprenant une pluralité de zones mémoires prévues pour stocker des données manipulées par des instructions basiques de lecture ou écriture sur ces zones mémoires, les données manipulées pouvant être d'au moins deux types différents, en particulier un type entier (integer, short ou long) et un type référence à un objet, caractérisé en ce qu'il comprend : un module d'association configuré pour associer, à chaque donnée à stocker dans une zone mémoire, une information supplémentaire de type représentative du type de ladite donnée à stocker ; et un module de détection configuré pour utiliser l'information de type associée à une donnée manipulée par une instruction basique en cours d'exécution, de sorte à détecter un conflit de type entre la donnée manipulée et un type de l'instruction basique. Le système est donc adapté à la mise en oeuvre du procédé selon l'invention précédemment introduit, et peut être embarqué dans un dispositif tel une carte à microcircuit.

L'invention a également pour objet un produit programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur. Le système et le produit programme d'ordinateur présentent des avantages similaires à ce procédé.

D'autres caractéristiques du procédé et du système selon des modes de réalisation sont décrites dans les revendications dépendantes. Par exemple, dans un mode de réalisation principal de l'invention, l'étape d'association comprend l'application, à la donnée à stocker, d'une fonction d'encodage propre au type de ladite donnée à stocker, les fonctions d'encodage propres aux deux types différents ayant valeur dans des ensembles distincts. Ces ensembles distincts garantissent que chaque donnée (encodée) stockée est associée à un type particulier, i.e. celui de l'ensemble auquel appartient la donnée codée. Cette disposition assure que l'information de type suit continuellement les données traitées durant les opérations.

Selon un mode de réalisation particulier de l'invention, la fonction d'encodage est également propre à la zone mémoire de stockage de ladite donnée. Cette disposition permet une plus grande précision dans la détection du conflit de type et donc dans l'identification de fonctions (attaquées) par lesquelles un attaquant introduit des confusions de type. En effet, selon les instructions basiques, par exemple en Java, différentes zones mémoires sont utilisées. Selon un autre mode de réalisation particulier qui peut lui être combiné, les fonctions d'encodage ajoutent au moins un bit à la représentation binaire de la donnée à stocker, bit dont la valeur dépend du type associé à chacune des fonctions d'encodage. Cette disposition permet d'introduire ladite information supplémentaire de type dans la donnée à stocker. De façon réciproque, les fonctions de décodage correspondantes retirent donc le même bit en vérifiant par exemple qu'il prend la valeur attendue (afin de détecter un éventuel conflit de type). Selon une caractéristique particulière dans un mode de réalisation, la position d'ajout de l'au moins un bit dans la représentation binaire de la donnée à stocker dépend de la zone mémoire de stockage de ladite donnée. Cette disposition s'avère simple à mettre en oeuvre pour accroître la précision dans l'identification de fonctions par lesquelles des confusions de type peuvent être introduites. Selon une autre caractéristique, l'au moins un bit comprend de deux à huit bits. Cette configuration apporte une robustesse accrue contre des attaques par perturbation. En outre, dans le cas de dispositifs manipulant des données de granularité d'un octet (cas le plus répandu), cette configuration n'engendre aucun coût supplémentaire de mémoire par rapport à la configuration classique (qui ne rajoute qu'un bit). Selon encore un autre mode de réalisation particulier de l'invention, l'utilisation de l'information supplémentaire de type pour détecter un conflit de type comprend l'application, à la donnée stockée et manipulée par l'instruction basique en cours d'exécution, d'une fonction de décodage propre au type de l'instruction basique. En effet, si les fonctions de codage ont valeur dans des ensembles distincts, la fonction de décodage propre à un type ne peut fonctionner que pour des données codées selon le même type. Il en résulte qu'en cas d'échec de la fonction de décodage, le conflit de type est efficacement détecté. Selon une caractéristique particulière d'un mode de réalisation, la fonction de décodage est également propre à la zone mémoire stockant ladite donnée manipulée par l'instruction basique en cours d'exécution. Cette disposition garantit une détection efficace du conflit de type et individualisée à chaque zone mémoire. Selon encore un autre mode de réalisation particulier de l'invention, lorsque l'instruction basique en cours d'exécution est non typée, on applique, à la donnée stockée et manipulée, l'ensemble des fonctions de décodage propres aux différents types. En effet il convient de récupérer la donnée décodée sans connaissance a priori de son type. A cet effet, on applique l'ensemble des fonctions de décodage possibles dont l'une (celle ne résultant pas en un échec de décodage) renvoie ladite donnée décodée. Dans un autre mode de réalisation principal de l'invention, l'étape d'association comprend l'indication de l'information supplémentaire de type associée à la donnée à stocker, dans une structure similaire à une première structure destinée à stocker ladite donnée dans la zone mémoire et à un emplacement correspondant à celui de stockage de ladite donnée dans la première structure. La similarité entre les structures permet de conserver une correspondance directe en la donnée stockée dans la première structure et son type mémorisé dans ladite structure similaire. Ce mode de réalisation permet notamment de conserver les premières structures inchangées, c'est-à-dire de rester compatible avec les exigences de certaines normes, type ISO 7816 - Java Card 3.0, sur les structures de stockage des données. Par exemple, on conserver des structures stockant les données sur deux octets quel que soit leur type, dans le cas notamment de la norme Java Card. Selon un mode de réalisation particulier de l'invention, l'utilisation de l'information supplémentaire de type pour détecter un conflit de type comprend la comparaison de l'information supplémentaire de type stockée dans ladite structure similaire avec le type de l'instruction basique en cours d'exécution. Cette disposition est simple à mettre en oeuvre pour effectuer la détection d'une attaque par confusion de type. Selon un autre mode de réalisation particulier de l'invention, l'information supplémentaire de type dans ladite structure similaire comprend de un à huit bits, de préférence un unique bit pour réduire l'espace mémoire nécessaire et permettre la manipulation uniquement de booléens.

Selon encore un autre mode de réalisation particulier de l'invention, la première structure et ladite structure similaire sont des piles partageant un même indicateur de sommet de pile. En effet, comme les deux structures de type pile évoluent normalement de façon identique, leurs tailles sont identiques et donc leurs sommets (top) ont une position similaire (indicateur de sommet de pile, parfois un pointeur) relativement à l'espace mémoire qui leur est respectivement alloué. Selon encore un autre mode de réalisation particulier de l'invention, une même structure similaire est utilisée pour stocker l'information supplémentaire de type des données stockées dans une pluralité de premières structures mémorisant les instances d'un même objet d'un langage de programmation orienté objet, par exemple d'une même classe Java. Comme toutes les instances d'un objet ont les mêmes champs/attributs avec les mêmes types, il n'est pas nécessaire de dupliquer les informations de type pour chacune des instanciations. Au final, l'espace mémoire requis pour la mise en oeuvre de l'invention est limité.

Dans un autre mode de réalisation principal de l'invention, une donnée est stockée dans la zone mémoire, et l'étape d'association comprend, immédiatement après le stockage de la donnée, le stockage d'une valeur prédéfinie dans la zone mémoire si la donnée stockée est d'un premier type. Cette configuration permet de n'utiliser que les structures de mémorisation déjà existantes, sans adjonction ou modification. Selon un mode de réalisation particulier de l'invention, le premier type est le type entier. Ainsi, seuls les entiers sont marqués à l'aide de la valeur prédéfinie, les données de type référence étant mémorisées de façon classique. C'est la valeur prédéfinie présente dans la mémoire qui permet à l'environnement d'exécution d'effectuer une vérification entre le type de la donnée accédée et le type de l'instruction basique réalisant cet accès. Selon un autre mode de réalisation particulier de l'invention, la valeur prédéfinie est choisie hors de l'ensemble des références affectables à des instanciations d'objets compte tenu d'un nombre maximal d'instanciations simultanées d'objets. Cette disposition permet de sécuriser le mécanisme en évitant que la valeur prédéfinie puisse accidentellement correspondre à une donnée de référence utilisée. En effet dans ce cas, il n'existe aucune incertitude sur la nature (valeur prédéfinie ou donnée de référence) de la valeur/donnée lue en mémoire. Selon un encore autre mode de réalisation particulier de l'invention, la donnée et la valeur prédéfinie sont stockées consécutivement dans une zone mémoire de type pile. En d'autres termes, ce mode de réalisation principal de l'invention est mis en oeuvre au niveau des piles, type pile d'opérandes, là où il est le plus efficace. Selon différents modes de réalisation de l'invention : - les deux types incluent le type entier (ou integer, short ou long) et le type référence à un objet instancié dans l'environnement d'exécution, c'est-à-dire une référence ou pointeur ou adresse vers un objet mémorisé dans une autre zone mémoire, par exemple une zone mémoire d'instance d'objets dans une plateforme Java Card ; - les instructions basiques sont des bytecodes Java, c'est-à-dire un flux d'octets binaire au format d'une classe Java. L'invention est particulièrement bien adaptée aux restrictions Java Card, en ce qu'elles interdisent la manipulation directe des données de type référence à un objet ; - une zone mémoire de ladite pluralité est l'une parmi : une pile d'opérandes configurée pour stocker des opérandes et paramètres des instructions basiques lors de leurs exécutions ; une table de variables locales configurée pour stocker des paramètres et variables locales d'une méthode en cours d'exécution d'un langage de programmation orienté objet, par exemple Java ; une zone d'instance d'objets configurée pour stocker les instances d'un objet d'un langage de programmation orienté objet.

Cette configuration permet de sécuriser la globalité de l'environnement d'exécution informatique car ces trois zones mémoires sont celles qui sont principalement utilisées lors de l'exécution des instructions basiques. Un troisième objet de l'invention concerne un dispositif électronique sécurisé, par exemple une carte à microcircuit ou carte à puce, embarquant un environnement d'exécution Java Card (Java Card Runtime Environment) et un système de sécurisation comme décrit ci-dessus. Un tel dispositif est donc efficacement sécurisé contre des attaques par confusion de type. BREVE DESCRIPTION DES FIGURES D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : - La Figure 1 dresse un tableau comparatif de la sécurisation contre les attaques par confusion de type, procurée par trois techniques connues et par les deux modes de réalisation de l'invention décrits à titre principaux ; - La Figure 2 illustre une architecture mémoire mise en oeuvre dans une plateforme Java Card ; - La Figure 3 illustre un premier mode de réalisation de l'invention ; - La Figure 4 illustre un second mode de réalisation de l'invention ; et - La Figure 5 illustre un troisième mode de réalisation de l'invention. DESCRIPTION DETAILLEE DE L'INVENTION La présente invention concerne la sécurisation d'environnements d'exécution informatiques, par exemple des dispositifs électroniques portatifs et sécurisés dotés de peu de ressources, tels des cartes à puce. La technologie Java Card est largement répandue dans ces dispositifs. La description ci-après fait référence au contexte des plateformes Java Card. L'invention peut également s'appliquer à une machine virtuelle Java dans un ordinateur. Les plateformes Java Card mettent en oeuvre un environnement d'exécution Java Card (ou JCRE) responsable de la gestion des ressources de la carte à puce, notamment des mémoires, des communications réseaux et de l'exécution et la sécurité des applets. Il comprend une machine virtuelle (JCVM) instanciée pour chaque application Java Card, en charge d'exécuter le bytecode Java Card de l'application. Ainsi, le JCRE exécute les méthodes définies dans l'application Java Card et gère les différentes instances d'objets sur la plateforme. Lors que la machine virtuelle Java Card exécute une application, elle a besoin de mémoire pour stocker un grand nombre d'informations, incluant les instructions basiques ou bytecodes Java, les objets instanciés à partir de classes, les paramètres des méthodes exécutées, les valeurs retournées par ces méthodes, les valeurs locales de ces méthodes, et des résultats intermédiaires de calcul. La figure 2 illustre quatre zones mémoire du JCRE qui contiennent les données manipulées par les instructions basiques ou bytecodes Java de l'application Java Card. Chaque fois qu'une instance de classe ou d'objet est créée au cours de l'exécution de l'application Java Card, de la mémoire persistante ou réinscriptible (EEPROM/Flash) est allouée dans la zone mémoire référencée OIA (pour Object Instance Area) afin de mémoriser cette instance d'objet (incluant des données d'instance et des attributs).

Pour pouvoir retrouver cet objet dans la zone mémoire OIA, une valeur d'adresse mémoire ou « référence » lui est attribuée et affectée. Cette référence, sur deux octets généralement, est incrémentée pour chaque nouvel objet instancié. La zone mémoire OIA est commune à l'ensemble des instances créées lors de l'exécution de toutes les applications Java Card présentes sur la carte. C'est cette zone mémoire qui constitue la vulnérabilité principale des plateformes Java Card aux attaques par confusion de type. Deux autres zones mémoires appartiennent à une zone mémoire principale dite « trame Java » (Java Stack) créée, en mémoire vive (RAM), pour chaque exécution d'une méthode Java dans l'application Java Card. La Java Stack comprend ainsi une pile d'opérandes (OS pour Operand Stack) où les opérandes et paramètres des instructions basiques sont poussés ou dépilés, et une table de variables locales (LV pour Local Variables) contenant les paramètres et variables locales de la méthode en cours d'exécution.

Enfin, une zone mémoire BC en mémoire morte ROM contient le bytecode de l'application Java et par voie de conséquence des valeurs constantes définies dedans et utilisées par certaines instructions basiques. Ces valeurs constantes peuvent uniquement être poussées dans la pile d'opérandes OS. Cette zone mémoire n'a pas besoin d'être réinscriptible car les valeurs constantes n'ont pas vocation à être modifiées. L'architecture représentée sur la Figure 2 montre que la pile d'opérandes OS joue un rôle central : elle reçoit les données des autres zones mémoires afin de réaliser des opérations conformément aux instructions basiques exécutées, puis ses données sont dépilées pour être stockées soit dans la table LV (s'il s'agit par exemple d'une nouvelle valeur de variable locale) soit dans la zone OIA (s'il s'agit par exemple de nouveaux attributs d'un objet instancié). On s'intéresse en particulier aux instructions basiques de lecture ou écriture sur ces zones mémoires. Par exemple, le bytecode correspondant à <sload_3> est une instruction basique typée « short » (indiqué par le préfixe « s ») en ce que ses opérandes ou paramètres sont de type short. Cette instruction basique charge la variable locale de type short stockée dans l'entrée #3 de la table LV sur le sommet de la pile d'opérandes OS. Symétriquement <sstore_2> dépile la valeur de type short située au sommet de la pile d'opérandes OS pour la stocker dans l'entrée #2 de la table LV.

Les instructions <aload_3> et <astore_2> permettent les mêmes opérations sur, cependant, des données de type référence à un objet (le préfixe « a » faisant référence à une valeur d'adresse mémoire). Dans la norme Java Card Platform, les zones mémoires OS, LV et OIA où transitent les données manipulées par les instructions basiques stockent ces données en perdant tout information du type de celles-ci, car seule une largeur de deux octets est prévue pour stocker uniquement chaque valeur de ces données. C'est la raison pour laquelle la confusion malicieuse de type est possible. Dans l'attaque par confusion directe de type, la donnée de type référence est directement manipulée comme valeur d'entier. Par exemple une application malicieuse peut être conçue pour réaliser une séquence illégale d'instructions basiques, par exemple <sload_3> puis <astore_2> pour charger une valeur d'entier initialement dans la table LV (dans l'entrée #3) en une donnée de type référence dans l'entrée #2 de la table LV, en transitant par la pile d'opérandes OS. Ainsi en fixant une valeur souhaitée à l'entier stocké dans l'entrée #3 de LV, l'attaquant configure la référence définie dans l'entrée #2 de LV, référence permettant par exemple d'accéder à un nouvel objet instancié. Dans un autre exemple, une faute est volontairement injectée lors de l'exécution des instructions basiques de l'application Java Card. Par exemple, supposons que l'instruction <ifeq> est sur le point d'être exécutée avec un paramètre égal à Ox2B. Si la personne mal intentionnée injecte une faute pour modifier l'instruction <ifeq> en instruction <nop> qui ne fait rien et n'utilise aucun paramètre, alors le paramètre Ox2B est vu par la machine virtuelle JCVM comme le prochain bytecode à exécuter, correspondant à l'instruction basique <astore_0>. Il en résulte que la valeur entière de sommet de pile OS qui devait être manipulée par l'instruction basique <ifeq> se retrouve stockée dans la table LV comme référence. Dans l'attaque par confusion indirecte de type, la donnée de type référence est manipulée comme valeur d'entier au travers de deux ou plus instances d'objets différents, l'un contenant un attribut de type référence et l'autre un attribut de type entier. Par exemple, une classe 'C' d'objets contient un attribut raft' de type référence : public class C { reference att }. Une personne mal intentionnée peut prévoir une autre classe 'B' d'objets contenant un attribut 'val' de type entier (short) : public class B { short val }.

En créant une instance de l'objet B : B b = new B(); puis en « castant » (i.e. forçant) l'objet instancié de type B sur un objet de type C : C c = b; la personne mal intentionnée peut directement manipuler la donnée raft' de type référence de l'objet c en modifiant la donnée 'val' de type entier de l'objet b' car dans cette configuration c.att = b.val. Grâce au « cast », le même objet en mémoire OIA est accessible à la fois comme objet c de type C et comme objet b de type B. Ce type d'attaque peut être réalisé à l'aide d'une application malveillante (modifiée par l'attaquant) ou par l'injection d'erreurs dans l'exécution de l'application Java Card de sorte à exécuter l'opération « C c=b; ».

Pour contrer l'ensemble de ces attaques possibles par confusion de type entre notamment le type entier et le type référence, un procédé de sécurisation selon l'invention prévoit les étapes suivantes : associer, à chaque donnée à stocker dans une zone mémoire, une information supplémentaire de type représentative du type de ladite donnée à stocker ; 15 et utiliser l'information de type associée à une donnée manipulée par une instruction basique en cours d'exécution, pour détecter un conflit de type entre la donnée manipulée et un type de l'instruction basique. En effet, l'utilisation de l'information supplémentaire de type permet de 20 maintenir un suivi sur le type des données manipulées dans les différentes zones mémoires, par exemple OS, LV, OIA et BC. Ainsi un conflit de type, et donc une attaque potentielle, peuvent être simplement détectés en comparant le type associé à la donnée stockée en passe d'être manipulée par une instruction basique courante et le type de cette instruction basique. 25 La manipulation directe d'une donnée de type référence n'est ainsi plus possible à partir d'une instruction basique de type entier. L'invention protège donc des attaques par confusion directe de type. De plus, malgré le forçage de l'objet 'ID' sur l'objet 'c', l'invention prévoit de conserver trace du fait que l'attribut `c.att' est de type référence de telle sorte que sa 30 modification /manipulation via l'attribut `b.val' n'est plus possible. L'invention protège donc également des attaques par confusion indirecte de type. En cas de détection de telles attaques, une procédure de sécurité peut être déclenchée, par exemple par l'effacement de données sensibles au sens de la carte à puce, par la désactivation/destruction définitive de la carte à puce. Eventuellement un compteur du nombre d'attaques détectées peut être incrémenté jusqu'à atteindre une valeur seuil pour déclencher une telle procédure de sécurité. La Figure 3 illustre un premier mode de réalisation de l'invention dans lequel l'étape d'association comprend l'application, à la donnée à stocker, d'une fonction d'encodage propre au type de ladite donnée à stocker, les fonctions d'encodage propres aux deux types différents ayant valeur dans des ensembles distincts. Les fonctions d'encodage sont référencées ENCt où 'V représente le type de la donnée manipulée et donc à stocker (1' vaut 's' si la donnée est de type entier, et vaut 'a' si la donnée est de type référence).

On comprend donc que la fonction d'encodage vient ajouter l'information supplémentaire de type permettant le suivi du type des données manipulées et stockées dans les différentes zones mémoires. Pour détecter un conflit de type et donc une attaque potentielle, l'utilisation de l'information supplémentaire de type comprend l'application, à la donnée stockée et manipulée par l'instruction basique en cours d'exécution, d'une fonction de décodage propre au type de l'instruction basique. En effet, une erreur renvoyée lors du décodage est indicatrice d'une divergence entre le type de la donnée manipulée et celui de l'instruction basique en cause. Une attaque a donc lieu. Les fonctions de décodage sont référencées DECt.

Dans l'exemple de la figure, la fonction d'encodage est propre à la zone mémoire de stockage de ladite donnée. De façon symétrique, la fonction de décodage est également propre à la zone mémoire stockant ladite donnée manipulée par l'instruction basique en cours d'exécution. Ainsi les données à empiler sur OS sont encodées à l'aide d'une fonction d'encodage propre à OS, référencée ENCtos, t valant soit 's' soit 'a' selon le type de la donnée manipulée. De même les données dépilées depuis OS sont décodées à l'aide d'une fonction de décodage propre à OS, référencée DECtos avant d'être transmises vers une autre zone mémoire (où elles seront encodées à l'aide d'une fonction d'encodage propre à cette autre zone mémoire). L'utilisation de fonctions propres à chaque zone mémoire permet de détecter de façon plus fine les attaques par confusion de type. En effet, il est ainsi possible d'identifier les instructions basiques ou les fonctions malveillantes. Dans l'exemple qui nous intéresse, il existe donc quatre fonctions propres à chaque zone mémoire * : ENCa-, ENCs-, DECa- et DECs- avec DECa-(ENCs-(X)) et DECs-(ENCa-(X)) aboutissant à des erreurs (permettant ainsi la détection d'une attaque). Ces erreurs de décodage peuvent notamment résulter d'un choix de conception selon lequel les fonctions d'encodage propres aux deux types différents (et accessoirement à la même zone mémoire) ont valeur dans des ensembles distincts. Au niveau de la machine virtuelle JCVM, les opérations d'encodage et de décodage doivent donc être effectuées lors de la mise en oeuvre d'instructions basiques permettant l'échange des données entre deux zones mémoires, et tenir compte du type effectif des dites données. Aux fins d'illustration, quelques exemples sont donnés ici. En ce qui concerne l'instruction basique <aload_0> (typée référence) permettant de charger, sur la pile OS, la donnée de type référence stockée dans l'entrée #0 de la table LV, elle peut être réalisée par les deux instructions élémentaires suivantes : tmp=DECaLv(LV[0]) où LV[0] est l'entrée #0 de LV push(ENCaos(tmp)). De même, l'instruction basique <putfield_s #0> (typée entier) permettant de dépiler un entier de la pile OS et de le stocker dans l'attribut #0 de l'objet dont la référence est à dépiler de la pile OS par la suite, peut être réalisée par les trois instructions élémentaires suivantes : tmp=DECsos(pop()) obj= DECaos(pop()) obj.IF[0]=ENCso1A(tmp) où obj.I F[0] est l'attribut (ou « instance field » IF) #0 de l'objet obj. Egalement, l'instruction basique <bipush #92> (typée entier) permettant de pousser la valeur constante '92' de paramètre sur la pile OS peut être réalisée par l'instruction élémentaire suivante : push(ENCsos(92)).

Un traitement particulier est appliqué à certaines instructions basiques non typées car dans leur cas on ne sait pas quelle fonction de décodage appliquer (celle propre au type entier ou celle propre au type référence). A cet effet, un mode de réalisation de l'invention prévoit d'appliquer, à la donnée stockée et manipulée, l'ensemble des fonctions de décodage propres aux différents types. Pour ainsi dire, on applique les deux fonctions de décodage DECa. et DECs- que l'on peut combiner de façon logique comme montré dans les exemples ci-après. En ce qui concerne l'instruction basique non typée <ifeq #offset> réalisant un saut de #offset instructions si la valeur au sommet de la pile OS est nulle, elle peut être réalisée par les instructions élémentaires suivantes : tmp=pop() if (tmp == ENCaos(0) II tmp == ENCsos(0)) jpc = jpc + #offset. De même, l'instruction basique non typée <ifne #offset> qui réalise un saut de #offset instructions si la valeur au sommet de la pile OS est non nulle peut être réalisée par les instructions élémentaires suivantes : tmp=pop() if (tmp != ENCaos(0) && tmp != ENCsos(0)) jpc = jpc + #offset. En revanche les instructions basiques Java non typées <dup> et <pop> ne requièrent aucune modification. Un grand nombre de fonction d'encodage (et réciproquement de décodage) peuvent être utilisées. On fournit ci-après un exemple simple à mettre en oeuvre dans lequel les fonctions d'encodage ajoutent au moins un bit (l'information supplémentaire de type) à la représentation binaire de la donnée à stocker, bit dont la valeur dépend du type associé à chacune des fonctions d'encodage. Dans cet exemple en particulier, la position d'ajout de l'au moins un bit dans la représentation binaire de la donnée à stocker dépend de la zone mémoire de stockage de ladite donnée. Dans le cas de dispositifs manipulant des données de granularité d'un octet, cet au moins un bit est codé sur un octet. Par conséquent, afin d'accroître la résistance de ces fonctions à des attaques par injection de faute visant la perturbation des données stockées (ici ledit bit représentant l'information supplémentaire de type), l'au moins un bit comprend de deux à huit bits, et notamment huit bits pour obtenir la robustesse maximale. En notant X=(X0, , Xn_i) la donnée manipulée (codée sur n bits, X, étant sa (i+1)-ème composante), l'exemple de fonctions de codage est le suivant: ENCaos :F2n Xn-i) - F2n+1 (X0, Xn-i) -> (0, Xo, xn-i) ENCsOS F2n - F2n+1 (X0, -> (1, xo, xn-i) ENCaLv : F2n - F2 n+1 (Xo, X1, Xn_i) -> (Xo, 0, X1, - - - , Xn-1) ENCsLy : F2n -> F2n+1 (Xo, X1, Xn_i) -> (Xo, 1, X1, - - - , Xn-1) ENCaOlA F2n -> F2n+1 (Xo, X1, X2, , Xn-1) (Xo, X1, 0, X2, - - - Xn-1) ENCsolA F2n -> F2n+1 (Xo, Xi , X2, - - - , Xn-1) (X0, X1, 1, X2, - - - , Xn-1) Les fonctions de décodage découlent directement de ces fonctions (par simple suppression du bit ajouté dès lors qu'il a la valeur attendue: "1" pour DECs- et "0" pour DECa-) Comme résumé dans la colonne « Invention - mode 1 » du tableau de la Figure 1, la mise en oeuvre de l'invention conformément aux enseignements généraux du premier mode de réalisation dont la Figure 3 est un exemple confère à l'environnement d'exécution Java Card une sécurité contre les différentes attaques par confusion de type listées précédemment. La Figure 4 illustre un second mode de réalisation de l'invention dans lequel l'étape d'association comprend l'indication de l'information supplémentaire de type associée à la donnée à stocker, dans une structure similaire à une première structure destinée à stocker ladite donnée dans la zone mémoire et à un emplacement correspondant à celui de stockage de ladite donnée dans la première structure. L'idée ici est de suivre continuellement l'information de type des données manipulées par la machine virtuelle Java JCVM en utilisant pour chaque structure de mémoire ne conservant pas l'information de type des données qu'elle stocke, une structure similaire reflétant ces informations de type. A cet effet, un agent compagnon abstrait peut être exécuté en même temps que la machine virtuelle Java Card, lequel compagnon abstrait duplique le comportement de la machine virtuelle, mais dans la structure dite similaire, en manipulant par exemple des booléens représentant l'information de type des données simultanément manipulées par la JCVM. Les trois zones mémoires OS, LV et OIA sont concernées par cette absence de mémorisation du type des données (dans BC, les valeurs sont figées en mémoire ROM). Concernant la pile d'opérandes OS, un pile abstrait des opérandes (la structure similaire est donc de même nature, pile, que la structure à augmenter, ici la pile OS) peut être prévue associée à la pile OS, laquelle pile abstraite évoluant de concert avec la pile OS mais pour uniquement garder trace du type des opérandes manipulées, par exemple entre un entier et une référence. De préférence, la pile abstraite des opérandes est créée dans la mémoire vive RAM. Un à huit bits (huit si la granularité des données dans la carte Java Card est d'un octer) peuvent être utilisés. Notamment un unique bit (i.e. booléen) peut être simplement utilisé pour distinguer les deux types critiques: entier (booléen à 0) et référence (booléen à 1). Dans ce cas, le surcoût mémoire maximal est de log2(N) où N est la taille maximale de la pile OS. Ainsi, lorsqu'un opérande de type référence est poussé sur la pile OS, une valeur spécifique représentative du type référence (par exemple le booléen 1) est poussée sur la pile abstraite des opérandes. De façon similaire, lorsqu'un opérande de type entier est poussé sur la pile OS par exemple par l'instruction <sload_0> (Figure 4a), une valeur spécifique représentative du type entier (par exemple le booléen 0) est poussée sur la pile abstraite des opérandes (AbOS sur la Figure). Pour permettre cette mise en oeuvre, les instructions basiques exécutées par la JCVM ont leur action répétée: une fois sur la pile OS régulière et une fois sur la pile d'abstraction. On notera que pour réduire le coût mémoire de cette mise en oeuvre, la première structure et ladite structure similaire sont des piles partageant un même indicateur de sommet de pile. En d'autres termes, puisque les deux piles (OS et pile abstraite) évolue de concert, le pointeur de sommet de pile OS peut être utilisé pour déterminer le pointeur de sommet de pile abstraite des opérandes. On évite ainsi l'espace mémoire nécessaire pour le deuxième pointeur, et les traitements correspondants. Ainsi, pour détecter un conflit de type et donc une attaque potentielle, l'utilisation de l'information supplémentaire de type comprend la comparaison de l'information supplémentaire de type stockée dans ladite structure similaire avec le type de l'instruction basique en cours d'exécution. En effet, l'information supplémentaire, éventuellement de type booléen, reflète le type de la donnée stockée correspondante. La manipulation de cette donnée par une instruction basique typée différemment ne devrait pas être autorisée. La détection d'un tel conflit peut permettre le déclenchement de fonctions de sécurité. Par exemple lorsqu'une instruction basique, par exemple <sstore_2>, demande à dépiler un opérande d'un type donné, un entier dans l'exemple des Figures 4b et 4c, depuis la pile OS, ce type donné est comparé à la valeur au sommet de la pile abstraite d'opérandes. Si les deux types sont identiques (intégrité conservée - Figure 4b), l'opérande est dépilée de la pile OS, et le type correspondant est dépilé de la pile abstraite. Sinon (Figure 4c), une erreur est remontée à la JCVM afin d'appliquer une règle de sécurité. On comprend donc que ce mode de réalisation de l'invention permet de sécuriser l'environnement d'exécution Java Card contre toutes les sortes d'attaques par confusion de type au niveau de la pile OS (Figure 1, colonne « Invention - mode 2 »). En outre, contrairement à la solution connue de ségrégation des types dans la pile OS, l'approche selon l'invention est entièrement compatible avec les instructions basiques non typées telles que <dup>, <pop>, <ifne> et <ifeq>. Malgré l'absence de type de ces instructions basiques, l'action de ces instructions doit également être répercutée sur la pile abstraite des opérandes afin de conserver une correspondance parfaite entre les entrées des deux piles OS et AbOS. Par exemple, si l'instruction <dup> (dupliquer l'opérande) est exécutée, l'information supplémentaire de type en haut de la pile AbOS doit aussi être dupliquée. Egalement, si l'instruction <ifeq> est exécutée, l'information supplémentaire de type en haut de la pile AbOS doit aussi être dépilée. Concernant la table LV, une approche similaire peut être utilisée, à savoir prévoir une table abstraite LV mémorisant, pour chaque entrée de LV, le type de la donnée mémorisée dans cette entrée. A noter que la table abstraite LV peut être créée directement en mémoire réinscriptible par le code de l'application (ou en mémoire ROM si elle est formée directement dans le code de l'application) puisque les types des paramètres et variables locales des méthodes sont connus dès l'écriture de l'application Java Card par le programmeur. Concernant la table OIA qui mémorise les instances de classe/objet, il s'agit de garder trace des types des attributs/champs de chacune de ces classes/objets. Or comme les différentes instances d'une même classe/objet contiennent des attributs/champs de même type, une seule structure similaire, dénommée instance abstraite de classe, est créée au chargement de la classe d'objets de sorte que toutes ses instances sont ensuite liées à l'instance abstraite de classe. Ainsi, une même structure similaire est utilisée pour stocker l'information supplémentaire de type des données stockées dans une pluralité de premières structures mémorisant les instances d'un même objet d'un langage de programmation orienté objet. L'instance abstraite de classe reprend donc la structure de la classe correspondante, où les champs sont chacun représentés par l'information supplémentaire de type (des attributs correspondants), par exemple par un bit valant soit 0 soit 1 selon que l'attribut est de type entier ou référence. Dans ce cas, le coût mémoire de l'instance abstraite de classe est de log2(N) où N est la taille d'une instance de la même classe. De façon similaire à ce qui précède, cette information supplémentaire de type dans l'instance abstraite de classe pour un attribut donné de la classe Java considérée est comparée au type de l'instruction basique exécutée afin de détecter un éventuel conflit. A noter que pour réduire le surcoût lié à cette vérification, seules les instructions basiques <putfield_s #i> et <getfield_a #i> peuvent être vérifiées. En effet, les autres instructions basiques sont indirectement vérifiées au niveau de la pile d'opérandes OS comme décrit ci-dessus. Cela s'avère suffisant pour garantir la sécurité de l'environnement d'exécution. A noter que l'instance abstraite de classe peut être créée directement en mémoire réinscriptible par le code de l'application (ou en mémoire ROM si elle est formée directement dans le code de l'application) puisque les types des attributs/champs des classes sont connus dès l'écriture de l'application Java Card par le programmeur. L'agent compagnon abstrait gérant les trois structures abstraites définies ci-dessus ne requiert pas de modification majeure de la machine virtuelle Java Card. Seul le coût mémoire de l'ordre de log2(N) pour chaque structure augmentée par une structure abstraite, avec N la taille de la structure considérée, peut s'avérer non négligeable en particulier pour des dispositifs dotés de peu de ressources. La Figure 5 illustre un troisième mode de réalisation de l'invention dans lequel une donnée est stockée dans la zone mémoire, et l'étape d'association comprend, immédiatement après le stockage de la donnée, le stockage d'une valeur prédéfinie (ou drapeau ou marqueur) dans la zone mémoire si la donnée stockée est d'un premier type, par exemple s'il s'agit d'un entier. Rien ne sera stocké si la donnée stockée est de type référence. Dans l'exemple illustré sur la Figure, la valeur prédéfinie (1100) est choisie hors de l'ensemble des références affectables à des instanciations d'objets compte tenu d'un nombre maximal (1024) d'instanciations simultanées d'objets. Ainsi, lorsqu'une nouvelle valeur « Int_1 » de type entier, quelle que soit sa valeur, est chargée dans la pile OS (<sload_1> par exemple), elle est stockée dans le haut de la pile, puis la valeur 1100 est stockée. En revanche, s'il s'agit de charger un nouvelle donnée « Ref 23 de type référence (<aload_2>), celle-ci est stockée dans le haut de pile sans que la valeur 1100 lui soit ajoutée.

La présence de cette valeur 1100 permet de détecter de façon aisée, sans modifier la structure (ici la pile OS) existante, si la prochaine donnée stockée est de type entier ou de type référence. Il suffit de vérifier la valeur du haut de pile. Un test sur la donnée de haut de pile permet de détecter qu'elle ne vaut pas 1100. La donnée stockée est donc de type référence et seule une instruction basique typée référence (<astore_4> dans l'exemple) doit être autorisée à manipuler cette donnée. En cas d'instruction basique typée entier, une erreur doit être levée permettant à la détection de l'attaque par confusion de type. Une fois la référence « Ref_2 » dépilée, la valeur suivante vaut 1100.

L'environnement virtuel ne doit alors autoriser qu'une instruction basique typée entier (<sstore_3>) pour manipuler la donnée suivante. Dans ce cas, la valeur 1100 est dépilée sans être utilisée permettant de dépiler effectivement la donnée entier « Int_1 » que l'instruction basique va manipuler. On voit bien que ce mode de réalisation de l'invention est compatible avec des instructions non typées. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.

Claims (28)

1. REVENDICATIONS1. Procédé de sécurisation d'un environnement d'exécution informatique comprenant une pluralité de zones mémoires prévues pour stocker des données manipulées par des instructions basiques de lecture ou écriture sur ces zones mémoires, les données manipulées pouvant être d'au moins deux types différents, caractérisé en ce qu'il comprend les étapes suivantes : associer, à des données à stocker dans une zone mémoire, une information supplémentaire de type représentative du type de ces données à stocker ; 10 et utiliser l'information de type associée à une donnée manipulée par une instruction basique en cours d'exécution, pour détecter un conflit de type entre la donnée manipulée et un type de l'instruction basique.
2. 2. Procédé de sécurisation selon la revendication 1, dans lequel l'étape 15 d'association comprend l'application, à la donnée à stocker, d'une fonction d'encodage propre au type de ladite donnée à stocker, les fonctions d'encodage propres aux deux types différents ayant valeur dans des ensembles distincts.
3. 3. Procédé de sécurisation selon la revendication 2, dans lequel la fonction d'encodage est également propre à la zone mémoire de stockage de ladite 20 donnée.
4. 4. Procédé de sécurisation selon la revendication 2 ou 3, dans lequel les fonctions d'encodage ajoutent au moins un bit à la représentation binaire de la donnée à stocker, bit dont la valeur dépend du type associé à chacune des fonctions d'encodage. 25
5. 5. Procédé de sécurisation selon la revendication 4, dans lequel la position d'ajout de l'au moins un bit dans la représentation binaire de la donnée à stocker dépend de la zone mémoire de stockage de ladite donnée.
6. 6. Procédé de sécurisation selon la revendication 4 ou 5, dans lequel l'au moins un bit comprend de deux à huit bits. 30
7. 7. Procédé de sécurisation selon l'une des revendications 2 à 6, dans lequel l'utilisation de l'information supplémentaire de type pour détecter un conflit de type comprend l'application, à la donnée stockée et manipulée par l'instruction basique en cours d'exécution, d'une fonction de décodage propre au type de l'instruction basique.
8. 8. Procédé de sécurisation selon la revendication 7, dans lequel la fonction de décodage est également propre à la zone mémoire stockant ladite donnée manipulée par l'instruction basique en cours d'exécution.
9. 9. Procédé de sécurisation selon l'une des revendications 2 à 8, dans lequel lorsque l'instruction basique en cours d'exécution est non typée, on applique, à la donnée stockée et manipulée, l'ensemble des fonctions de décodage propres aux différents types.
10. 10. Procédé de sécurisation selon la revendication 1, dans lequel l'étape d'association comprend l'indication de l'information supplémentaire de type associée à la donnée à stocker, dans une structure similaire à une première structure destinée à stocker ladite donnée dans la zone mémoire et à un emplacement correspondant à celui de stockage de ladite donnée dans la première structure.
11. 11. Procédé de sécurisation selon la revendication 10, dans lequel l'utilisation de l'information supplémentaire de type pour détecter un conflit de type comprend la comparaison de l'information supplémentaire de type stockée dans ladite structure similaire avec le type de l'instruction basique en cours d'exécution.
12. 12. Procédé de sécurisation selon la revendication 10 ou 11, dans lequel l'information supplémentaire de type dans ladite structure similaire comprend de un à huit bits.
13. 13. Procédé de sécurisation selon l'une des revendications 10 à 12, dans lequel la première structure et ladite structure similaire sont des piles partageant un même indicateur de sommet de pile.
14. 14. Procédé de sécurisation selon l'une des revendications 10 à 13, dans lequel une même structure similaire est utilisée pour stocker l'information supplémentaire de type des données stockées dans une pluralité de premières structures mémorisant les instances d'un même objet d'un langage de programmation orienté objet.
15. 15. Procédé de sécurisation selon la revendication 1, dans lequel une donnée est stockée dans la zone mémoire, et l'étape d'association comprend, immédiatement après le stockage de la donnée, le stockage d'une valeur prédéfinie dans la zone mémoire si la donnée stockée est d'un premier type.
16. 16. Procédé de sécurisation selon la revendication 15, dans lequel le premier type est le type entier.
17. 17. Procédé de sécurisation selon la revendication 15 ou 16, dans lequel la valeur prédéfinie est choisie hors de l'ensemble des références affectables à desinstanciations d'objets compte tenu d'un nombre maximal d'instanciations simultanées d'objets.
18. 18. Procédé de sécurisation selon l'une des revendications 15 à 17, dans lequel la donnée et la valeur prédéfinie sont stockées consécutivement dans une zone mémoire de type pile.
19. 19. Procédé de sécurisation selon l'une des revendications 1 à 18, dans lequel les deux types incluent le type entier et le type référence à un objet instancié dans l'environnement d'exécution.
20. 20. Procédé de sécurisation selon l'une des revendications 1 à 19, dans lequel les instructions basiques sont des bytecodes Java.
21. 21. Procédé de sécurisation selon l'une des revendications 1 à 20, dans lequel une zone mémoire de ladite pluralité est l'une parmi : une pile d'opérandes configurée pour stocker des opérandes et paramètres des instructions basiques lors de leurs exécutions ; une table de variables locales configurée pour stocker des paramètres et variables locales d'une méthode en cours d'exécution d'un langage de programmation orienté objet ; une zone d'instance d'objets configurée pour stocker les instances d'un objet d'un langage de programmation orienté objet.
22. 22. Produit programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur.
23. 23. Système de sécurisation d'un environnement d'exécution informatique comprenant une pluralité de zones mémoires prévues pour stocker des données manipulées par des instructions basiques de lecture ou écriture sur ces zones mémoires, les données manipulées pouvant être d'au moins deux types différents, caractérisé en ce qu'il comprend : un module d'association configuré pour associer, à chaque donnée à 30 stocker dans une zone mémoire, une information supplémentaire de type représentative du type de ladite donnée à stocker ; et un module de détection configuré pour utiliser l'information de type associée à une donnée manipulée par une instruction basique en cours d'exécution, de sorte à détecter un conflit de type entre la donnée manipulée et un type de l'instruction 35 basique.
24. 24. Système de sécurisation selon la revendication 23, dans lequel le module d'association est configuré pour appliquer, à la donnée à stocker, une fonction d'encodage propre au type de ladite donnée à stocker, les fonctions d'encodage propres aux deux types différents ayant valeur dans des ensembles distincts.
25. 25. Système de sécurisation selon la revendication 24, dans lequel les fonctions d'encodage sont conçues pour ajouter au moins un bit à la représentation binaire de la donnée à stocker, bit dont la valeur dépend du type associé à chacune des fonctions d'encodage.
26. 26. Système de sécurisation selon la revendication 23, dans lequel le module d'association est configuré pour appliquer indiquer l'information supplémentaire de type associée à la donnée à stocker, dans une structure similaire à une première structure destinée à stocker ladite donnée dans la zone mémoire et à un emplacement correspondant à celui de stockage de ladite donnée dans la première structure.
27. 27. Système de sécurisation selon la revendication 23, dans lequel le module d'association est configuré pour, immédiatement après le stockage d'une donnée dans la zone mémoire, stocker une valeur prédéfinie dans la zone mémoire si la donnée stockée est d'un premier type.
28. 28. Dispositif électronique sécurisé embarquant un environnement d'exécution Java Card et un système de sécurisation selon l'une des revendications 23 à 27.