Brevet FR3069670A1 — publié le 20190201

DOMAINE DE L'INVENTION La présente invention concerne un pare-feu logiciel installé sur une carte électronique, telle qu'une carte à puce, sur laquelle plusieurs profils d'utilisation coexistent. La présente invention concerne aussi un procédé implémenté par un tel pare-feu logiciel. ETAT DE LA TECHNIQUE 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 (dit « bytecode » en anglais) indépendant d'un matériel de carte à puce grâce auquel des applications, dites applets, sont exécutées. Cet environnement d'exécution est appelé JCRE (« Java Card Runtime Environment » en anglais) en terminologie Java Card, qui est une technologie largement répandue dans la conception des cartes à puce. Le système d'exploitation comporte un interpréteur permettant l'exécution du code intermédiaire des applets installées en mémoire non volatile sur la carte à puce. Cet interpréteur est 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' applets pour cartes à puce. Pour de plus amples détails sur la technologie Java Card, on pourra notamment se référer aux spécifications « Java Card Classic Plateform », version 3.0.4. Les cartes à puce sont principalement utilisées comme moyens d'identification personnelle, ou de paiement, ou de preuve d'abonnement à des services prépayés. Ainsi, les cartes à puce contiennent typiquement 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 exemple des séquences frauduleuses de code intermédiaire. Il existe des pare-feu logiciels qui assurent des vérifications de droits d'accès entre 5 contextes d'exécution des applets, de sorte à n'autoriser l'accès à une applet cible dans un contexte par une autre applet dans un autre contexte que si l'applet cible offre une interface partagée (« shareable interface » en anglais). Cependant de tels pare-feu logiciels ne sont pas adaptés à prendre en compte des situations dans lesquelles l'applet cible n'offrirait une interface partagée qu'a un sous-ensemble des autres applets 10 exécutées sur la carte à puce. Ce cas de figure se présente notamment lorsque l'utilisation d'une carte à puce est partagée par plusieurs services d'opérateurs distincts. On peut citer par exemple le cas d'une carte SIM (« Subscriber Identity Module » en anglais) permettant d'accéder à des services de téléphonie offerts par des opérateurs distincts. Les droits d'accès offerts par l'interface partagée fournie par une applet 15 seraient alors distincts selon si l'applet est accédée via une autre applet provenant du même opérateur ou si l'applet est accédée via une autre applet provenant d'un autre opérateur, auquel cas une certaine herméticité doit être assurée de manière à éviter d'offrir la possibilité qu'un opérateur ne vienne récupérer ou polluer les données d'un autre opérateur. D'autres exemples d'utilisation d'une carte à puce dans un cadre multi- 20 service peuvent être construits sur le même modèle. De plus, 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 25 des systèmes d'exploitation tels que susmentionnés. EXPOSE DE L'INVENTION 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 logiques 30 susmentionnées, de fiabilité renforcée. A cet effet, l'invention concerne un procédé de vérification d'exécution d' applets développées en langage orienté objet et compilées en code intermédiaire, le procédé étant implémenté par un pare-feu logiciel d'un système d'exploitation installé dans un composant électronique ou sur une carte électronique, le système d'exploitation 3 comportant un interpréteur qui est un logiciel interprétant et exécutant le code intermédiaire des applets, chaque applet étant associée à un unique contexte, chaque contexte étant associé à une ou plusieurs applets. Chaque contexte est associé à un unique profil d'utilisation parmi plusieurs profils d'utilisation, chaque profil 5 d'utilisation est associé à un ou plusieurs contextes. Lorsque le pare-feu logiciel est informé par l'interpréteur d'un accès depuis une première applet vers une seconde applet, le pare-feu logiciel effectue les étapes suivantes : déterminer un profil source de l'accès, qui est le profil associé au contexte auquel est associée la première applet ; déterminer un profil destinataire de l'accès, qui est le profil associé au contexte auquel 10 est associée la seconde applet ; vérifier si le profil source de l'accès est identique au profil destinataire de l'accès ; lorsque le profil source de l'accès n'est pas identique au profil destinataire de l'accès, refuser l'accès ; et lorsque le profil source de l'accès est identique au profil destinataire de l'accès, appliquer des règles de vérification d'accès entre contextes. 15 Ainsi, grâce à la définition de la notion de profil d'utilisation intégrant la notion de contexte, et grâce au comportement du pare-feu logiciel face à un accès entre applets, les données d'un profil d'utilisation sont protégées d'un accès en provenance d'un autre profil d'utilisation. Selon un mode de réalisation particulier, l'accès fait référence soit à une donnée 20 statique, soit à une donnée non statique, soit à une méthode Selon un mode de réalisation particulier, un desdits profils d'utilisation est un profil particulier, appelé profil système, géré distinctement des autres profils d'utilisation par le pare-feu logiciel, de telle sorte que, lorsque le profil source de l'accès est le profil système, le pare-feu logiciel applique les règles de vérification d'accès entre 25 contextes, et lorsque le profil destinataire de l'accès est le profil système, le pare-feu logiciel refuse l'accès. L'invention concerne également un pare-feu logiciel configure pour effectuer une vérification d'exécution d'applets développées en langage orienté objet et compilées en code intermédiaire, le pare-feu logiciel étant destiné à appartenir à un système 30 d'exploitation destiné à être installé dans un composant électronique ou sur une carte électronique, le système d'exploitation comportant un interpréteur qui est un logiciel interprétant et exécutant le code intermédiaire des applets, chaque applet étant associée à un unique contexte, chaque contexte étant associé à une ou plusieurs applets. Chaque contexte est associé à un unique profil d'utilisation parmi plusieurs profils d'utilisation, chaque profil d'utilisation est associé à un ou plusieurs contextes. Lorsque le pare-feu logiciel est informé par l'interpréteur d'un accès depuis une première applet vers une seconde applet, le pare-feu logiciel effectue les étapes suivantes : déterminer un profil source de l'accès, qui est le profil associé au contexte auquel est associée la première 5 applet ; déterminer un profil destinataire de l'accès, qui est le profil associé au contexte auquel est associée la seconde applet ; vérifier si le profil source de l'accès est identique au profil destinataire de l'accès ; lorsque le profil source de l'accès n'est pas identique au profil destinataire de l'accès, refuser l'accès ; et lorsque le profil source de l'accès est identique au profil destinataire de l'accès, appliquer des règles de vérification 10 d'accès entre contextes. L'invention concerne également une carte électronique comportant un système d'exploitation intégrant un pare-feu logiciel tel qu'abordé ci-dessus, configure pour effectuer une vérification d'exécution d'applets développées en langage orienté objet et compilées en code intermédiaire. 15 Selon un mode de réalisation particulier, la carte électronique est une carte à puce. Selon un mode de réalisation particulier, la carte à puce est une carte SIM et les profils d'utilisation sont respectivement associés à des services de téléphonie d'opérateurs distincts. L'invention concerne également un composant électronique comportant un 20 système d'exploitation intégrant un pare-feu logiciel tel qu'abordé ci-dessus, configure pour effectuer une vérification d'exécution d'applets développées en langage orienté objet et compilées en code intermédiaire. LISTE DES FIGURES 25 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: - la Fig. lA illustre schématiquement une architecture matérielle d'une carte à 30 puce, dans laquelle la présente invention peut être implémentée ; - la Fig. 1B illustre schématiquement une architecture matérielle d'un composant électronique, dans lequel la présente invention peut être implémentée ; - la Fig. 2 illustre schématiquement une organisation logicielle implémentée par la carte à puce ; - la Fig. 3 illustre schématiquement une gestion d'accès entre des applets appartenant à des contextes distincts, selon un premier mode de réalisation ; - la Fig. 4 illustre schématiquement une gestion d'accès entre des applets appartenant à des contextes distincts, selon un second mode de réalisation ; 5 - la Fig. 5A illustre schématiquement un algorithme, implémenté par le pare-feu logiciel, de traitement d'un accès entre applets, selon le premier mode de réalisation ; et - la Fig. 5B illustre schématiquement un algorithme, implémenté par le pare-feu logiciel, de traitement d'un accès entre applets, selon le second mode de réalisation. 10 DESCRIPTION DETAILLEE DE MODES DE REALISATION La Fig. lA illustre schématiquement une architecture matérielle d'une carte à puce eUICC (« embedded Universal Integrated Circuit Card » en anglais), dans laquelle la présente invention peut être implémentée. Bien que l'invention soit présentée dans 15 au moins un mode de réalisation détaillé dans le cadre d'une mise en oeuvre de carte à puce, la présente invention s'applique aussi plus généralement dans le cadre d'une mise en oeuvre de carte électronique. La carte à puce eUICC comporte une interface IF configurée pour connecter la carte à puce eUICC à un lecteur de carte (non représenté sur la Fig. 1A). La carte à puce 20 eUICC est par exemple une carte SIM (« Subscriber Identity Module » en anglais) multi-opérateur et le lecteur de carte est inclus dans un terminal de téléphonie mobile. La carte à puce eUICC peut aussi être une carte bancaire multi-service et le lecteur de carte est inclus dans un terminal bancaire, ou une carte de fidélité multi-vendeur et le lecteur de carte est inclus dans un système de caisse enregistreuse. D'une manière 25 générale, la présente invention peut être implémentée au sein d'une carte électronique, préférentiellement une carte à puce, pour laquelle différents profils d'utilisation parallèles sont requis. L'interface IF est ainsi configurée pour permettre d'effectuer des échanges de données entre le lecteur de carte et la carte à puce eUICC, notamment pour permettre 30 au lecteur de carte d'envoyer des commandes à la carte à puce eUICC, et aussi pour permettre au lecteur de carte d'alimenter en énergie la carte à puce eUICC. La carte à puce eUICC comporte en outre un processeur, typiquement sous la forme d'un microcontrôleur [if ou d'un microprocesseur, en charge d'effectuer des traitements au sein de la carte à puce eUICC : calculs, traitements et transferts de données, etc. La carte à puce eUICC comporte en outre une mémoire volatile, telle qu'une mémoire vive RAM (« Random Access Memory » en anglais), ainsi qu'au moins une 5 mémoire non volatile, telle qu'une mémoire morte ROM (« Read Only Memory » en anglais) et une mémoire EEPROM (« Electronically Erasable Programmable ROM » en anglais) ou une mémoire FLASH. Lorsque la carte à puce eUICC est alimentée en énergie par le lecteur de carte via l'interface IF, le microcontrôleur[tC est capable d'exécuter des instructions, notamment 10 sous forme de code intermédiaire, à partir de la mémoire morte ROM et/ou de la mémoire EEPROM. La mémoire morte ROM et/ou la mémoire EEPROM contiennent 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 15 s'appuyant sur la mémoire non volatile 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 applicatives. La mémoire EEPROM contient typiquement des instructions d'applications, appelées applets, installées sur la carte à puce eUICC, et plus particulièrement, lorsque 20 l'application est instanciée, des objets desdites applications. Les applets sont développées en langage orienté objet et compilées en code intermédiaire. 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 (« Java Card Virtual Machine » en anglais) de l'environnement JCRE selon la 25 technologie Java Card, en charge d'assurer l'exécution du code intermédiaire, lu depuis la mémoire EEPROM, des applications par le microcontrôleur[tC. A noter que, lorsque le système d'exploitation est implémenté sur une carte électronique autre qu'une carte à puce, le microcontrôleur 1..tC est capable d'exécuter des instructions chargées dans la mémoire vive RAM à partir de la mémoire morte ROM 30 et/ou de la mémoire EEPROM, une fois que ladite carte électronique est alimentée en énergie. La Fig. 1B illustre schématiquement une architecture matérielle d'un composant électronique iUICC (« integrated Universal Integrated Circuit Card » en anglais), dans lequel la présente invention peut être implémentée. La Fig. 1B correspond à une architecture connue sous le nom de SoC (« System on Chip » en anglais). L'architecture présentée sur la Fig. 1B est très proche de celle présentée sur la Fig. lA et diffère essentiellement en ce qu'elle est intégrée dans un unique composant électronique. Ainsi, le composant électronique iUICC comporte une interface IF2 configurée pour connecter 5 le composant électronique iUICC à d'autres composants électroniques sur une carte électronique, typiquement via un bus de communication. Le composant électronique iUICC comporte en outre un coeur processeur, typiquement sous la forme d'un coeur microcontrôleur !..tC2, en charge d'effectuer des traitements au sein du composant électronique iUICC : calculs, traitements et transferts 10 de données, etc. Le composant électronique iUICC comporte en outre une mémoire volatile, telle qu'une mémoire vive RAM2, ainsi qu'au moins une mémoire non volatile, telle qu'une mémoire morte ROM2. Lorsque le composant électronique iUICC est alimenté en énergie, le coeur 15 microcontrôleur !..tC2 est capable d'exécuter des instructions, notamment sous forme de code intermédiaire, à partir de la mémoire morte ROM2. La mémoire morte ROM2 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 non volatile RAM2 pour créer, au moins, une pile 20 (« stack » en anglais) d'exécution et pour stocker temporairement des données, telles que des données applicatives. La mémoire ROM2 contient typiquement des instructions d'applications, appelées applets, et plus particulièrement, lorsque l'application est instanciée, les objets desdites applications sont stockés dans la mémoire vive RAM2. La Fig. 2 illustre schématiquement une organisation logicielle implémentée par 25 la carte à puce eUICC ou par le composant électronique iUICC. Une interface matérielle-logicielle (« hard-soft interface » en anglais) 250 permet de contrôler la carte à puce eUICC ou le composant électronique iUICC, en tant qu'entité matérielle, grâce à des instructions logicielles en provenance de ladite organisation logicielle. Ladite organisation logicielle comporte une partie de système d'exploitation 30 HOSTOS adaptée à l'entité matérielle, afin de permettre à une autre partie du système d'exploitation constituée de l'environnement JCRE de faire fonctionner la carte à puce eUICC. La partie de système d'exploitation HOSTOS permet de rendre l'environnement JCRE indépendant de la structure effective de l'entité matérielle. L'environnement JCRE contient notamment la machine virtuelle JCVM, ainsi qu'un pare-feu logiciel FW (« software Firewall » en anglais). Les services de l'environnement JCRE sont utilisés par des applications APP, appelées applets, chacune créée au sein d'un contexte donné. Chaque contexte inclut une ou plusieurs applets. En 5 terminologie Java Card, les contextes sont dénommés packages. En d'autres termes, les applets sont organisées en espaces de noms (« namespaces » en anglais) qui définissent ainsi un contexte d'exécution desdites applets. D'après la technologie Java Card, le pare-feu logiciel FW applique certaines règles de vérification d'accès lorsqu'une première applet tente de faire un accès (appel, 10 lecture ou écriture) à une seconde applet appartenant à un contexte (ou package) différent. Le pare-feu logiciel FW vérifie alors notamment auprès de la seconde applet que ladite seconde applet fournit une interface partagée et autorise ainsi un accès en provenance de la première applet. D'autres règles de vérification d'accès entre contextes peuvent être définies. 15 Dans le cadre de la présente invention, le pare-feu logiciel FW dispose de fonctionnalités complémentaires, de manière à permettre une gestion multi-profil et empêcher que des accès indésirables ne soient exécutés depuis une applet d'un premier profil d'utilisation vers une applet d'un second profil d'utilisation. Le comportement du pare-feu logiciel FW est détaillé ci-après en relation avec la Fig. 5A dans un premier 20 mode de réalisation. Il peut toutefois exister un profil d'utilisation particulier (profil système), géré distinctement par le pare-feu logiciel FW, avec des droits d'accès propres aux autres profils d'utilisation (profils ordinaires). Cet aspect correspond à un second mode de réalisation détaillé ci-après en relation avec la Fig. 5B. Dans le cadre de la présente invention, on entend par tentative d'accès par une 25 première applet à une seconde applet l'une quelconque des actions suivantes : le fait qu'un objet de la première applet tente de lire ou d'écrire dans une donnée statique d'objets de la seconde applet ; le fait qu'un objet de la première applet tente de lire ou d'écrire dans une données non statique d'un objet de la seconde applet ; et le fait qu'un objet de la première applet tente de faire appel à une méthode d'un objet de la seconde 30 applet. L'accès fait donc référence soit à une donnée statique, soit à une données non statique, soit à une méthode. Le pare-feu logiciel FW permet ainsi de gérer des situations multi-profil, c'est-à-dire lorsque plusieurs profils d'utilisation coexistent au sein d'une même carte à puce ou d'un même composant électronique. Une telle situation multi-profil se retrouve par 9 exemple lorsqu'une carte SIM permet d'accéder à des services de téléphonie offerts par des opérateurs distincts. Un profil d'utilisation est alors associé à chaque opérateur sur la carte SIM, et un profil d'utilisation peut être sélectivement activé parmi les différents profils d'utilisation de manière à pouvoir accéder aux services de téléphonie de 5 l'opérateur auquel ledit profil d'utilisation est associé. Le pare-feu logiciel FW permet d'assurer que les applets du profil actif ne viennent pas accéder ou modifier les données des autres profils d'utilisation. Il convient de noter que, sur la carte à puce eUICC ou dans le composant électronique iUICC, un seul contexte et un seul profil (celui dans lequel s'inscrit le 10 contexte en question) ne sont actifs à la fois. Les autres contextes et les autres profils sont créés, mais inactifs. Des changements sélectifs de profils interviennent au cours de l'utilisation de la carte à puce eUICC ou du composant électronique iUICC, par exemple lorsqu'un utilisateur de ladite carte à puce eUICC ou du composant iUICC bascule d'un service de téléphonie souscrit auprès d'un opérateur vers un autre service de téléphonie 15 souscrit auprès d'un autre opérateur, ou lorsque l'utilisateur de ladite carte à puce eUICC ou du composant électronique iUICC bascule d'un service fourni par un premier vendeur vers un service fourni par un autre vendeur. A noter aussi que des basculements de profil peuvent être réalisés manuellement ou automatiquement. Le profil actif jusqu'alors devient inactif, et un profil jusqu'alors inactif devient actif. 20 La Fig. 3 illustre schématiquement une gestion d'accès entre des applets appartenant à des contextes distincts, selon le premier mode de réalisation. De manière illustrative, sur la Fig. 3, deux profils d'utilisation PA et PB sont présentés. Par exemple, considérons que les profils d'utilisation PA et PB sont utilisés dans le contexte de la carte à puce eUICC, et que la carte à puce eUICC est une carte 25 SIM. Les profils PA et PB correspondent alors à des souscriptions de services de téléphonie auprès d'opérateurs distincts ou à des souscriptions de services de téléphonie pour des noms d'utilisateur distincts. Le profil PA contient un premier contexte CA1 et un second contexte CA2. Le premier contexte CA1 contient une applet AA1 et une applet AA2. Le second contexte 30 CA2 contient une applet AA4 et une applet AA5. Le profil PA contient en outre un troisième contexte JA destiné aux applets instanciées par l'environnement JCRE lorsque le profil PA est actif. Sur la Fig. 3, le troisième contexte JA contient une applet AA3. Le profil PA peut contenir en outre des données statiques SA destinées aux différents contextes du profil PA. 10 Le profil PB contient un quatrième contexte CB1 et un cinquième contexte CB2. Le quatrième contexte CB1 contient une applet AB1 et une applet AB2. Le cinquième contexte CB2 contient une applet AB5. Le profil PB contient en outre un sixième contexte JB destiné aux applets instanciées par l'environnement JCRE lorsque le profil 5 PB est actif Sur la Fig. 3, le sixième contexte JB contient une applet AB3 et une applet AB4. Le profil PB peut contenir en outre des données statiques SB destinées aux différents contextes du profil PB. Lorsqu'un accès est effectué entre applets au sein d'un même profil d'utilisation (intra-profil), le pare-feu logiciel FW applique les règles de vérification d'accès entre 10 contextes, c'est-à-dire notamment les règles de vérification d'accès usuelles déjà évoquées de la technologie Java Card (telles qu'on les retrouve dans les spécifications « Java Card Classic Plateform », version 3.0.4). Le pare-feu logiciel FW vérifie alors auprès de l'applet ciblée que ladite applet ciblée fournit une interface partagée et que ladite applet ciblée autorise ainsi un accès en provenance d'une autre applet. 15 Lorsqu'un accès est effectué depuis une première applet appartenant à un premier profil d'utilisation (e.g. le profil PB) vers une seconde applet appartenant à un second profil d'utilisation (e.g. le profil PA), le pare-feu logiciel FW refuse l'accès, même si la seconde applet fournit une interface partagée et autorise ainsi un accès en provenance d'une autre applet. Cela permet d'assurer l'herméticité entre les profils d'utilisation. 20 La Fig. 3 illustre ainsi que le pare-feu logiciel FW refuse tout accès intervenant depuis le profil PA vers le profil PB (et il en serait de même pour tout accès intervenant depuis le profil PB vers le profil PA). Notamment, la Fig. 3 montre que les accès suivants sont refusés par le pare-feu logiciel FW, indépendamment de toute interface partagée de l'applet à laquelle l'accès est destiné : 25 - accès depuis une applet du contexte CB1 vers une applet du contexte CA1 (il en serait de même à destination du contexte CA2) ; - accès depuis une applet du contexte CB1 vers une applet du contexte JA (il en serait de même depuis le contexte CB2) ; - accès depuis une applet du contexte JB vers une applet du contexte JA ; 30 - accès depuis une applet du contexte JB vers les données statiques SA; - accès depuis une applet du contexte JB vers une applet du contexte CA2 (il en serait de même à destination du contexte CA1) ; - accès depuis une applet du contexte CB2 vers une applet du contexte CA2 (il en serait de même à destination du contexte CA1) ; et 11 - accès depuis une applet du contexte CB2 vers les données statiques SA (il en serait de même depuis le contexte CB1). La Fig. 4 illustre schématiquement une gestion d'accès entre des applets appartenant à des contextes distincts, selon le second mode de réalisation. 5 Dans le cadre du second mode de réalisation, un profil d'utilisation particulier est défini. Il est appelé profil système PS. Le profil système a des droits d'accès propres aux autres profils d'utilisation, appelés alors profils ordinaires. De manière illustrative, on retrouve ainsi sur la Fig. 4 le profil PA déjà présent sur la Fig. 3 (le profil PB aurait pu y être indifféremment représenté à la place du profil PA). 10 Dans un mode de réalisation particulier, le profil système est un profil d'utilisation associé aux applets instanciées par le fabricant de la carte à puce eUICC ou du composant électronique iUICC. Le profil système est en charge du téléchargement, de l'installation et de la mise en place des profils ordinaires. Par exemple, en considérant le cas où la carte à puce eUICC est une carte SIM, le profil système est associé au 15 fabricant de la carte SIM, et les profils ordinaires sont associés à des opérateurs de téléphonie distincts auprès desquels l'utilisateur de la carte à puce eUICC a effectué des souscriptions de service. Le profil système permet ainsi notamment de centraliser toutes les données communes à l'ensemble des profils ordinaires, comme les données d'administration de la carte à puce eUICC elle-même, e.g. ECASD (« eUICC 20 Controlling Authority Secure Domain » en anglais) et ISD-R (« Issuer Security Domain - Root » en anglais). Chaque profil ordinaire peut aussi inclure des données d'administration qui lui sont propres, e.g. CASD (« Controlling Authority Secure Domain » en anglais). il en serait de même dans le cadre d'une mise en oeuvre du composant électronique iUICC. 25 Le profil PS contient un septième contexte CS1 et un huitième contexte C52. Le septième contexte CS1 contient une applet AS1. Le huitième contexte C52 contient une applet A54. Le profil PS contient en outre un neuvième contexte JS destiné aux applets instanciées par l'environnement JCRE lorsque le profil PS est actif Sur la Fig. 4, le neuvième contexte JS contient une applet A52 et une applet A53. Le profil PS peut 30 contenir en outre des données statiques SS communes aux différents contextes du profil PS. Lorsqu'un accès est effectué entre applets au sein d'un même profil d'utilisation (intra-profil), le pare-feu logiciel FW applique les règles de vérification d'accès entre contextes, c'est-à-dire notamment les règles de vérification d'accès usuelles déjà 12 évoquées de la technologie Java Card (telles qu'on les retrouve dans les spécifications « Java Card Classic Plateform », version 3.0.4). Le pare-feu logiciel FW vérifie alors auprès de l'applet ciblée que ladite applet ciblée fournit une interface partagée et que ladite applet ciblée autorise ainsi un accès en provenance d'une autre applet. 5 De plus, lorsqu'un accès est effectué depuis une première applet appartenant au profil PS vers une seconde applet appartenant au profil PA, le pare-feu logiciel FW accepte l'accès, et applique aussi les règles de vérification d'accès entre contextes. Le pare-feu logiciel FW vérifie ainsi notamment si la seconde applet fournit une interface partagée et autorise ainsi un accès en provenance d'une autre applet. Le profil PS a ainsi 10 accès aux profils ordinaires PA et PB. En d'autres termes, cela signifie que le pare-feu logiciel FW applique les règles de vérification d'accès entre contextes, comme si l'accès était intra-profil. La Fig. 4 illustre ainsi que le pare-feu logiciel FW accepte tout accès intervenant depuis le profil PS vers le profil PA (et il en serait de même pour tout accès intervenant 15 depuis le profil PS vers le profil PB). Notamment, la Fig. 4 montre que les accès suivants sont acceptés par le pare-feu logiciel FW : - accès depuis une applet du contexte CS1 vers une applet du contexte CA1 (il en serait de même à destination du contexte CA2) ; - accès depuis une applet du contexte CS1 vers une applet du contexte JA (il en 20 serait de même depuis le contexte CS2) ; - accès depuis une applet du contexte JS vers une applet du contexte JA ; - accès depuis une applet du contexte JS vers une applet du contexte CA2 (il en serait de même à destination du contexte CA1) ; - accès depuis une applet du contexte CS2 vers une applet du contexte CA2 (il en 25 serait de même à destination du contexte CA1) ; et - accès depuis une applet du contexte CS2 vers les données statiques SA (il en serait de même depuis le contexte CS1). A l'inverse, les accès émanant du profil PA (il en serait de même en provenance du profil PB) à destination du profil PS sont refusés par le pare-feu logiciel FW, 30 indépendamment de toute interface partagée de l'applet à laquelle l'accès est destiné. On remarque à la lecture de la description des Figs. 3 et 4 que chaque applet est associée à un unique contexte et que chaque contexte est associé à une ou plusieurs applets. On remarque aussi que chaque contexte est associé à un unique profil d'utilisation et que chaque profil d'utilisation est associé à un ou plusieurs contextes. 13 La Fig. 5A illustre schématiquement un algorithme, implémenté par le pare-feu logiciel FW, de traitement d'un accès entre applets, selon le premier mode de réalisation. Dans une étape 501, le pare-feu logiciel FW reçoit un accès à vérifier. Le pare- 5 feu logiciel FW en est informé par l'interpréteur, à savoir la machine virtuelle JCVM. Dans une étape 502, le pare-feu logiciel FW détermine un profil source de l'accès. En d'autres termes, le pare-feu logiciel FW vérifie à quel profil d'utilisation appartient l'applet à l'origine de l'accès en question. Une information représentative du profil actif est fournie au pare-feu logiciel FW en parallèle de l'accès à vérifier. 10 Dans une étape 503, le pare-feu logiciel FW détermine un profil destinataire de l'accès. En d'autres termes, le pare-feu logiciel FW vérifie à quel profil d'utilisation appartient l'applet ciblée par l'accès en question. L'accès est destiné à un objet, relatif à une applet donnée, instancié dans ledit profil destinataire. Cet objet contient une information dudit profil destinataire, dans lequel ledit objet est instancié. Chaque objet 15 est ainsi auto-descriptif Une autre approche consiste à inclure, dans le pare-feu logiciel FW, une table listant les profils d'utilisation existant sur la carte à puce eUICC ou sur le composant électronique iUICC, ainsi que les contextes existant au sein de chaque profil d'utilisation, ainsi que les applets existant au sein de chaque contexte. Cette table est 20 mise à jour à chaque instanciation de profil d'utilisation, de contexte et d'applet. Le pare-feu logiciel FW retrouve ainsi dans ladite table à quel profil d'utilisation appartient l'applet ciblée par l'accès en question. Dans une étape 504, le pare-feu logiciel FW vérifie si le profil source de l'accès, déterminé à l'étape 502, est identique au profil destinataire de l'accès, déterminé à 25 l'étape 503. Typiquement, le profil d'utilisation courant, c'est-à-dire le profil source, est maintenu dans une variable persistante, à laquelle le pare-feu logiciel FW a accès. Lorsque le profil source de l'accès est identique au profil destinataire de l'accès, une étape 506 est effectuée ; sinon, une étape 505 est effectuée. Dans l'étape 505, le pare-feu logiciel FW refuse l'accès, indépendamment du fait 30 que l'applet ciblée par l'accès fournisse ou pas une interface partagée. Aucun accès à l'applet ciblée par l'accès n'est donc donné. Il est alors mis fin à l'algorithme de la Fig. 5A. Dans l'étape 506, le pare-feu logiciel FW applique les règles susmentionnées de vérification d'accès entre contextes. En d'autres termes, le pare-feu logiciel FW vérifie 14 notamment si l'applet ciblée par l'accès fournit ou pas une interface partagée. Ainsi. , si l'applet ciblée par l'accès fournit une interface partagée, l'accès à l'applet ciblée par l'accès est donné ; sinon, l'accès est refusé et aucun accès à l'applet ciblée par l'accès n'est donné. Il est alors mis fin à l'algorithme de la Fig. 5A. 5 La Fig. 5B illustre schématiquement un algorithme, implémenté par le pare-feu logiciel, de traitement d'un accès entre applets, selon le second mode de réalisation. Dans une étape 551, le pare-feu logiciel FW reçoit un accès à vérifier. L'étape 551 est identique à l'étape 501. Dans une étape 552, le pare-feu logiciel FW détermine un profil source de l'accès. 10 L'étape 552 est identique à l'étape 502. Dans une étape 553, le pare-feu logiciel FW détermine un profil destinataire de l'accès. L'étape 553 est identique à l'étape 503. Dans une étape 554, le pare-feu logiciel FW vérifie si le profil source de l'accès, déterminé à l'étape 552, est identique au profil destinataire de l'accès, déterminé à 15 l'étape 553. L'étape 554 est identique à l'étape 504. Lorsque le profil source de l'accès est identique au profil destinataire de l'accès, une étape 556 est effectuée ; sinon, une étape 560 est effectuée. Dans l'étape 556, le pare-feu logiciel FW applique les règles susmentionnées de vérification d'accès entre contextes. En d'autres termes, le pare-feu logiciel FW vérifie 20 si l'applet ciblée par l'accès fournit ou pas une interface partagée. Ainsi, si l'applet ciblée par l'accès fournit une interface partagée, l'accès à l'applet ciblée par l'accès est donné ; sinon, l'accès est refusé et aucun accès à l'applet ciblée par l'accès n'est donné. Il est alors mis fin à l'algorithme de la Fig. 5B. Dans l'étape 560, le pare-feu logiciel FW vérifie si le profil source de l'accès est 25 le profil système PS. Si tel est le cas, l'étape 556 est effectuée ; sinon, une étape 561 est effectuée. En d'autres termes, lorsque l'étape 556 est ici effectuée, le pare-feu logiciel FW vérifie si l'applet ciblée par l'accès fournit ou pas une interface partagée. Ainsi, si l'applet ciblée par l'accès fournit une interface partagée, l'accès à l'applet ciblée par l'accès est donné ; sinon, l'accès est refusé et aucun accès à l'applet ciblée par l'accès 30 n'est donné. Il est alors mis fin à l'algorithme de la Fig. 5B. Ainsi, contrairement aux profils ordinaires, le profil système PS peut effectuer des accès aux applets d'autres profils si lesdites applets fournissent respectivement des interfaces partagées. Dans l'étape 561, le pare-feu logiciel FW refuse l'accès, indépendamment du fait que l'applet ciblée par l'accès fournisse ou pas une interface partagée. Aucun accès à 15 l'applet ciblée par l'accès n'est donc donné. Il est alors mis fin à l'algorithme REVENDICATIONS1) Procédé de vérification d'exécution d'applets (AA1, AB1) développées en langage orienté objet et compilées en code intermédiaire, le procédé étant implémenté par un pare-feu logiciel (FW) d'un système d'exploitation installé dans un composant électronique (iUICC) ou sur une carte électronique (eUICC), le système d'exploitation comportant un interpréteur (JCVM) qui est un logiciel interprétant et exécutant le code intermédiaire des applets (AA1, AB1), chaque applet (AA1, AB1) étant associée à un unique contexte (CA1, CB1, JB), chaque contexte (CA1, CB1, JB) étant associé à une ou plusieurs applets, caractérisé en ce que chaque contexte (CA1, CB1, JB) est associé à un unique profil d'utilisation (PA, PB) parmi plusieurs profils d'utilisation, chaque profil d'utilisation (PA, PB) est associé à un ou plusieurs contextes (CA1, CB1, JB), et en ce que, lorsque le pare-feu logiciel (FW) est informé par l'interpréteur (JCVM) d'un accès depuis une première applet (AB1) vers une seconde applet (AB3, AA1), le pare-feu logiciel (FW) effectue les étapes suivantes : - déterminer (502, 552) un profil source de l'accès, qui est le profil associé au contexte auquel est associée la première applet (AB1) ; - déterminer (503, 553) un profil destinataire de l'accès, qui est le profil associé au contexte auquel est associée la seconde applet (AB3, AA1) ; - vérifier (504, 554) si le profil source de l'accès est identique au profil destinataire de l'accès ; - lorsque le profil source de l'accès n'est pas identique au profil destinataire de l'accès, refuser (505, 561) l'accès ; et - lorsque le profil source de l'accès est identique au profil destinataire de l'accès, appliquer (506, 556) des règles de vérification d'accès entre contextes. 2) Procédé selon la revendication 1, caractérisé en ce que l'accès fait référence soit à une donnée statique, soit à une donnée non statique, soit à une méthode. 3) Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce qu'un desdits profils d'utilisation est un profil particulier, appelé profil système (PS), géré distinctement des autres profils d'utilisation (PA, PB) par le pare-feu logiciel (FW), de telle sorte que, lorsque le profil source de l'accès est le profil système (PS), le pare- 17 feu logiciel (FW) applique les règles de vérification d'accès entre contextes, et lorsque le profil destinataire de l'accès est le profil système (PS), le pare-feu logiciel (FW) refuse l'accès. 5 4) Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que la carte électronique est une carte à puce. 5) Procédé selon la revendication 4, caractérisé en ce que la carte à puce est une carte SIM et en ce que les profils d'utilisation sont respectivement associés à des 10 services de téléphonie d'opérateurs distincts. 6) Pare-feu logiciel (FW) configure pour effectuer une vérification d'exécution d'applets (AA1, AB1) développées en langage orienté objet et compilées en code intermédiaire, le pare-feu logiciel (FW) destiné à appartenir à un système d'exploitation 15 destiné à être installé dans un composant électronique (iUICC) ou sur une carte électronique (eUICC), le système d'exploitation comportant un interpréteur (JCVM) qui est un logiciel interprétant et exécutant le code intermédiaire des applets (AA1, AB1), chaque applet (AA1, AB1) étant associée à un unique contexte (CA1, CB1, JB), chaque contexte (CA1, CB1, JB) étant associé à une ou plusieurs applets, 20 caractérisé en ce que chaque contexte (CA1, CB1, JB) est associé à un unique profil d'utilisation (PA, PB) parmi plusieurs profils d'utilisation, chaque profil d'utilisation (PA, PB) est associé à un ou plusieurs contextes (CA1, CB1, JB), et en ce que, lorsque le pare-feu logiciel (FW) est informé par l'interpréteur (JCVM) d'un accès depuis une première applet (AB1) vers une seconde applet (AB3, 25 AA1), le pare-feu logiciel (FW) effectue les étapes suivantes : - déterminer (502, 552) un profil source de l'accès, qui est le profil associé au contexte auquel est associée la première applet (AB1) ; - déterminer (503, 553) un profil destinataire de l'accès, qui est le profil associé au contexte auquel est associée la seconde applet (AB3, AA1) ; 30 - vérifier (504, 554) si le profil source de l'accès est identique au profil destinataire de l'accès ; - lorsque le profil source de l'accès n'est pas identique au profil destinataire de l'accès, refuser (505, 561) l'accès ; et 18 - lorsque le profil source de l'accès est identique au profil destinataire de l'accès, appliquer (506, 556) des règles de vérification d'accès entre contextes. 7) Carte électronique (eUICC) comportant un système d'exploitation intégrant un 5 pare-feu logiciel (FW), selon la revendication 6, configure pour effectuer une vérification d'exécution d'applets (AA1, AB1) développées en langage orienté objet et compilées en code intermédiaire. 8) Carte électronique (eUICC) selon la revendication 7, caractérisée en ce que la 10 carte électronique est une carte à puce. 9) Carte électronique (eUICC) selon la revendication 8, caractérisée en ce que la carte à puce est une carte SIM et en ce que les profils d'utilisation sont respectivement associés à des services de téléphonie d'opérateurs distincts. 10) Composant électronique (iUICC) comportant un système d'exploitation intégrant un pare-feu logiciel (FW), selon la revendication 6, configure pour effectuer une vérification d'exécution d'applets (AA1, AB1) développées en langage orienté objet et compilées en code intermédiaire. 15 20