Brevet FR3047584A1 — publié le 20170811

La présente invention concerne un système d'exploitation comportant un interpréteur qui permet une exécution d'applications, développées en langage orienté objet et compilées sous forme de code intermédiaire (dit « bytecode » en anglais) indépendant d'un matériel de carte électronique grâce auquel lesdites applications sont exécutées, qui soit résistante à des attaques par perturbation. L'invention est plus particulièrement adaptée au domaine des cartes à puce. Une carte à puce comporte au moins un circuit intégré capable de contenir et de traiter de l'information. Le circuit intégré, i.e. la puce, contient un microprocesseur ou microcontrôleur capable de traiter l'information, qui est stockée dans une mémoire non volatile. Le microprocesseur ou microcontrôleur permet d'implémenter un système d'exploitation qui assure le déroulement d'échanges d'informations et de traitements réalisés au sein de la carte puce. Le système d'exploitation définit un environnement d'exécution de code intermédiaire. Cet environnement d'exécution est appelé JCRE (« Java Card Runtime Environment » en anglais) en terminologie Java Card. Le système d'exploitation comporte un interpréteur permettant l'exécution du code intermédiaire d'applications, aussi dénommées applets, installées en mémoire non volatile sur la carte à puce. Cet interpréteur est parfois appelé machine virtuelle, JCVM (« Java Card Virtual Machine » en anglais) en terminologie Java Card. Le système d'exploitation comporte également un ensemble de librairies contenant les fonctions de base (APIs, pour « Application Programming Interfaces » en anglais) utiles au développement d'applications pour cartes à puce. On pourra notamment se référer aux spécifications « Java Card Classic Plateform », version 3.0.4. Certaines applications destinées à être exécutées au sein de la carte à puce sont écrites dans un langage de programmation orienté objet, par exemple Java, sont compilées, puis sont converties sous forme de fichiers qui contiennent un ensemble de composants représentant une version compacte des applications. Ces fichiers sont appelés fichiers CAP (« Converted APplets » en anglais) en terminologie Java Card. Parmi ces composants, on retrouve le composant des méthodes (« method component » en anglais) qui correspond à la version exécutable sous forme de code intermédiaire des méthodes implémentées dans une application. Alors que le code exécutable de l'application, issu de la compilation du code source et de sa conversion, est indépendant du matériel (processeur) sur lequel il est ensuite destiné à être exécuté, 3047584 2 l'interpréteur, qui est en charge de l'exécution du code de l'application, est exécuté directement par le processeur. La carte à puce est principalement utilisée comme moyens d'identification personnelle, ou de paiement, ou preuve d'abonnement à des services prépayés. Ainsi, 5 la carte à puce contient des données considérées comme confidentielles. Les cartes à puce peuvent ainsi faire l'objet d'attaques, qui ont pour finalité de récupérer ces données confidentielles. Ces attaques peuvent être physiques ou logiques. Les attaques logiques consistent à faire exécuter par le système d'exploitation, et plus particulièrement l'interpréteur, des applications malveillantes, qui contiennent par 10 exemple des séquences de code intermédiaire ne respectant pas les règles Java Card. Parmi les attaques physiques, il existe plus particulièrement des attaques dites par perturbation qui consistent à injecter de l'énergie sur un point précis de la puce à un instant précis, grâce par exemple à un laser ou une impulsion électromagnétique. Le point d'attaque et l'instant de l'attaque sont déterminés par l'attaquant pour que 15 l'énergie appliquée modifie l'état logique des instructions exécutées par l'interpréteur et/ou des données manipulées par l'interpréteur. Pour lutter contre des attaques par perturbation visant à modifier des données stockées en mémoire volatile ou non volatile, l'interface de programmation applicative Java Card 3.0.5 propose un mécanisme de sécurité permettant de créer des 20 tableaux « sensibles en intégrité », par le biais de la classe « SensitiveArrays ». Cette approche consiste à inclure à ces tableaux des éléments de contrôle d'intégrité respectifs. La vérification de ces éléments de contrôle d'intégrité doit être requise, manuellement, par le développeur de l'application au moment qui lui semble opportun dans le code source de l'application. Outre le fait que cette approche ne permet pas de 25 sécuriser tout type d'objet dans l'écriture du code source, mais seulement des tableaux, cette approche présente surtout l'inconvénient d'en laisser reposer la fiabilité sur le développeur de l'application lui-même. En effet, si le développeur de l'application ne prend pas garde à faire appel à la vérification des éléments de contrôle d'intégrité aux moments opportuns dans l'écriture du code source de l'application, la 30 fiabilité du mécanisme de sécurité s'en trouve remise en cause. L'écriture du code source est par conséquent particulièrement fastidieuse pour le développeur, la maintenance du code source s'en trouve complexifiée, et la place occupée par le code de l'application en mémoire non volatile s'en trouve augmentée. 3047584 3 Les problèmes décrits ci-dessus ne se limitent pas au contexte des cartes à puce. En effet, les mêmes problèmes se posent vis-à-vis de cartes électroniques, comme par exemple celles contenues dans les téléphones intelligents (« smartphones » en anglais) ou dans les ordinateurs, lorsque de telles cartes électroniques implémentent des 5 systèmes d'exploitation tels que susmentionnés. Il est souhaitable de pallier ces inconvénients de l'état de la technique. Il est plus particulièrement souhaitable de fournir une solution, résistante aux attaques par perturbation susmentionnées, de fiabilité renforcée. Il est plus particulièrement souhaitable de fournir une solution dont la fiabilité ne repose pas sur les développeurs 10 des applications à faire exécuter par l'interpréteur. A cet effet, l'invention concerne un procédé d'exécution d'une application, développée en langage orienté objet et compilée en code intermédiaire, le procédé étant mis en oeuvre par un système d'exploitation installé sur une carte électronique, le système d'exploitation comportant un interpréteur qui est un logiciel interprétant et 15 exécutant le code intermédiaire de l'application. Le procédé est tel que, lorsque l'interpréteur détecte un appel à une fonction dédiée du système d'exploitation dans le code intermédiaire de l'application vis-à-vis d'un objet à protéger de l'application ou d'une donnée membre à protéger dudit objet, le système d'exploitation met à jour des métadonnées associées audit objet de sorte à associer une donnée de vérification 20 d'intégrité de référence audit objet ou respectivement à ladite donnée membre. De plus, lorsque l'interpréteur détecte une manipulation ultérieure de l'objet protégé ou respectivement de ladite donnée membre protégée dans le code intermédiaire de l'application, le système d'exploitation détermine une valeur de donnée de vérification d'intégrité correspondant audit objet protégé en l'état ou respectivement de ladite 25 donnée membre protégée en l'état, et avant que l'interpréteur n'effectue ladite manipulation, le système d'exploitation vérifie que la valeur de donnée de vérification d'intégrité calculée concorde avec la valeur de donnée de vérification d'intégrité de référence. Ainsi, grâce à la donnée de vérification de référence, les manipulations des objets de l'application sont résistantes aux attaques par perturbation. La vérification 30 d'intégrité étant effectuée par le système d'exploitation, le développeur de l'application a un simple appel à ladite fonction dédiée à intégrer dans le code source de l'application après la création dudit objet et n'a pas à se soucier des moments où la vérification d'intégrité doit être effectuée. 3047584 4 Selon un mode de réalisation particulier, sur appel à ladite fonction dédiée dans le code intermédiaire de l'application vis-à-vis d'un objet à protéger de l'application ou d'une donnée membre à protéger dudit objet, le système d'exploitation met à jour les métadonnées associées audit objet de sorte à indiquer que ledit objet ou 5 respectivement ladite donnée membre est protégé(e). De plus, lors d'une manipulation ultérieure d'un objet ou respectivement d'une donnée membre d'un objet dans le code intermédiaire de l'application, le système d'exploitation vérifie si ledit objet ou respectivement ladite donnée membre est protégé(e), et si tel n'est pas le cas, le système d'exploitation n'effectue pas de vérification d'intégrité pour ledit objet ou 10 respectivement ladite donnée membre. Selon un mode de réalisation particulier, lorsque le code intermédiaire de l'application demande une modification d'un objet protégé ou d'une donnée membre protégée d'un objet, le système d'exploitation détermine en conséquence une nouvelle donnée de vérification d'intégrité de référence à associer audit objet protégé ou 15 respectivement à ladite donnée membre protégée. Selon un mode de réalisation particulier, lesdites métadonnées comprennent une référence pointant sur ladite donnée de vérification d'intégrité de référence. Selon un mode de réalisation particulier, l'interpréteur utilise une pile (« stack» en anglais) d'exécution pour empiler des variables d'exécution de l'application, à 20 laquelle est adjointe une pile (« stack» en anglais) de sécurité pour empiler en correspondance des données de vérification permettant de vérifier, avant leur manipulation, que les variables d'exécution de l'application n'ont pas été corrompues, et, lorsqu'une référence sur un objet protégé ou sur une donnée membre protégée d'un objet est placée dans la pile d'exécution, une référence sur la valeur d'intégrité 25 associée audit objet protégé ou à ladite donnée membre protégée est placée en correspondance dans la pile de sécurité, de telle sorte que, lorsque le système d'exploitation vérifie que la valeur de donnée de vérification d'intégrité calculée pour ledit objet protégé ou ladite donnée membre protégée concorde avec la valeur de donnée de vérification d'intégrité de référence, le système d'exploitation vérifie en 30 outre que la valeur de donnée de vérification d'intégrité calculée pour ledit objet protégé ou ladite donnée membre protégée concorde avec la valeur pointée par la référence correspondante placée sur la pile de sécurité. Selon un mode de réalisation particulier, la carte électronique est une carte à puce, l'application est une application Java Card, le système d'exploitation prend la 3047584 5 forme d'un environnement JCRE, et l'interpréteur prend la forme d'une machine virtuelle JCVM. L'invention concerne également une carte électronique configurée pour exécuter une application, développée en langage orienté objet et compilée en code 5 intermédiaire, le code intermédiaire étant exécuté par un interpréteur d'un système d'exploitation installé sur ladite carte électronique, l'interpréteur étant un logiciel interprétant et exécutant le code intermédiaire de l'application. La carte électronique est configurée pour que, lorsque l'interpréteur détecte un appel à une fonction dédiée du système d'exploitation dans le code intermédiaire de l'application vis-à-vis d'un 10 objet de l'application ou d'une donnée membre dudit objet, le système d'exploitation met à jour des métadonnées associées audit objet de sorte à associer une donnée de vérification d'intégrité de référence audit objet ou respectivement à ladite donnée membre, et, lorsque l'interpréteur détecte une manipulation ultérieure dudit objet ou respectivement de ladite donnée membre dans le code intermédiaire de l'application, 15 le système d'exploitation détermine une valeur de donnée de vérification d'intégrité correspondant audit objet ou respectivement de ladite donnée membre en l'état, et avant que l'interpréteur n'effectue ladite manipulation, le système d'exploitation vérifie que la valeur de donnée de vérification d'intégrité calculée concorde avec la valeur de donnée de vérification d'intégrité de référence associée audit objet ou 20 respectivement à ladite donnée membre. Selon un mode de réalisation particulier, ladite carte électronique est une carte à puce. L'invention concerne également un programme d'ordinateur, qui peut être stocké sur un support et/ou téléchargé d'un réseau de communication, afin d'être lu 25 par un processeur. Ce programme d'ordinateur comprend des instructions pour implémenter le procédé mentionné ci-dessus dans l'un quelconque de ses modes de réalisation, lorsque ledit programme est exécuté par le processeur. L'invention concerne également un support de stockage d'informations stockant un tel programme d' ordinateur. 30 Les caractéristiques de l'invention mentionnées ci-dessus ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints parmi lesquels: 3047584 6 - la Fig. 1 illustre schématiquement une architecture matérielle de dispositif, tel qu'une carte à puce, dans lequel la présente invention peut être implémentée ; - la Fig. 2A illustre schématiquement une modification d'un objet d'une application, afin de permettre à un système d'exploitation installé sur ledit dispositif, 5 de protéger ledit objet contre des attaques par perturbation ; - la Fig. 2B illustre schématiquement une alternative à la Fig. 2A ; et - la Fig. 3 illustre schématiquement un algorithme, implémenté par un interpréteur du système d'exploitation, de traitement de code intermédiaire de ladite application. 10 La description qui suit détaille plus particulièrement des modes de réalisation de la présente invention dans un contexte de carte à puce. Les principes décrits ici s'appliquent toutefois à d'autres types de carte électronique que les cartes à puce, comme par exemple les cartes électroniques contenues dans les téléphones intelligents ou dans les ordinateurs, lorsque de telles cartes électroniques implémentent des 15 systèmes d'exploitation comportant des interpréteurs respectifs dont le rôle est d'interpréter et d'exécuter un code intermédiaire obtenu par compilation d'applications développées en langage orienté objet. La Fig. 1 illustre schématiquement une architecture matérielle d'un dispositif 100, tel qu'une carte à puce, dans lequel la présente invention peut être implémentée. 20 Considérons plus particulièrement que le dispositif 100 est une carte à puce. La carte à puce 100 comporte une interface 110 configurée pour connecter la carte à puce 100 à un lecteur de carte (non représenté sur la Fig. 1). La carte à puce 100 est par exemple une carte bancaire et le lecteur de carte est un terminal de paiement. L'interface 110 est ainsi configurée pour permettre d'effectuer des échanges 25 de données entre le lecteur de carte et la carte à puce 100, notamment de permettre au lecteur de carte d'envoyer des commandes à la carte à puce 100, et aussi permettre au lecteur de carte d'alimenter en énergie la carte à puce 100. La carte à puce 100 comporte en outre un processeur, typiquement sous la forme d'un microcontrôleur [tC 111 ou d'un microprocesseur, en charge d'effectuer des 30 traitements au sein de la carte à puce 100 : calculs, transferts de données, etc. La carte à puce 100 comporte en outre une mémoire vive RAM (« Random Access Memory » en anglais) 112, une mémoire morte ROM (« Read Only Memory » en anglais) 113, et une mémoire non volatile, comme par exemple une mémoire EEPROM (« Electronically Erasable Programmable ROM » en anglais) 114. 3047584 7 Lorsque la carte à puce 100 est alimentée en énergie par le lecteur de carte via l'interface 110, le microcontrôleur !..tC 111 est capable d'exécuter des instructions, notamment sous forme de code intermédiaire, à partir de la mémoire morte ROM 113 et/ou de la mémoire EEPROM 114. 5 La mémoire morte ROM 113 contient typiquement des instructions causant l'implémentation d'un système d'exploitation, préférentiellement un environnement JCRE selon la technologie Java Card, en s'appuyant sur la mémoire vive RAM 112 pour créer, au moins, une pile (« stack » en anglais) d'exécution et pour stocker temporairement des données, telles que des données de vérification d'intégrité. 10 La mémoire EEPROM 114 contient typiquement des instructions d'applications installées sur la carte à puce 100, et plus particulièrement, lorsque l'application est instanciée, des objets desdites applications. Le contrôle de la création de ces objets et l'attribution d'espace mémoire pour manipuler ces objets sont réalisés par un interpréteur, préférentiellement une machine virtuelle JCVM de l'environnement 15 JCRE selon la technologie Java Card, en charge d'assurer l'exécution du code intermédiaire, lu depuis la mémoire EEPROM 114, des applications par le microcontrôleur !..tC 111. La manipulation des objets, dans le cadre de la présente invention, par l'interpréteur est décrite ci-après en relation avec la Fig. 3. A noter que, lorsque le système d'exploitation est implémenté sur une carte 20 électronique autre qu'une carte à puce, le microcontrôleur !..tC 111 est capable d'exécuter des instructions chargées dans la mémoire vive RAM 112 à partir de la mémoire morte ROM 113 et/ou de la mémoire EEPROM 114, une fois que ladite carte électronique est alimentée en énergie. La Fig. 2A illustre schématiquement une modification d'un objet d'une 25 application instanciée, afin de permettre à l'interpréteur, de protéger ledit objet contre des attaques par perturbation. Chaque application est développée en langage orienté objet, un objet étant une instance de classe. Le programmeur de l'application en question a la possibilité de décider que tel ou tel objet de l'application va devoir être protégé, ou que tel ou tel 30 autre objet de l'application n'a pas besoin d'être spécifiquement protégé. Pour ce faire, lorsque le développeur décide qu'un objet doit être protégé, le développeur appelle une fonction dédiée F du système d'exploitation dans le code source de l'application. L'appel à cette fonction dédiée F vis-à-vis dudit objet est préférentiellement réalisé immédiatement après la création de l'objet en question. 3047584 8 A partir de ce moment, le développeur de l'application n'a plus, dans l'écriture du code source de l'application, à s'inquiéter de la vérification de l'intégrité de l'objet. En effet, comme décrit ci-après en relation avec la Fig. 3, la vérification de l'intégrité de l'objet est à la charge du système d'exploitation et est donc transparente pour le 5 développeur. Une difficulté peut résider dans le fait que l'appel des méthodes de création (« byte code new ») et des méthodes d'initialisation (constructeurs) des objets peut être effectué par du code système inaccessible directement par le développeur au niveau applicatif. Dans un mode de réalisation particulier, pour prendre en compte ce 10 cas de figure, ladite fonction dédiée F est appelée dans le constructeur de la classe concernée. Ce constructeur étant défini dans le système d'exploitation et non dans l'application, ladite fonction dédiée F est toujours appelée pour les objets de ladite classe. Chaque objet étant constitué de données et de métadonnées système nécessaires 15 au fonctionnement de l'interpréteur, des métadonnées additionnelles sont ajoutées à tout objet lors de sa création. Deux métadonnées additionnelles sont ainsi ajoutées à tous les objets de l'application en question lors de leurs créations respectives. A la création de chaque objet, des métadonnées additionnelles sont ainsi associées audit objet, ces métadonnées additionnelles contenant respectivement des valeurs par défaut 20 qui indiquent que l'objet en question n'est (par défaut) pas protégé. Lorsqu'un objet 200 est à protéger, l'interpréteur détecte ainsi l'appel à ladite fonction dédiée F qui a été inséré à cet effet dans le code source de l'application par le développeur. L'interpréteur fait alors appel au système d'exploitation afin de modifier la valeur des métadonnées additionnelles 220 qui sont associées à l'objet 200 à 25 protéger. Ces métadonnées 220 comportent alors : un marqueur 221, indiquant que pendant l'exécution de l'application, l'objet 200 en question est un objet protégé ; et une donnée de vérification d'intégrité 222. La donnée de vérification d'intégrité est par exemple une somme de contrôle de redondance cyclique CRC (« Cyclic Redundancy Checksum » en anglais), ou une 30 duplication de donnée de l'objet 200, ou toute autre donnée permettant de vérifier l'intégrité de l'objet 200 en question. Au cours de l'exécution de ladite fonction dédiée F, le système d'exploitation applique en conséquence une règle prédéfinie pour déterminer la valeur de la donnée de vérification d'intégrité à associer à l'objet en question. La donnée de vérification d'intégrité déterminée à cet instant sert 3047584 9 ultérieurement de référence lorsque l'objet en question est manipulé par l'interpréteur en cours d'exécution de l'application à laquelle ledit objet appartient. Dans un mode de réalisation préférentiel, les métadonnées 220 n'incluent pas directement la donnée de vérification d'intégrité susmentionnée, mais une référence 5 (i.e. une information de localisation mémoire) pointant sur ladite donnée de vérification d'intégrité, qui est alors stockée ailleurs en mémoire. C'est cette situation qui est représentée sur la Fig. 2A, où les métadonnées 220 incluent une référence 222 pointant sur une donnée de vérification d'intégrité 230. Suite à l'exécution de ladite fonction dédiée F, l'interpréteur obtient ainsi, grâce 10 aux opérations décrites ci-dessus, un nouvel objet 210 contenant l'objet 200 (comportant les métadonnées système) qui était à protéger ainsi que, en association avec ledit objet 200, les métadonnées additionnelles 220. Lorsque les objets ainsi créés sont stockés dans la mémoire EEPROM 114, les métadonnées additionnelles desdits objets sont aussi stockées dans la mémoire 15 EEPROM 114. Les données de vérification d'intégrité peuvent, dans ce cas, être aussi stockées dans la mémoire EEPROM 114 à la création de l'objet en question, mais sont préférentiellement stockées en mémoire vive RAM 112 pour permettre à l'interpréteur de pouvoir y accéder plus rapidement. Lorsque les objets ainsi créés sont stockés en mémoire vive RAM 112, les métadonnées additionnelles desdits objets sont 20 préférentiellement stockées dans la mémoire EEPROM 114. Le système d'exploitation regroupe alors dans une structure de données auxiliaire les métadonnées dans la mémoire EEPROM 114 et l'adresse physique des données utilisateurs, et donc des objets en question, en mémoire RAM 112. Les données de vérification d'intégrité peuvent, dans ce cas, être aussi stockées dans la mémoire EEPROM 114 à la création 25 de l'objet en question, mais peuvent, en variante, être stockées en mémoire vive RAM 112 pour permettre à l'interpréteur de pouvoir y accéder plus rapidement. D'une manière générale, les données de vérification sont stockées dans une mémoire d'accès au moins aussi rapide que l'accès à la mémoire dans laquelle sont stockés les objets auxquels lesdites données de vérification s'appliquent. 30 La Fig. 2B illustre schématiquement une alternative à la Fig. 2A. Chaque objet comporte une pluralité de données membres. Sur la Fig. 2B, les données membres de l'objet 200 sont schématiquement délimitées par des pointillés. Comme décrit ci-dessus, des métadonnées additionnelles 260 sont ajoutées à l'objet 200 pour permettre de protéger l'objet 200 contre des attaques par perturbation. 3047584 10 Ces métadonnées additionnelles 260 comportent alors un ensemble 261 de M marqueurs, par exemple sous la forme d'un champ de N bits, où N représente la quantité de données membres qui composent l'objet 200 et M (M REVENDICATIONS1) Procédé d'exécution d'une application développée en langage orientée objet et compilée en code intermédiaire, le procédé étant mis en oeuvre dans un système d'exploitation installé sur une carte électronique (100), le système d'exploitation comportant un interpréteur qui est un logiciel interprétant et exécutant le code intermédiaire de l'application, caractérisé en ce que, lorsque l'interpréteur détecte un appel à une fonction dédiée du système d'exploitation dans le code intermédiaire de l'application vis-à-vis d'un objet à protéger de l'application ou d'une donnée membre à protéger dudit objet, le système d'exploitation met à jour des métadonnées (220 ; 260) associées audit objet de sorte à associer une donnée de vérification d'intégrité (230 ; 271 ; 272 ; 273) de référence audit objet ou respectivement à ladite donnée membre, et en ce que, lorsque l'interpréteur détecte une manipulation ultérieure de l'objet protégé ou respectivement de ladite donnée membre protégée dans le code intermédiaire de l'application, le système d'exploitation détermine (305) une valeur de donnée de vérification d'intégrité correspondant audit objet protégé en l'état ou respectivement de ladite donnée membre protégée en l'état, et avant que l'interpréteur n'effectue ladite manipulation, le système d'exploitation vérifie (306) que la valeur de donnée de vérification d'intégrité calculée concorde avec la valeur de donnée de vérification d'intégrité de référence. 2) Procédé selon la revendication 1, caractérisé en ce que, sur appel à ladite fonction dédiée dans le code intermédiaire de l'application vis-à-vis d'un objet à protéger de l'application ou d'une donnée membre à protéger dudit objet, le système d'exploitation met à jour (311) les métadonnées (221 ; 261) associées audit objet de sorte à indiquer que ledit objet ou respectivement ladite donnée membre est protégé(e), et en ce que, lors d'une manipulation ultérieure d'un objet ou respectivement d'une donnée membre d'un objet dans le code intermédiaire de l'application, le système d'exploitation vérifie (304) si ledit objet ou respectivement ladite donnée membre est protégé(e), et si tel n'est pas le cas, le système d'exploitation n'effectue pas de vérification d'intégrité pour ledit objet ou respectivement ladite donnée membre. 3047584 16 3) Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que, lorsque le code intermédiaire de l'application demande une modification d'un objet protégé ou d'une donnée membre protégée d'un objet, le système d'exploitation 5 détermine (309) en conséquence une nouvelle donnée de vérification d'intégrité de référence à associer audit objet protégé ou respectivement à ladite donnée membre protégée. 4) Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce 10 que lesdites métadonnées comprennent une référence (222 ; 262) pointant sur ladite donnée de vérification d'intégrité de référence. 5) Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'interpréteur utilise une pile d'exécution pour empiler des variables d'exécution 15 de l'application, à laquelle est adjointe une pile de sécurité pour empiler en correspondance des données de vérification permettant de vérifier, avant leur manipulation, que les variables d'exécution de l'application présentes dans la pile d'exécution n'ont pas été corrompues, et en ce que, lorsqu'une référence à un objet protégé ou à une donnée membre 20 protégée d'un objet est placée dans la pile d'exécution, une référence sur la valeur d'intégrité associée audit objet protégé ou à ladite donnée membre protégée est placée en correspondance dans la pile de sécurité, de telle sorte que, lorsque le système d'exploitation vérifie (306) que la valeur de donnée de vérification d'intégrité calculée pour ledit objet protégé ou ladite donnée membre protégée concorde avec la valeur de 25 donnée de vérification d'intégrité de référence, le système d'exploitation vérifie en outre que la valeur de donnée de vérification d'intégrité calculée pour ledit objet protégé ou ladite donnée membre protégée concorde avec la valeur pointée par la référence correspondante placée sur la pile de sécurité. 30 6) Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que la carte électronique est une carte à puce, l'application est une application Java Card, le système d'exploitation prend la forme d'un environnement JCRE, et l'interpréteur prend la forme d'une machine virtuelle JCVM. 3047584 17 7) Produit programme d'ordinateur, caractérisé en ce qu'il comporte des instructions causant l'implémentation, par une carte électronique, du procédé selon l'une quelconque des revendications 1 à 6, lorsque lesdites instructions sont exécutées par un processeur de ladite carte électronique. 5 8) Support de stockage d'informations, caractérisé en ce qu'il stocke un programme d'ordinateur selon la revendication 7. 9) Carte électronique (100) configurée pour exécuter une application développée 10 dans un langage orienté objet et compilée en code intermédiaire, le code intermédiaire étant exécuté par un interpréteur d'un système d'exploitation installé sur ladite carte électronique, l'interpréteur étant un logiciel interprétant et exécutant le code intermédiaire de l'application, caractérisée en ce que la carte électronique est configurée pour que, lorsque 15 l'interpréteur détecte un appel à une fonction dédiée du système d'exploitation dans le code intermédiaire de l'application vis-à-vis d'un objet de l'application ou d'une donnée membre dudit objet, le système d'exploitation met à jour des métadonnées (220 ; 260) associées audit objet de sorte à associer une donnée de vérification d'intégrité de référence (230 ; 271 ; 272 ; 273) audit objet ou respectivement à ladite 20 donnée membre, et en ce que, lorsque l'interpréteur détecte une manipulation ultérieure dudit objet ou respectivement de ladite donnée membre dans le code intermédiaire de l'application, le système d'exploitation détermine (305) une valeur de donnée de vérification d'intégrité correspondant audit objet ou respectivement de ladite donnée 25 membre en l'état, et avant que l'interpréteur n'effectue ladite manipulation, le système d'exploitation vérifie (306) que la valeur de donnée de vérification d'intégrité calculée concorde avec la valeur de donnée de vérification d'intégrité de référence associée audit objet ou respectivement à ladite donnée membre. 30 10) Carte électronique selon la revendication 9, caractérisée en ce que ladite carte électronique est une carte à puce.