Brevet FR3099258A1 — publié le 20210129

Description Titre de l'invention : Adaptation dynamique d'un environnement d'exécution d'élément sécurisé à des profils Domaine technique [0001] La présente invention concerne, de façon générale, le domaine des éléments sécurisés et plus particulièrement la gestion de leur exécution dans de tels éléments. Technique antérieure [0002] Un élément sécurisé, SE, est un composant ou plate-forme matérielle inviolable (typiquement une puce ou une carte à puce) utilisée dans un terminal hôte (typiquement un terminal mobile) et capable d'héberger, de façon sûre, des applications et des données en conformité avec des règles et des exigences de sécurité fixées par des autorités de confiance. [0003] Un facteur de forme de plus en plus utilisé du SE est l'élément sécurisé embarqué, eSE (pour « embedded Secure Element »). Cet élément sécurisé embarqué est généralement soudé au terminal hôte. Un facteur de forme plus récent est l'élément sécurisé intégré, iSE (pour « integrated Secure Douent »). L'élément sécurisé fait alors partie intégrante du processeur principal (par exemple comme coeur sécurisé en plus d'autres coeurs du processeur). [0004] Les éléments sécurisés sont programmés selon les applications souhaitées. [0005] A titre d'exemple, un eSE ou iSE peut former l'élément sécurisé nécessaire à de nombreux usages ou services reposant sur une communication NFC (Near Field Communication) mis en oeuvre par un terminal mobile hôte. Par exemple, un service de paiement NFC nécessite des informations bancaires secrètes de l'utilisateur qui sont avantageusement stockées dans l'eSE, à l'abri de tout accès intempestif. C'est aussi le cas d'un service de transport public où l'eSE permet d'identifier l'utilisateur auprès de portiques. [0006] Un autre exemple d'élément sécurisé est l'UICC embarquée (pour « Universal In- tegrated Circuit Card » soit carte de circuit intégré universelle) qui procure les références d'un abonné pour s'authentifier sur un ou plusieurs réseaux (le téléphonie mobile, notamment via différents opérateurs. Il s'agit par exemple d'un eSE ou iSE configuré comme une carte SIM (pour « Subscriber Identity Module » - ou module d'identité d'abonné). On parle alors d'eUICC (pour « embedded UICC ») ou iUICC (pour « integrated UICC »). [0007] L'intérêt principal de ces éléments sécurisés est d'offrir plusieurs services à l'aide d'un seul et même élément sécurisé. Plusieurs fournisseurs de service doivent donc charger les données et/ou applications dans le même élément sécurisé permettant à un 2 utilisateur d'accéder à leurs services. Ces données et/ou applications propres à un fournisseur de service pour un utilisateur forment un profil de service mémorisé dans l'élément sécurisé. On connaît, notamment les profils au sens de la norme GSMA RSP Technical Specification, Version 2.2 du 01 septembre 2017 (ci-dessous GSMA SGP.22) qui sont associés à des opérateurs mobiles (fournisseurs de service) et contiennent les informations de l'utilisateur lui permettant d'accéder à leurs services de téléphonie mobile. On connaît, également les configurations au sens de la norme GlobalPlatform Card Specification (Version 2.3 (l'octobre 2015) qui sont associées à des autorités (fournisseurs de service) et contiennent les informations de l'utilisateur lui permettant d'accéder à leurs services respectifs. [0008] Chaque fournisseur de service présente ses propres spécificités qui nécessitent d'adapter l'environnement d'exécution dans l'élément sécurisé, par exemple un système d'exploitation et/ou une machine virtuelle (typiquement un système Java Card), pour pouvoir utiliser le profil de service correspondant. Or, ces adaptations d'une ou plusieurs ressources d'exécution ne sont pas nécessairement compatibles d'un profil à l'autre. [0009] D'une façon générale, il serait bénéfique d'améliorer la gestion de l'exécution d'un élément sécurisé comportant un profil de service. [0010] On connaît, de la publication US 2010/012732, l'utilisation de données correctives ou « patch » pour mettre à jour un module de carte à puce après initialisation de celui-ci. Il s'agit cependant de corriger des erreurs dans l'environnement d'exécution. Cette approche ne permet pas de gérer dynamiquement l'environnement d'exécution en fonction du ou des profils d'exécution. [0011] La présente invention vise à remédier à ces inconvénients. Exposé de l'invention [0012] L'invention concerne tout d'abord un élément sécurisé comprenant un envi- ronnement d'exécution initial, un premier profil de service, des données adaptatives (ou « adaptateur » ou « adapter » en terminologie anglaise) de l'environnement d'exécution initial en un environnement d'exécution adapté au premier profil de service, une routine adaptative contiguréc pour appliquer les données adaptatives à l'environnement d'exécution initial, caractérisé en ce qu'il comprend en outre des données adaptatives inverses (ou adaptateur inverse) pour restaurer l'environnement d'exécution initial depuis l'environnement d'exécution adapté, la routine adaptative étant configurée pour appliquer les données adaptatives inverses après utilisation du premier profil de service. [0013] Corrélativement, l'invention concerne également un procédé d'exécution dans un élément sécurisé comprenant un environnement d'exécution initial et un premier profil 3 de service, le procédé comprenant les étapes suivantes : - appliquer, par une routine adaptative, des données adaptatives de l'environnement d'exécution initial pour obtenir un environnement d'exécution adapté au premier profil de service, - utiliser le premier profil de service dans l'environnement d'exécution adapté, - puis appliquer, par la routine adaptative, des données adaptatives inverses à l'environnement d'exécution adapté pour restaurer l'environnement d'exécution initial. [0014] A titre d'exemple, l'adaptation peut concerner une classe Java souvent utilisée dans un élément sécurisé conçu selon la technologie Java Card. Dans ce cas, les données adaptatives sont configurécs pour adapter une classe Java initiale de l'environnement d'exécution initial à un format d'un objet instanciant la classe Java dans le premier profil de service, et les données adaptatives inverses sont configurécs pour restaurer la classe Java initiale depuis la classe Java adaptée. Bien entendu, d'autres ressources d'exécution, telle que des applications chargées dans l'élément sécurisé, peuvent être adaptées. [0015] Le principe d'adaptation de la présente invention s'applique aussi dans la situation où des objets de la classe ont déjà été instanciés par d'autres profils. [0016] La présente invention permet ainsi d'adapter dynamiquement l'environnement d'exécution d'un élément sécurisé à différents profils chargés qui ont leurs propres spécificités. Avantageusement, le mécanisme d'adaptation proposé n'impacte pas les infrastructures déjà existantes (notamment des réseaux de téléphonie mobile) tout en augmentant le champ accessible aux fournisseurs de service pour adapter l'environnement d'exécution à leurs services. Il en résulte une plus grande liberté pour ceux-ci à offrir de nouvelles fonctionnalités ou nouveaux services. [0017] Des caractéristiques optionnelles de modes de réalisation de l'invention sont définies dans les revendications dépendantes. [0018] Dans un mode de réalisation, la routine adaptative est configurée pour appliquer les données adaptatives et les données adaptatives inverses en fonction du cycle de vie du premier profil de service. Cette approche offre une adaptation dynamique efficace de l'environnement d'exécution. [0019] Par exemple, la routine adaptative est configurée pour appliquer les données adaptatives à l'environnement d'exécution initial lors d'une activation du premier profil de service et pour appliquer les données adaptatives inverses à l'environnement d'exécution adapté lors d'une désactivation ou suppression du premier profil de service. Cette disposition assure un fonctionnement optimal des profils activés. [0020] Corrélativement pour le procédé selon l'invention, les données adaptatives et les données adaptatives inverses sont appliquées en fonction du cycle de vie du premier profil de service, par exemple, les données adaptatives sont appliquées à l'environnement d'exécution initial lors d'une activation du premier profil de service et les données adaptatives inverses sont appliquées à l'environnement d'exécution adapté lors d'une désactivation ou suppression du premier profil de service. [0021] Dans un mode de réalisation, les données adaptatives et les données adaptatives inverses sont stockées sous forme de listes de directives interprétables par la routine adaptative. Cette disposition accroît les possibilités d'adaptation de l'environnement d'exécution comparativement aux techniques connues limités à un nombre restreint d'indirections (vers un système d'exploitation) où une modification peut être apportée. Les applications et fonctionnalités des profils peuvent par conséquent être plus variées. [0022] Dans un mode de réalisation, les données adaptatives et les données adaptatives inverses sont stockées dans le premier profil de service ou associées à ce premier profil de service, par exemple dans une mémoire réservée au premier profil. Aussi, chaque profil stocke ses propres données adaptatives. Cela facilite l'utilisation et la gestion des données adaptatives pour leur application lorsque le profil est par exemple activé. [0023] Dans un mode de réalisation, l'élément sécurisé comprend un moyen de commu- nication pour recevoir les données adaptatives et les données adaptatives inverses au sein d'un package transmis par un équipement externe, par exemple un package d'installation du premier profil de service transmis par un équipement d'un site de personnalisation ou par un serveur réseau distant, ou encore un package transmis par un serveur réseau distant postérieurement à l'installation du premier profil de service dans l'élément sécurisé. Notamment, les données adaptatives et les données adaptatives inverses peuvent être encapsulées comme deux composants supplémentaires (appelés custom component dans la technologie Java Card) d'une application du premier profil au sein du package. Aucune adaptation des mécanismes existants d'installation ( provisionning selon les normes) n'est ainsi requis. [0024] Corrélativement pour le procédé selon l'invention, celui-ci comprend en outre la réception des données adaptatives et des données adaptatives inverses au sein d'un package transmis par un équipement externe, par exemple un package d'installation du premier profil de service transmis par un équipement d'un site de personnalisation ou par un serveur réseau distant, ou encore un package transmis par un serveur réseau distant postérieurement à l'installation du premier profil de service dans l'élément sécurisé. [0025] Dans une variante, l'élément sécurisé comprend un module de génération des données adaptatives inverses à partir des données adaptatives reçues d'un équipement réseau distant. Les données adaptatives peuvent être reçues comme composant supplémentaire d'une application du premier profil dans un package d'installation de ce profil. La génération par l'élément sécurisé des données adaptatives inverses permet de réduire les risques d'erreur dans leur génération. Dans cette variante, la génération peut désormais tenir compte du résultat réellement obtenu en appliquant les données adaptatives à l'environnement d'exécution de l'élément sécurisé (compte tenu par exemple de la plateforme matérielle utilisée), ce que ne peut pas un serveur distant. Cette génération a lieu lors de l'adaptation de l'environnement d'exécution. [0026] Dans une variante, cette génération peut avoir lieu à l'installation du profil ou à la première activation du profil. [0027] Corrélativement pour le procédé selon l'invention, celui-ci comprend en outre la gé- nération, par l'élément sécurisé, des données adaptatives inverses à partir des données adaptatives reçues d'un équipement réseau distant. [0028] Dans un mode de réalisation, l'élément sécurisé comprend en outre un deuxième profil (ou plus) choisi parmi : - un profil de service utilisable dans l'environnement d'exécution initial, - un profil de service utilisable dans un environnement d'exécution modifié obtenu par l'application d'autres données adaptatives différentes desdites données adaptatives à l'environnement d'exécution initial, ce profil de service comportant les autres données adaptatives et des autres données adaptatives inverses pour restaurer l'environnement d'exécution initial depuis l'environnement d'exécution modifié. [0029] L'application des données adaptatives et données adaptatives inverses de différents profils peut alors être effectuée selon leurs cycles de vie, c'est-à-dire au fur et à mesure de leurs activations, désactivations, suppressions. [0030] Dans un mode de réalisation, l'élément sécurisé comprend un collecteur de déchets (ou « ramasse-miettes » ou « garbage collector » selon une terminologie anglo-saxonne) collectant des ressources de profil (par exemple des objets, typiquement Java) non utilisées (par exemple non référencées par les applications) stockées en mémoire, le collecteur de déchets étant configuré pour effectuer la collecte uniquement parmi les ressources de profil liées à un ou plusieurs profils de service particuliers. La collecte est généralement effectuée en vue d'une suppression des ressources non utilisées, pour libérer de l'espace mémoire. Le comportement du garbage collector est ainsi adapté au type d'objet à collecter, à savoir fonction du ou des profils visés. Il est ainsi possible de ne venir collecter qu'un type d'objet. [0031] Le ou les profils de service particulier peuvent être constitués d'un seul profil désigné par une action ou commande comme décrit ci-après, ou être un ensemble de profils s'exécutant sur le même environnement d'exécution adapté (c'est-à-dire des profils dont les données adaptatives correspondantes sont identiques). A titre illustratif, lorsqu'un profil cible est identifié pour collecte par le garbage collector, ce dernier peut étendre la collecte à l'ensemble des profils partageant le même environnement d'exécution adapté que celui du profil cible. [0032] Selon une caractéristique, le profil de service particulier est un profil de service actif 6 dans l'élément sécurisé. La collecte est ainsi effectuée pour le profil actif, par exemple en réponse à une commande de désactivation du profil actif [0033] Selon une variante, le profil de service particulier est le dernier profil de service actif. Cette disposition peut être utilisée lors d'une procédure de nettoyage de la mémoire alors qu'aucun profil n'est actif. [0034] Selon une autre variante, le profil de service particulier est un profil de service à supprimer. Cette situation survient donc généralement en réponse à une commande de suppression d'un profil. [0035] Dans ces deux variantes, l'environnement d'exécution n'est pas adapté au profil visé par la collecte. Aussi, l'élément sécurisé peut être configure pour appliquer, avant d'effectuer la collecte, les données adaptatives associées au profil de service particulier (pour adapter l'environnement d'exécution au profil), et appliquer, après la collecte, les données adaptatives inverses associées au profil de service particulier (pour restaurer l'environnement d'exécution initial). Cela permet de réaliser une collecte efficace ciblée sur les objets spécifiques au profil concerné. Dans un mode de réalisation propre à la collecte pour un profil à supprimer, le collecteur de déchets collecte, lors de ladite collecte, les ressources de profil du profil de service à supprimer à l'exception des données adaptatives inverses associées à ce profil de service, et supprime les données adaptatives inverses seulement après les avoir appliquées. Cette disposition garantit un retour à l'environnement d'exécution générique lors de la suppression d'un profil. L'élément sécurisé peut ainsi continuer à être utilisé avec les profils restants. [0036] Dans un mode de réalisation particulier, les ressources de profil sont estampillées d'un indicateur représentatif de leurs profils d'exécution respectifs. Cette disposition permet au collecteur de déchets de chercher efficacement parmi les ressources pertinentes. [0037] Dans un mode de réalisation particulier, les ressources de profils peuvent être collectées spontanément, c'est-à-dire indépendamment de la réception d'une commande (par exemple de suppression ou de désactivation). A titre d'exemple, la collecte peut être déclenchée en cas de détection d'une saturation mémoire. [0038] Dans ce cas notamment mais non exclusivement, le collecteur de déchets peut être configuré pour scanner, c'est-à-dire, et tel que bien connu par l'homme du métier, lire toutes les références d'un objet, l'ensemble des objets de tous les profils et ainsi procéder à la collecte sur l'ensemble des objets de tous les profils. Cette « vision globale du collecteur de déchets apporte une précision accrue, au sens de pouvoir collecter tous les objets inatteignables, du fait d'avoir la possibilité de nettoyer toute la mémoire. [0039] Préférablement, la collecte n'est opérée que pour les objets du profil actif afin de se focaliser sur le seul contexte courant. D'autres choix de mise en oeuvre sont néanmoins 7 envisageables selon les performances souhaitées (précision de la collecte, au sens meilleur nettoyage de la mémoire, ou temps de traitement réduit). [0040] L'invention concerne également un produit programme d'ordinateur comprenant des instructions configurées pour une mise en oeuvre des étapes du procédé ci-dessus lorsque ledit programme est exécuté sur un ordinateur, ainsi qu'un support tangible comprenant un tel produit programme d'ordinateur. Brève description des dessins [0041] D'autres particularités et avantages de l'invention apparaîtront encore dans la des- cription ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. [0042] [fig.1] La Figure 1 illustre un système dans lequel un élément sécurisé selon l'invention est mis en oeuvre. [0043] [fig.2] La Figure 2 illustre un exemple d'architecture haut-niveau d'une carte cUICC pour une mise en oeuvre de l'invention. [0044] [fig.3] La Figure 3 illustre, à l'aide d'un ordinogramme, des étapes générales pour le déploiement d'adaptateurs selon l'invention dans un élément sécurisé. [0045] [fig.4] La Figure 4 illustre un exemple d'adaptation d'une classe Java selon un mode de réalisation de l'invention. [0046] [fig.5] La Figure 5 illustre, à l'aide d'un ordinogramme, des étapes générales de l'adaptation d'un environnement d'exécution lors de l'activation d'un profil, selon un mode de réalisation dc l'invention. [0047] [fig.6] La Figure 6 illustre, à l'aide d'un ordinogramme, des étapes générales de la restauration d'un environnement d'exécution lors de la désactivation d'un profil, selon un mode de réalisation de l'invention. [0048] [fig.7] La Figure 7 illustre, à l'aide d'un ordinogramme, des étapes générales de l'adaptation dynamique d'un environnement d'exécution lors de la suppression d'un profil, selon un mode de réalisation dc l'invention. Description détaillée [0049] La Figure 1 illustre un système 1 dans lequel un élément sécurisé 10 selon l'invention est mise en oeuvre. A titre illustratif, le système I représenté est un système de téléphonie mobile, bien que l'invention s'applique à tout système utilisant un élément sécurisé 10 contenant un ou plusieurs profils d'exécution. [0050] Dans cet exemple, l'élément sécurisé 10 est une eVICC embarquée dans un équipement hôte 20 classique, de type téléphone mobile. [0051] L'élément sécurisé 10 peut être tout type de module de carte à souder ou à insérer de façon amovible dans un lecteur d'élément sécurisé ou le dispositif hôte 20, dont des exemples sont un eSE, un iSE, une eSIM (pour embedded SIM), une SSP (pour Smart 8 Secure Platform dont des exemples sont l'iSIM (pour integrated SIM) ou l'icUICC (pour integrated cUICC)). L'équipement hôte 20 peut être l'un quelconque parmi un téléphone mobile (par exemple téléphone cellulaire ou intelligent), un ordinateur (par exemple un ordinateur portable), une tablette, un appareil de communication portable, un appareil informatique portable (par exemple un assistant de données personnelles), un appareil de divertissement (par exemple un appareil de musique ou vidéo, ou une radio satellite), ou tout autre appareil approprié. [0052] Dans l'exemple de la Figure 1, le téléphone 20 est relié à un serveur SM-DP+ 30 (« Subscription Manager Data Préparation » ou serveur de préparation de données et de gestion des abonnements) d'un réseau mobile, lequel serveur reçoit des données de différents opérateurs MNO1 et MNO2 pour les transmettre aux abonnés. Selon les situations de mise en oeuvre de l'invention, le terminal hôte 20 peut être connecté à différents types de serveurs distants 30. Le serveur SM-DP+ peut notamment être remplacé par deux serveurs SM-DP et SM-SR. [0053] L'eUICC 10 (ou plus généralement l'élément sécurisé) comporte : - une unité de traitement 12 - ou microprocesseur ; - une ou plusieurs mémoires non volatiles 14 par exemple ROM (acronyme de « Read Only Menzory » en terminologie anglo-saxonne), Flash, EEPROM (acronyme de « Eleorically Erasable Read Only Memory » en terminologie anglo-saxonne) ou tout type de disque dur ; - une mémoire vive 16 ou mémoire cache ou mémoire volatile par exemple RAM (acronyme de « Ranclom Access Memory » en terminologie anglo-saxonne) comprenant des registres adaptés à l'enregistrement de variables et paramètres pendant le fonctionnement de l'eUICC 10 du terminal 20 ; lors de la mise en oeuvre de l'invention, les codes d'instructions de programme stockés en mémoire morte non-volatile sont chargés en mémoire RAM en vue d'être exécutés par l'unité de traitement 12; - une ou plusieurs interfaces de communication 18 adaptées à échanger (transmettre et recevoir) des données avec le terminal hôte 20 et/ou avec le serveur distant 30 via un réseau de télécommunications et une interface de communication COM du terminal hôte 20. [0054] La Figure 2 illustre un exemple d'architecture haut-niveau d'une eUICC 10 (de façon générale un élément sécurisé) dans une utilisation de téléphonie mobile où elle héberge plusieurs profils opérateurs MNOI, MNO2 permettant l'accès au réseau mobile de ces opérateurs (de façon générale elle héberge un ou plusieurs profils d'exécution permettant d'accéder à des services respectifs). [0055] L'eUICC 10 comprend un environnement d'exécution 100, un domaine de sécurité racine ISD-R 200, un ou plusieurs (ici deux) domaines de sécurité de profil ISD-P 210, 9 220 correspondant à deux profils P1 et P2, et un domaine ECASD 230. [0056] L'environnement d'exécution 100 comprend par exemple le système d'exploitation OS de l'eUICC 10. L'environnement d'exécution 100 peut également comprendre un environnement d'exécution JCRE (comprenant généralement une machine virtuelle JCVM) exécuté par l'OS lorsque l'eUICC lo est conçue en accord avec la technologie Java Card. [0057] L'environnement d'exécution 100 comporte un service télécom 102, un service d'activation de profil 104, un interpréteur de package de profil 106, une ou plusieurs ressources 108 utilisées par les profils installés (par exemple par des applications), une routine adaptative 110, et un collecteur de déchets 112. [0058] Le service télécom 102 fournit des algorithmes d'authentification réseau pour les profils (P1, P2) stockés sur l'eUICC 10. Le service d'activation de profil 104 valide et applique des règles de politique de profil. L' interpréteur 106 traduit des packages de profil (typiquement au format CAP) reçus en des profils (par exemple P1 et P2) installés sur l'eUICC 10. [0059] Les ressources 108 utilisées par les profils peuvent être de natures variées : données, applications, code (interprété ou natif), API (interface de programmation applicative), fonctions, classes (ajout, suppression, modification de champs d'une classe). Ces ressources 108 sont « adaptées » à l'aide de données adaptatives (ci-après « adaptateur ») dans une mise en oeuvre l'invention. Dans l'exemple qui suit, on considère comme ressource « adaptable » une classe Java Card utilisée par les profils PI et P2. Néanmoins, l'invention s'applique à l'adaptation de toute ressource. [0060] La routine adaptative 110 permet d'appliquer des données adaptatives à ces ressources 108 afin d'obtenir des ressources adaptées. En appliquant des données adaptatives prévues pour un profil particulier (donc adaptées à un opérateur), il est ainsi possible d'adapter l'environnement d'exécution 100 au profil considéré, permettant d'assurer et supporter les fonctionnalités spécifiques prévues dans ce profil. De façon avantageuse, l'adaptation peut être réalisée sur le code natif de l'environnement d'exécution. En variante, l'adaptation peut être réalisée sur du code interprétable de l'environnement d'exécution. [0061] L'exemple proposé ci-après s'appuie sur l'adaptation de la classe 108 aux différents profils, par exemple par ajout/modification d'un champ ou d'une méthode de la classe 108. Bien entendu, plusieurs ressources peuvent être adaptées, qui diffèrent d'un profil à l'autre. En outre, d'autres ressources que des classes Java peuvent être modifiées, par exemple le code ou les données d'une application chargée de l'environnement d'exécution 100. [0062] Selon l'invention, la routine adaptative 110 permet également d'appliquer des données adaptatives inverses permettant de restaurer la ressource 108 dans son état 10 initial. Ainsi, il est possible d'adapter dynamiquement l'environnement d'exécution 100 à un profil particulier à utiliser : en appliquant les données adaptatives idoines pour obtenir les ressources adaptées utilisées par le profil, puis en appliquant, en fin d'utilisation, les données adaptatives inverses pour restaurer les ressources initiales. [0063] Le collecteur de déchets 112, autrement connu sous l'appellation de « garbage collectai» dans un environnement Java, permet de collecter des ressources propres aux profils qui ne sont plus en cours d'utilisation, pour les supprimer (afin de libérer de la mémoire). Il s'agit par exemple de collecter des objets Java qui ne sont plus atteignables par les méthodes et autres objets mis en oeuvre. [0064] De façon connue, l'ISD-R 200 permet la création des domaines de sécurité de profil ISD-P 210, 220 ainsi que la gestion de leurs cycles de vie, c'est-à-dire l'installation des profils PI et P2, leurs activations, désactivations et suppressions. Des commandes peuvent ainsi être reçues par l'ISD-R 200 du serveur distant 30 ou d'une action (par exemple saisie, choix, clic, ...) réalisée par l'utilisateur sur le terminal hôte 20, aux fins de modifier l'état d'un profil. [0065] Pour le cas où deux profils d'exécution ne peuvent être actifs en même temps, l'activation d'un profil inactif est interprétée également comme une demande de désactivation du profil actif. En variante, deux profils peuvent être actifs simultanément, reposant sur un même environnement d'exécution (éventuellement adapté) ou sur des environnements d'exécution différents auquel cas l'environnement d'exécution est dynamiquement adapté en temps réel au profil sollicitant une exécution. [0066] Chaque domaine de sécurité de profil ISD-P 210 ou 220 correspond à un profil PI ou P2 pour accéder au réseau mobile d'un opérateur MNO1 ou MNO2. De façon connue, un ISD-P comporte un certain nombre d'éléments (non représentés) tels qu'un MNOSD (domaine de sécurité de l'opérateur contenant des clés cryptographiques), des domaines de sécurité supplémentaires (SSD), un domaine d'autorité de contrôle (CASD), des applications (applets), un application d'accès réseau (NAA) utilisée pour permettre l'accès au réseau de l'opérateur à l'aide des clés du MNO-SD, des données de profil (incluant des règles de politique de profil). [0067] Chaque domaine de sécurité de profil ISD-P 210 ou 220 (ou profil Pl ou P2) comporte en outre un adaptateur 211/221 ainsi qu'un adaptateur inverse 212/222. [0068] L'adaptateur 211/221 permet d'adapter l'environnement d'exécution initial (ou d'origine) 100 en un environnement d'exécution adapté aux spécificités du profil Pl ou P2 (et donc de l'opérateur associé). L'adaptateur 211/221 correspond à la différence binaire entre l'environnement d'exécution initial 100 et l'environnement d'exécution adapté aux spécificités de l'opérateur. L'adaptation peut concerner une ou plusieurs ressources d'exécution 108. [0069] L'adaptateur inverse 212/222 permet de restaurer l'environnement d'exécution initial 11 100 depuis l'environnement d'exécution adapté par l'adaptateur 211/221. En d'autres termes, l'adaptateur inverse 212/222 correspond ainsi à la différence binaire entre l'environnement d'exécution adapté aux spécificités de l'opérateur et l'environnement d'exécution initial 100 non adapté. La restauration peut concerner la ou les ressources d'exécution 108 adaptées. [0070] Les adaptateurs sont encapsulés dans des directives interprétables par la routine adaptative 110, c'est-à-dire sous forme d'applications. Deux listes de directives (correspondant aux adaptateur et adaptateur inverse) peuvent ainsi être stockées dans chaque profil, en tant qu'objets. Ces objets peuvent ainsi être aisément reconnus par la routine adaptative 110 comme adaptateurs à exécuter. Leur format (directives interprétables) permet avantageusement de s'affranchir des schémas restrictifs de l'art antérieur où seules des indirections (liste de certaines adresses) sont proposées pour une éventuelle correction. [0071] Bien que les profils représentés sur la figure aient chacun un adaptateur et un adaptateur inverse, un ou plusieurs profils installés sur l'élément sécurisé 10 peuvent n'avoir aucun adaptateur, notamment s'ils ne nécessitent (pour leur utilisation) aucune adaptation de l'environnement d'exécution 100 et de ses ressources d'exécution 108. [0072] Dans l'exemple, un profil (ici Pl) est désactivé lorsqu'un autre profil (ici P2) est activé. D'autres profils peuvent être prévus, préférablement désactivés pour le cas où un seul profil est actif à la fois au sein de l'élément sécurisé 10. [0073] Le domaine ECASD 230 est responsable de la sécurisation des domaines de sécurité 200, 210, 220 et des fonctions d'authentification de l'eUICC 10, en stockant les clés et autres certificats associés aux domaines de sécurité. [0074] Grâce aux adaptateur et adaptateur inverse selon l'invention, l'environnement d'exécution 100 peut être adapté dynamiquement à un profil particulier à utiliser, sans contrainte pour l'opérateur du profil. Il peut en particulier être adapté dynamiquement lors de changements de profils, c'est-à-dire en fonction du cycle de vie des différents profils stockés dans l'élément sécurisé 10. [0075] Tout type de ressource d'exécution 108 peut être adaptée dynamiquement, contrairement aux techniques connues généralement limitées uniquement à la modification de certaines ressources prédéterminées (généralement une liste d'indirections possibles sur ces ressources). [0076] Une gestion appropriée des adaptateurs comme décrite par la suite (utilisant notamment les adaptateurs inverses pour restaurer l'environnement d'exécution) permet ainsi de faire cohabiter, au sein d'un même élément sécurisé 10, des profils qui sont potentiellement incompatibles entre eux. [0077] La Figure 3 illustre, à l'aide d'un ordinogramme, des étapes générales pour le dé- ploiement des adaptateurs 211, 221 et adaptateurs inverses 212, 222 dans un élément 12 sécurisé 10. [0078] De façon préalable, un environnement d'exécution initial 100 (par exemple un système d'exploitation OS et/ou un système Java Card avec machine virtuelle Java Card) est généré (étape 300) pour installation sur l'élément sécurisé 10 (étape 302) selon des techniques classiques. Par exemple, l'installation de l'environnement d'exécution 100 peut être réalisée, en usine, lors de la fabrication, pré-personnalisation ou personnalisation de l'élément sécurisé 10. En variante, elle peut être effectuée à distance par OTA (OTA pour over-the-air - voir par exemple les standards GSMA SGP 22 RSP - Technical Specification - Version 2.2.1 du 18 Décembre 2018, GSMA SGP .02 - Remote Provisioning Architecture for Embedded UICC - Technical Specification - Version 4.0 du 25 Février 2019, GlobalPlatform Card - Remote Application Management over HTTP - Card Specification v2.2 - Amendment B - version 1.1.3 ) via le serveur distant 30, par exemple lors d'une mise à jour de l'OS ou de la machine virtuelle Java Card. [0079] A tout instant, un fournisseur de service (un opérateur mobile dans l'exemple qui suit) peut souhaiter installer un profil de service (un profil abonné mobile P2 dans l'exemple qui suit, mais pouvant également être un profil bancaire lié à un service bancaire, un profil transport lié à un service de transport, etc.) dans l'élément sécurisé 10. Les étapes 304 et suivantes sont donc réalisées autant de fois qu'il y a de profils à installer, lorsque ceux-ci requièrent une adaptation de l'environnement d'exécution 100. [0080] Pour tenir compte des spécificités propres au service fourni, l'opérateur génère (étape 304) un environnement d'exécution spécifique à ce service. On dénomme ci-après cet environnement d'exécution spécifique « l'environnement d'exécution adapté au profil P2 ». Cette étape peut partir de l'environnement d'exécution 100 initial tel que créé à l'étape 300. [0081] La Figure 4 illustre un exemple d'adaptation d'une ressource d'exécution 108 basée sur la technologie Java, par exemple Java Card. [0082] La ressource d'exécution 108 est ici un descripteur de classe Java tel que connu dans l'art antérieur, comprenant par exemple des interfaces, des champs, des méthodes et/ou des attributs. La classe Java peut être instanciée en objets utilisés par les profils. Dans l'exemple, les objets A et B sont deux instances de la classe 108 telle que prévue dans l'environnement d'exécution initial 100 (i.e. créé à l'étape 300). Les objets A et B ont été créés pour le profil P3, qui implémentent par exemple une méthode de la classe définie dans l'environnement d'exécution initial 100. [0083] Dans l'environnement d'exécution spécifique au profil P2, le descripteur de classe Java est modifié pour par exemple comprendre une ou plusieurs interfaces, champs, méthodes et/ou attributs modifiés qui correspondent aux spécificités du service de 13 l'opérateur MNO2 du profil P2. Par exemple, une méthode différente (que celle prévue dans la classe 108) peut être nécessaire pour réaliser une opération du service de l'opérateur MNO2. Une instanciation de cette classe modifiée ou « adaptée » est réalisée au travers de l'objet C, créé pour le profil P2. L'objet C comporte ainsi par exemple la méthode modifiée 400. [0084] Dc même dans l'environnement d'exécution spécifique au profil Pl, le descripteur de classe Java est modifié aux spécificités du service de l'opérateur MNO1 du profil Pl . L'objet D instancié pour cc profil comporte ainsi par exemple la méthode modifiée 402. [0085] Dc retour à la Figure 3, à l'étape 306, les adaptateur 221 et adaptateur inverse 222 spécifiques au profil P2 considéré sont générés. Chaque adaptateur peut notamment être la différence binaire entre les deux environnement d'exécution générés aux étapes 300 et 304: l'adaptateur 221, la différence entre l'environnement d'exécution initial 100 et l'environnement d'exécution spécifique (ou adapté) de l'étape 304 et l'adaptateur inverse 222, la différence entre l'environnement d'exécution spécifique de l'étape 304 et l'environnement d'exécution initial 100. [0086] Dans le cas de la Figure 4, les adaptateur 221 et adaptateur inverse 222 pour le profil P2 comportent la définition additive des composants supplémentaires 400 (pour l'adaptateur 221) et la définition soustractive des composants supplémentaires 400 (pour l'adaptateur inverse 222), respectivement. [0087] A l'étape 308 de la Figure 3, les adaptateurs générés 221, 222 sont encapsulés dans des directives interprétables par la routine adaptative 110 de l'environnement d'exécution 100. Ces directives sont elles-mêmes encapsulées à l'étape 310 dans une application, typiquement une applet Java Card type fichier CAP, en tant que deux composants supplémentaires (« custom components » dans la spécification Java Card). L'application peut être marquée, par exemple à l'aide d'un entête prédéfini, comme contenant les adaptateurs. [0088] A l'étape 312, cette application est ajoutée dans un package du profil P2, ce package (Profile Package selon certains normes SIM Alliance) ayant vocation à être déployé dans l'élément sécurisé 10 sur le terrain. La création d'un package de profil pour son installation dans un élément sécurisé et l'ajout d'applications dans celui-ci sont connus de l'homme de l'art. Par exemple, le package peut être généré conformément au document « SIMalliance eUICC Profile Package Interoperable Format Technical Specification », Version 2.2. [0089] Puis le package est envoyé, via le serveur distant 30, à l'élément sécurisé 10, lors de l'étape 314. [0090] L'étape suivante 316 prend place dans l'élément sécurisé 10 recevant le package envoyé au sein duquel se trouvent les adaptateurs. De façon connue, l'élément sécurisé 14 10 procède à l'installation du profil P2 à l'aide du package reçu. Une procédure de chargement et installation d'un profil est par exemple décrite dans le document « GSMA SGP .22 - RSP Technical Spécification », Version 2.1 du 27 février 2017. [0091] Lors de l'installation, l'environnement d'exécution reconnait le marquage de l'applet des adaptateurs. Il peut ainsi traiter cette applet pour en extraire les directives interprétables (représentant chacun des adaptateurs 221 et 222) et les stocker en lien avec le profil P2, par exemple dans l'ISD-P2 formant ce profil. En d'autres termes, les adaptateur 221 et adaptateur inverse 222 sont stockés dans la mémoire réservée au profil P2 dans l'élément sécurisé 10. [0092] Dans une variante de réalisation, seul l'adaptateur 221 de l'environnement d'exécution initial 100 est généré à l'étape 306. Dans cette variante, l'adaptateur inverse 222 peut être généré (et installé) par l'élément sécurisé 10 par exemple lors de l'installation de l'adaptateur 221 (étape 316) ou lors de la première utilisation/application de l'adaptateur 221. Dans ce cas, c'est l'élément sécurisé 10 (et non plus un équipement à l'usine ou un serveur distant) qui obtient l'environnement d'exécution spécifique (adapté) en appliquant l'adaptateur reçu à l'environnement d'exécution initial 100, puis détermine la différence binaire entre cet environnement d'exécution spécifique et l'environnement d'exécution initial 100 pour construire l'adaptateur inverse. [0093] Bien que la Figure 3 soit décrite en lien avec un package d'installation du profil P2 dans l'élément sécurisé, le même mécanisme peut être mis en oeuvre avec un package de mise à jour du profil P2. [0094] Les Figures 5 à 7 illustrent, à l'aide de logigrammes, l'utilisation des adaptateurs et adaptateurs inverses en fonction de l'activation, désactivation et suppression des profils associés. Ces figures illustrent ainsi comment les adaptateurs et les adaptateurs inverses sont appliqués en fonction du cycle de vie des profils. [0095] Les Figures 5 et 6 illustrent notamment l'application des adaptateurs à l'environnement d'exécution initial 100 lors d'une activation d'un des profils et l'application des adaptateurs inverses à l'environnement d'exécution adapté lors d'une désactivation ou suppression du profil. On obtient ainsi une adaptation dynamique et à la volée de l'environnement d'exécution aux différents profils successivement activés (puis désactivés), en appliquant successivement les étapes des Figures 5 et 6. [0096] 11 peut y avoir autant d'adaptations possible de l'environnement d'exécution qu'il y a d'opérateurs (ou de profils). Dans l'exemple de la Figure 4, la classe 108 est utilisée pour instancier les objets A et B lorsque le profil P3 est actif (l'environnement d'exécution n'étant pas adapté). Puis le profil PI est activé (en lieu et place de P3), l'environnement d'exécution étant alors adapté en conséquence (avec l'adaptateur 211 ajoutant la méthode 402) et l'objet D est instancié à partir de la classe 108 modifiée avec la méthode 402 propre à Pl . Puis le profil P2 est activé (en lieu et place de P1), conduisant à l'application de l'adaptateur inverse 212 de Pl (désactivation de Pl) et à l'application de l'adaptateur 221 de P2 pour adapter l'environnement d'exécution à P2. L'objet C est alors instancié à partir de la classe 108 modifiée avec la méthode 400 propre à P2. [0097] A l'étape 500, l'élément sécurisé 10, et plus précisément l'ISD-R 200, reçoit une commande d'activation d'un profil. Dans l'exemple de la Figure 2, la commande peut demander l'activation du profil P1 inactif. Cette demande peut également être interprétée comme une commande de désactivation, au préalable, du profil actif, ici P2. Dans cc cas, le proccss dc la Figure 6 est exécuté pour la désactivation du profil P2 avant le process de la Figure 5 pour l'activation du profil Pl. [0098] Des exemples de commande et de procédure d'activation (Profile Etiabling) sont décrits dans les documents GSMA SGP.02 (« Remote Provisioning Architecture for Embedded UICC Technical Spccification », Version 3.2 du 27 juin 2017) et GSMA SGP.22. [0099] A l'étape 502, l'ISD-R 200 débute l'exécution de la commande d'activation dc façon classique. Pendant cette exécution, l'ISD-R 200 appelle la routine adaptative 110 pour le compte de l'ISD-Pl . A l'étape 504, la routine adaptative 110 récupère l'adaptateur 211 du profil Pl à activer (et non l'adaptateur inverse 212). [0100] La nature de la commande (activation ou désactivation par exemple) permet à la routine adaptative 110 de récupérer soit l'adaptateur pour adapter l'environnement d'exécution initial (commande d'activation) soit l'adaptateur inverse pour le restaurer (commande de désactivation/suppression). [0101] Le système d'exploitation de l'eUICC connaît en permanence l'état courant de l'environnement d'exécution, c'est-à-dire quel profil est actif, grâce à une valeur persistante mise en mémoire qui indique par exemple le cycle de vie des profils. Sur la base de cette information, la routine adaptative 110 peut donc récupérer l'adaptateur idoine : Ainsi, le système d'exploitation sait continuellement quel profil est couramment actif. S'il apparaît qu'aucun profil n'est actif et donc que l'environnement d'exécution n'est pas adapté, la routine adaptative 110 peut alors récupérer l'adaptateur du profil à activer en cas de commande d'activation. En revanche, s'il apparaît qu'un profil est couramment actif, la routine adaptative 110 peut récupérer l'adaptateur inverse du profil actif en cas de commande de désactivation ou suppression de ce profil. [0102] Si aucun adaptateur n'est disponible (par exemple parce que le profil ne requiert pas d'adaptation de l'environnement d'exécution), le procédé passe directement à l'étape 506. En variante, un adaptateur par défaut peut être stocké avec la routine adaptativel10 (avec un adaptateur inverse par défaut correspondant), lequel adaptateur 16 par défaut est appliqué par la routine en l'absence d'adapter spécifique au profil à activer. [0103] Toujours à l'étape 504, la routine adaptative 110 applique l'adaptateur 211 récupéré de sorte à adapter dynamiquement l'environnement d'exécution initial 100 au profil Pl. Dans l'exemple de la Figure 4, la classe 108 est adaptée pour contenir par exemple la méthode modifiée 400. [0104] A l'étape 506, l'ISD-R 200 poursuit l'exécution de la commande d'activation de façon classique, aboutissant à l'activation du profil Pl. Le registre mémorisant un identifiant du profil actif est mis à jour (mis à la valeur de l'identifiant de P1). [0105] Le profil Pl peut ainsi être utilisé dans l'environnement d'exécution adapté. L'environnement d'exécution adapté fonctionne totalement selon les caractéristiques de l'adaptateur appliqué, garantissant que les fonctions ou données spécifiques à l'opérateur MNO1 sont disponibles. [0106] Après utilisation, le profil Pl peut être désactivé (par exemple parce qu'un autre profil, P2 dans l'exemple, est activé) conformément à la Figure 6. A l'étape 600, l'ISD-R 200 reçoit donc une commande de désactivation (Profile Disabling) du profil Pl. [0107] A l'étape 604, l'ISD-R 200 débute l'exécution de la commande de désactivation de façon classique. Pendant cette exécution, l'ISD-R 200 appelle la routine adaptative 110. Soit l'indication du profil (ici P1) à désactiver est indiquée dans la commande, soit la routine adaptative 110 peut utiliser le registre mémorisant un identifiant du profil actif. A l'étape 606, la routine adaptative 110 récupère l'adaptateur inverse 212 du profil PI à désactiver. Si aucun adaptateur inverse n'est disponible (par exemple parce que l'environnement d'exécution n'a pas eu besoin d'être adapté au profil actif), le procédé passe directement à l'étape 608 ou, en variante, l'adaptateur inverse par défaut est récupéré. [0108] Toujours à l'étape 606, la routine adaptative 110 applique l'adaptateur inverse 212 récupéré de sorte à restaurer l'environnement d'exécution initial 100. Dans l'exemple de la Figure 4, la classe 108 est restaurée sans la méthode modifiée 400. [0109] A l'étape 608, l'ISD-R 200 poursuit l'exécution de la commande d'activation de façon classique, aboutissant à la désactivation du profil Pl. Le registre mémorisant un identifiant du profil actif est mis à jour (mis à 0). [0110] Dans un mode de réalisation, il peut être bénéfique de supprimer, de la mémoire, des données du profil Pl à désactiver. C'est le cas par exemple des objets Java instanciés pendant l'utilisation du profil Pl, afin de libérer de l'espace mémoire 14 qui peut être limité dans l'élément sécurisé 10. [0111] Cette opération est menée par le garbage collector 112. Selon un mode de réalisation, celui-ci est configuré pour scanner uniquement les objets du profil actif en vue de la 17 collecte. En effet, si un objet est issu d'une classe qui est adaptée pour un profil, la structure de cet objet n'est reconnue que si l'environnement d'exécution est adapté. En d'autres termes, le garbage collector 1 1 2 risque de ne pas reconnaitre la structure d'un objet appartenant au profil P si l'environnement d'exécution n'est pas adapté. [0112] En outre, il faut veiller à limiter l'intervention du garbage collector 1 1 2 au seul profil courant afin d'éviter toute corruption (par suppression non souhaitée d'objets) d'un autre profil. Aussi, les objets auront été créés dans le JCRE en respectant, de préférence, un cloisonnement des profils les uns avec les autres, impliquant notamment qu'aucun objet d'un profil ne pointe vers un objet d'un autre profil. Cela permet un mécanisme de nettoyage (garbage collector) simplifié tout en améliorant également la sécurité au niveau des profils. [0113] Le nettoyage est ainsi réalisé à l'étape optionnelle 602 précédant l'application de l'adaptateur inverse (étape 606) et consiste pour l'ISD-R 200 à lancer une exécution du garbage collector 112 pour le compte du profil actif (identifiant indiqué dans le commande de lancement ou récupéré du registre mémorisant l'identifiant du profil actif). Cette exécution comporte la collecte des objets instanciés (par exemple à partir de la classe 108 mais pas uniquement) pour le profil Pl uniquement (celui à désactiver) puis la suppression de ceux-ci. Le garbage collector 112 ne collecte pas ici d'éventuels objets instanciés pour d'autres profils ni au sein du JCRE. [0114] Les objets instanciés pour le profil Pl peuvent être ceux stockés dans un espace mémoire réservé à l'ISD-Pl. [0115] En variante, les objets peuvent être instanciés par la machine virtuelle JCVM en les estampillant d'un marquage (ou indicateur) représentatif de leurs profils Ainsi, le garbage collector 112 peut facilement identifier les objets liés au profil PI à désactiver. [0116] Selon une autre variante, une table de correspondance peut être maintenue à jour qui liste les objets créés pour chaque profil. Ainsi le garbage collector 112 peut rapidement identifier les objets liés au profil Pl à désactiver. [0117] Selon une autre variante, un jeu d'indirections peut être mis en place qui indique les emplacements (adresses mémoire) où sont stockés les objets instanciés pour chaque profil. [0118] Bien que ce mécanisme de collecte par le garbage collector 112 soit présenté en lien avec la désactivation d'un profil, il peut également être mis en oeuvre lors de la suppression d'un profil comme décrit ci-dessous en lien avec la Figure 7 : les objets appartenant au profil à supprimer sont collectés par la garbage collector puis supprimés. [0119] Selon une autre variante, les objets créés peuvent être collectés à n'importe quel moment pour suppression, par exemple lors d'une saturation mémoire. [0120] Dans cet exemple de la Figure 5, l'adaptation est réalisée une seule fois lors de l'activation du profil PI. En variante, le profil PI peut être activé de façon classique 18 sans adaptation (à ce stade) de l'environnement d'exécution initial 100 et une adaptation à l'aide de l'adaptateur 211 peut être lancée (étapes 502 et 504) à l'occasion d'autres événements, par exemple à chaque accès au profil Pl . Un accès au profil Pl peut avoir lieu lors d'une procédure d'authentification (d'un service réseau, bancaire ou transport par exemple) ou lors de l'appel à une application située dans le profil Pl. Dans cette variante, l'environnement d'exécution initial 100 peut être restauré (en utilisant les étapes 602 à 606) à l'issue de ces opérations, c.g. de la procédure d'authentification ou de l'exécution de l'application située dans le profil Pl . [0121] La Figure 7 illustre des étapes lors de la suppression d'un profil. [0122] A l'étape 700, l'élément sécurisé 10, et plus précisément l'ISD-R 200, reçoit une commande de suppression (Profile Deletion) d'un profil P, par exemple conforme aux documents GSMA mentionnés plus haut. [0123] Pour une utilisation efficace du garbagc collector 112, l'environnement d'exécution est adapté au profil à supprimer. Ainsi, à l'étape 702, l'ISD-R 200 appelle la routine adaptative 110 pour le compte du profil à supprimer. A l'étape 704, la routine adaptative 110 récupère l'adaptateur 211 ou 221 du profil P à supprimer (et non l'adaptateur inverse 212 ou 222), puis l'applique de sorte à adapter l'environnement d'exécution initial 100 au profil P. [0124] A l'étape 706 (similaire à l'étape 602 décrite plus haut), l'ISD-R 200 qui reprend la main lance une exécution du garbagc collector 112 pour le compte du profil P à supprimer. Cette exécution comporte la collecte des objets instanciés (à partir d'une classe reconnue, possiblement adaptée) pour le profil P uniquement (celui à supprimer) puis la suppression de ceux-ci. [0125] A l'étape 708, l'ISD-R 200 supprime les éléments constitutifs du profil P, notamment données et applications. Lors de cette opération, l'adaptateur inverse 212 ou 222 est ajouté dans les racines de persistance du JCRE afin de le conserver (il n'est pas vu et donc pas supprimé par l'ISD-R 200). [0126] Suite à cette suppression des éléments constitutifs du profil P, l'environnement d'exécution initial 100 peut désormais être restauré lors de l'étape 710. Pour ce faire, l'ISD-R 200 appelle à nouveau la routine adaptative 110, qui récupère l'adaptateur inverse 212 ou 222 du profil P à supprimer, puis l'applique de sorte à restaurer l'environnement d'exécution initial 100. [0127] A l'étape 712, l'ISD-R 200 supprime l'adaptateur inverse du profil P (après l'avoir retiré des racines de persistance du JCRE). Cette étape clôt la suppression complète du profil P. L'environnement d'exécution initial 100 peut ainsi reprendre la main sur l'exécution dans l'élément sécurisé 10. [0128] Dans un mode de réalisation, une routine de nettoyage de l'environnement d'exécution peut déclencher, sur commande ou périodiquement ou sur tout autre 19 événement, une opération de nettoyage des objets inutiles pour libérer de l'espace mémoire, alors même qu'aucun profil ne peut être actif. Cette routine peut ainsi considérer successivement tout ou partie des profils installés (par exemple le ou les profils déterminés selon une règle prédéfinie - à titre illustratif le dernier profil utilisé) et pour un profil P considéré : - récupérer (étape 702) et appliquer (étape 704) l'adaptateur du profil P pour obtenir l'environnement d'exécution adapté ; - lancer le garbagc collector 112 (étape 706) pour collecter les objet du profil Pet les supprimer (étape 708); puis - récupérer et appliquer (étape 710) l'adaptateur inverse du profil P pour restaurer l'environnement d'exécution initial. [0129] Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. [0130] Notamment ces exemples concernent principalement une application de téléphonie mobile avec des profils Pl, P2 d'abonnés, une infrastructure de réseau mobile et des opérateurs mobiles, ils sont transposables sans difficultés à tout type de profil de service (incluant les configurations selon GlobalPlatform), tout type de serveur distant et tout type de fournisseur de service. [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5] [Revendication 6] [Revendication 7] REVENDICATIONSElément sécurisé (10) comprenant un environnement d'exécution initial (100), un premier profil de service (P 1 , P2, 210, 220), des données adaptatives (211, 221) de l'environnement d'exécution initial en un environnement d'exécution adapté au premier profil de service, une routine adaptative (110) configurée pour appliquer les données adaptatives à l'environnement d'exécution initial, caractérisé en ce qu'il comprend en outre des données adaptatives inverses (212, 222) pour restaurer l'environnement d'exécution initial depuis l'environnement d'exécution adapté, la routine adaptative étant configurée pour appliquer les données adaptatives inverses après utilisation du premier profil de service. Elément sécurisé (10) selon la revendication 1, dans lequel la routine adaptative (110) est configurée pour appliquer les données adaptatives et les données adaptatives inverses en fonction du cycle de vie du premier profil de service. Elément sécurisé (10) selon la revendication 2, dans lequel la routine adaptative (110) est configurée pour appliquer les données adaptatives à l'environnement d'exécution initial lors d'une activation du premier profil de service et pour appliquer les données adaptatives inverses à l'environnement d'exécution adapté lors d'une désactivation ou suppression du premier profil de service. Elément sécurisé (10) selon l'une des revendications 1 à 3, dans lequel les données adaptatives et les données adaptatives inverses sont stockées sous forme de listes de directives interprétables par la routine adaptative. Elément sécurisé (10) selon l'une des revendications 1 à 4, comprenant en outre un moyen de communication pour recevoir les données adaptatives et les données adaptatives inverses au sein d'un package d'installation du premier profil de service transmis par un équipement externe (30). Elément sécurisé (10) selon l'une des revendications 1 à 5, comprenant en outre un module de génération des données adaptatives inverses à partir des données adaptatives reçues d'un équipement réseau distant (30). Elément sécurisé (10) selon l'une des revendications 1 à 6, comprenant en outre un deuxième profil choisi parmi : - un profil de service utilisable dans l'environnement d'exécution initial, 21 [Revendication 8] [Revendication 9] [Revendication 10] [Revendication 11] [Revendication 12] - un profil de service utilisable dans un environnement d'exécution modifié obtenu par l'application d'autres données adaptatives (221) différentes desdites données adaptatives (211) à l'environnement d'exécution initial, ce profil de service comportant les autres données adaptatives et des autres données adaptatives inverses (222) pour restaurer l'environnement d'exécution initial depuis l'environnement d'exécution modifié. Elément sécurisé (10) selon l'une des revendications 1 à 7, comprenant en outre un collecteur de déchets (112) collectant des ressources de profil non référencées stockées en mémoire, le collecteur de déchets étant configure pour effectuer la collecte uniquement parmi les ressources de profil liées à un ou plusieurs profils de service particuliers. Elément sécurisé (10) selon l'une des revendications 1 à 8, dans lequel les données adaptatives (211, 221) sont configurécs pour adapter une classe Java initiale (108) de l'environnement d'exécution initial (100) à un format d'un objet instanciant la classe Java dans le premier profil de service, et les données adaptatives inverses (212, 222) sont configurées pour restaurer la classe Java initiale (108) depuis la classe Java adaptée. Procédé d'exécution dans un élément sécurisé (10) comprenant un environnement d'exécution initial (100) et un premier profil de service (P1, P2, 210, 220), le procédé comprenant les étapes suivantes : - appliquer (504, 704), par une routine adaptative (110), des données adaptatives (211, 221) de l'environnement d'exécution initial pour obtenir un environnement d'exécution adapté au premier profil de service, - utiliser le premier profil de service dans l'environnement d'exécution adapté, - puis appliquer (606, 710), par la routine adaptive, des données adaptatives inverses (212, 222) à l'environnement d'exécution adapté pour restaurer l'environnement d'exécution initial. Procédé selon la revendication 9, dans lequel les données adaptatives (211, 221) et les données adaptatives inverses (212, 222) sont appliquées en fonction du cycle de vie du premier profil de service. Procédé selon l'une des revendications 9 et 10, dans lequel les données adaptatives sont appliquées à l'environnement d'exécution initial lors d'une activation (500) du premier profil de service et les données adaptatives inverses sont appliquées à l'environnement d'exécution adapté lors d'une désactivation (600) ou suppression (700) du premier [Revendication 13] profil de service. [Revendication 14] Procédé selon l'une des revendications 9 à 11, dans lequel les données adaptatives et les données adaptatives inverses sont stockées sous forme de listes de directives interprétables par la routine adaptive. [Revendication 15] Procédé selon l'une des revendications 9 à 12, dans lequel l'élément sécurisé comprend en outre un deuxième profil choisi parmi : [Revendication 16] - un profil de service utilisable dans l'environnement d'exécution initial, - un profil de service utilisable dans l'environnement d'exécution modifié obtenu par l'application d'autres données adaptatives (221) différentes desdites données adaptatives (211) à l'environnement d'exécution initial, ce profil de service comportant les autres données adaptatives et des autres données adaptatives inverses (222) pour restaurer l'environnement d'exécution initial depuis l'environnement d'exécution modifié. Procédé selon l'une des revendications 9 à 13, dans lequel l'élément sécurisé comprend en outre un collecteur de déchets (112) collectant des ressources de profil non utilisées stockées en mémoire, le collecteur de déchets étant configure pour effectuer la collecte (602, 706) uniquement parmi les ressources de profil liées à un profil de service particulier. Support tangible comprenant un produit programme d'ordinateur comprenant des instructions configurées pour une mise en oeuvre des étapes du procédé selon l'une des revendications 9 à 14, lorsque ledit programme est exécuté sur un ordinateur.