Brevet FR3094526A1 — publié le 20201002

Description Titre de l'invention : Dément sécurisé embarqué Domaine technique [0001] La présente description concerne de façon générale les systèmes électroniques, et de façon plus particulière les systèmes électroniques embarqués. La présente description concerne encore plus particulièrement l'utilisation des mémoires dans un système électronique embarqué. Technique antérieure [0002] Un système électronique embarqué est un système électronique et logiciel autonome adapté à être embarqué dans un appareil électronique et/ou un équipement électronique. [0003] Les difficultés dc conception d'un système embarqué sont fréquemment liées à des contraintes d'encombrement et de consommation énergétique. Une difficulté connue de conception des systèmes embarqués est l'optimisation de la sauvegarde des données, et, plus particulièrement, dc l'utilisation de différentes mémoires comprises dans le système embarqué. A titre d'exemple, le système peut comprendre des mémoires mortes, des mémoires non volatiles et des mémoires volatiles, chacune étant adaptée à stocker des données de différents types. [0004] Il serait souhaitable de pouvoir améliorer, au moins en partie, certains aspects des systèmes électroniques embarqués connus, plus particulièrement dc pouvoir améliorer, au moins en partie, certains aspects dc l'utilisation des mémoires dans les systèmes électroniques embarqués. Résumé de l'invention 100051 11 existe un besoin dans la technique pour des systèmes embarqués plus performants. 100061 11 existe, plus particulièrement, un besoin dans la technique pour des systèmes embarqués dans lequel l'utilisation des mémoires est optimisée. 100071 Un mode de réalisation prévoit un élément sécurisé embarqué comprenant une mémoire volatile, et étant configuré pour mettre en oeuvre au moins une partie d'une première application adaptée à être mise en oeuvre par au moins un système d'exploitation de bas niveau de l'élément sécurisé embarqué, dans lequel des données d'exécution de ladite première application sont stockées dans une partie de ladite mémoire volatile configurée pour stocker uniquement des données d'exécution de ladite première application. 100081 Un autre mode de réalisation prévoit un procédé d'exécution d'au moins une première application adaptée à être mise en oeuvre par au moins un système d'exploitation de bas niveau dans un élément sécurisé embarqué comprenant une mémoire volatile, dans 2 lequel des données d'exécution de ladite première application sont stockées dans une partie d'une mémoire volatile configurée pour recevoir uniquement des données d'exécution de ladite première application. [0009] Selon un mode de réalisation, ledit au moins un système d'exploitation de bas niveau est un système d'exploitation adapté à échanger des commandes directement avec des composants de l'élément sécurisé embarqué. [0010] Selon un mode de réalisation, les données d'exécution d'une application sont des données temporaires utilisées par une application uniquement pendant son exécution. [0011] Selon un mode de réalisation, la partie de ladite première application est la totalité de ladite première application. [0012] Selon un mode de réalisation, l'élément sécurisé embarqué est configure pour mettre en oeuvre au moins une deuxième application adaptée à être mise en oeuvre par au moins un système d'exploitation de bas niveau de l'élément sécurisé embarqué. [0013] Selon un mode de réalisation, les données d'exécution de ladite deuxième application sont stockées dans une partie de la mémoire volatile quand ladite deuxième application est active, et dans une partie d'une mémoire non volatile quand ladite deuxième application est non active. [0014] Selon un mode de réalisation, les données d'exécution de ladite deuxième application sont supprimées de la mémoire volatile quand ladite deuxième application est non active. [0015] Selon un mode de réalisation, toutes les données d'exécution de ladite deuxième ap- plication sont stockées dans une mémoire non volatile. [0016] Selon un mode de réalisation, les données d'exécution nécessaires à l'exécution de ladite deuxième application sont déplacées de la mémoire non volatile vers la mémoire volatile quand ladite deuxième application est active. [0017] Selon un mode de réalisation, des données d'exécution de ladite première ou de ladite deuxième application sont déplacées vers une partie d'une mémoire non volatile quand la mémoire volatile est pleine. [0018] Selon un mode de réalisation, les données d'exécution de ladite deuxième application sont supprimées de la mémoire volatile quand ladite mémoire est pleine. [0019] Selon un mode de réalisation, la mémoire non volatile est interne à l'élément sécurisé. [0020] Selon un mode de réalisation, la mémoire non volatile est externe à l'élément sécurisé. [0021] Un autre mode de réalisation prévoit une application adaptée à être mise en oeuvre par au moins un système d'exploitation de bas niveau dans un élément sécurisé embarqué décrit précédemment. 3 Brève description des dessins [0022] Ces caractéristiques et avantages, ainsi que d'autres, seront exposés en détail dans la description suivante de modes de réalisation particuliers faite à titre non limitatif en relation avec les figures jointes parmi lesquelles : [0023] [fie.1] la figure 1 représente, de façon schématique et sous forme de blocs, une ar- chitecture logicielle d'un système électronique embarqué ; [0024] [fie.2] la figure 2 représente des vues (a), (b) et (c) illustrant, de façon schématique et sous forme de blocs, la mise en oeuvre d'un procédé d'exécution d'applications du système électronique embarqué de la figure 1 ; [0025] [fie.3] la figure 3 représente des vues (a), (b) et (c) illustrant, de façon schématique et sous forme de blocs, un mode de mise en oeuvre d'un procédé d'exécution d'applications du système électronique embarqué de la figure 1 ; [0026] [fig.4] la figure 4 représente des vues (a), (h) et (c) illustrant, de façon schématique et sous forme de blocs, la mise en oeuvre d'un procédé d'exécution d'applications du système électronique embarqué de la figure 1 ; et [0027] [fig.51 la figure 5 représente des vues (a), (h) et (c) illustrant, de façon schématique et sous forme de blocs, un autre mode de mise en oeuvre d'un procédé d'exécution d'applications du système électronique embarqué de la figure 1. Description des modes de réalisation [0028] De mêmes éléments ont été désignés par de mêmes références dans les différentes figures. En particulier, les éléments structurels et/ou fonctionnels communs aux différents modes de réalisation peuvent présenter les mêmes références et peuvent disposer de propriétés structurelles, dimensionnelles et matérielles identiques. [0029] Par souci de clarté, seuls les phases et éléments utiles à la compréhension des modes de réalisation décrits ont été représentés et sont détaillés. [0030] Sauf précision contraire, lorsque l'on fait référence à deux éléments connectés entre eux, cela signifie directement connectés sans éléments intermédiaires autres que des conducteurs, et lorsque l'on fait référence à deux éléments reliés ou couplés entre eux, cela signifie que ces deux éléments peuvent être connectés ou être reliés ou couplés par l'intermédiaire d'un ou plusieurs autres éléments. [0031] Dans la description qui suit, lorsque l'on fait référence à des qualificatifs de position absolue, tels que les termes "avant", "arrière", "haut', "bas", "gauche", "droite", etc., ou relative, tels que les termes "dessus", "dessous", "supérieur", "inférieur", etc., ou à des qualificatifs d'orientation, tels que les termes "horizontal", "vertical", etc., il est fait référence sauf précision contraire à l'orientation des fleures. [0032] Sauf précision contraire, les expressions "environ", "approximativement", "sen- siblement", et "de l'ordre de" signifient à 10 % près, de préférence à 5 % près. [0033] La figure 1 représente, de façon schématique et sous forme de blocs, une architecture logicielle 100 d'un élément sécurisé embarqué E, ou système électronique embarqué sécurisé. [0034] L'architecture comprend une plateforme primaire 110 comprenant l'accès aux composants électroniques 111 (HW, Hardware) de l'élément sécurisé E, et comprenant des systèmes d'exploitation de bas niveau 113 (LLOS, Low Level Operating System). [0035] Les composants de l'élément sécurisé E sont, par exemple, un ou plusieurs pro- cesseurs, une ou plusieurs mémoires, un ou plusieurs dispositifs de communication, etc. A titre d'exemple, les dispositifs de communication permettent de communiquer directement avec un dispositif de communication en champ proche (NFC, Ncar Field Communication), un dispositif de communication à courte distance utilisant, par exemple, la norme Bluctooth, des capteurs hiométriqucs, etc. [0036] Les systèmes d'exploitation de bas niveau 113 sont des systèmes d'exploitation permettant de faciliter la communication entre un ou plusieurs systèmes d'exploitation de haut niveau (HLOS1, HLOS2, HLOS, High Level Operating System) 124A, 124B (deux systèmes d'exploitation de haut niveau dans le cas illustré en figure 1) de l'élément sécurisé E et les composants 111 de l'élément E. A titre d'exemple, les systèmes d'exploitation de bas niveau comprennent des logiciels pilote des composants 111. A titre d'exemple, les systèmes d'exploitation de bas niveau 113 peuvent permettre d'isoler les systèmes d'exploitation de haut niveau 124A, 124B les uns des autres. Plus particulièrement, les systèmes d'exploitation de bas niveau 113 peuvent gérer l'accès des systèmes d'exploitation de haut niveau 124A, 124B à différentes mémoires. Plus particulièrement, les systèmes d'exploitation de bas niveau 113 peuvent permettre de gérer les données stockées dans lesdites mémoires, et plus particulièrement, gérer l'accès de ces données, surtout dans le cas où plusieurs systèmes d'exploitation de haut niveau sont présents dans l'élément sécurisé E. Les systèmes d'exploitation de bas niveau 113 peuvent, par exemple, interdire l'accès de certaines données à un système d'exploitation de haut niveau. [0037] L'architecture comprend, en outre, des applications adaptées à être mise en oeuvre par la plateforme primaire 110. Ces applications sont, par exemple, adaptées à traiter des commandes provenant d'interfaces de communication, comme par exemple une transaction bancaire utilisant un dispositif de communication en champ proche. Chacune de ces applications est mise en oeuvre à l'aide de données fixes, par exemple les instructions, ou les lignes de code, formant l'application, et de données temporaires, données d'exécution, ou variable. Les données d'exécution d'une application sont des données utilisées par l'application uniquement pendant son exécution. Ces applications peuvent être de différents types, par exemple, une application SIM (Subscriber Identity Module), une application de paiement, une application permettant la validation d'un ticket de transport en commun, etc. [0038] Selon un exemple de type d'application, une application 121 (Appt) est adaptée à être mise en oeuvre directement par plateforme primaire 110. L'application 121 est, par exemple, une application permettant d'effectuer des paiements en communiquant avec un dispositif de communication en champ proche (NFC, Near Field Communication). [0039] Selon un autre exemple de type d'application, une autre application 122 (App2) peut être adaptée à envoyer des commandes à la plateforme primaire 110 par l'intermédiaire d'un des systèmes d'exploitation de haut niveau, ici le système d'exploitation 124B. Cc système d'exploitation de haut niveau peut être, par exemple, un des systèmes d'exploitation de l'élément sécurisé E échangeant des commandes avec la plateforme primaire 110. A titre de variante, on peut également considérer que le système d'exploitation, ainsi que toutes les applications qui lui sont attachées, sont une application adaptée à être mise en oeuvre par la plateforme primaire 110. [0040] Selon un autre exemple de type d'application, une autre application 123 (App3) peut être adaptée à envoyer des commandes à la plateforme primaire 110 par l'intermédiaire d'un environnement d'exécution 125 (ENV) et d'un des systèmes d'exploitation de haut niveau, ici le système d'exploitation 124A. L'environnement d'exploitation est par exemple de type Java ou JavaCard. A titre de variante, on peut également considérer que le système d'exploitation, ainsi que toutes les applications qui lui sont attachées, sont une application adaptée à être mise en oeuvre par la plateforme primaire 110. [0041] Pour mettre en oeuvre ces différentes applications 121, 122, 123, les systèmes d'exploitation 124A, 124B, et l'environnement d'exécution 125, les composants 111 de l'élément sécurisé E comprennent, plus particulièrement, au moins une mémoire non volatile et au moins une mémoire volatile. La mémoire non volatile sert généralement à stocker des données fixes d'une application, et la mémoire volatile sert généralement à stocker les données d'exécution d'une application. [0042] Selon un mode de réalisation, au moins une partie de la mémoire non volatile est utilisée comme une mémoire volatile. Autrement dit, cette partie de la mémoire non volatile forme une mémoire volatile virtuelle pour stocker des données temporaires utilisées par les applications pendant son fonctionnement. A titre d'exemple, la mémoire non volatile peut être interne ou externe à l'élément sécurisé E. Des modes d'utilisation de cette mémoire volatile virtuelle seront décrits en relation avec les figures 2 à 5. [0043] La figure 2 comprend trois vues (a), (b), et (c) illustrant chacune une phase d'une mise en oeuvre d'un procédé d'exécution d'applications App20 et App21 de l'élément sécurisé E décrit en relation avec la figure 1. Ces trois vues illustrent plus particulièrement l'utilisation de la mémoire volatile virtuelle (NVM - Virtual RAM), portant la référence VRAM, et d'une mémoire volatile réelle (Physical RAM), portant la 6 référence PRAM, de l'élément sécurisé E pendant l'activation des applications App20 et App21. [0044] Selon l'exemple décrit en figure 2, l'application App21 a déjà été démarrée, avant le démarrage de l'application App20. L'application App21 est dans un mode "veille", ou non active, dans lequel des données d'exécution représentatives de l'état de l'application App21 sont stockées dans une partie VRAM21 de la mémoire volatile virtuelle VRAM. L'application App20, quant à elle, n'a jamais été démarrée. [0045] A une première phase (vue (a)), l'application App20 est démarrée par l'élément sécurisée E, plus particulièrement, l'application App20 est démarrée par les systèmes d'exploitation de bas niveau 113. Des données d'exécution, relatives à l'application App20 sont téléchargées/chargées dans la mémoire volatile réelle PRAM. [0046] Pendant toute son exécution, et si elle n'est pas interrompue par l'exécution d'une autre application, l'application App20 stocke ses données d'exécution dans la mémoire volatile réelle PRAM. [0047] A une deuxième phase (vue (h)), l'application App21, déjà chargée auparavant, demande à être exécutée par l'élément sécurisé E. [0048] Les données d'exécution relatives à l'application App20 présentes dans la mémoire volatile réelle PRAM sont stockées dans une partie VRAM20 de la mémoire volatile virtuelle VRAM et supprimées de la mémoire volatile réelle PRAM. Ainsi l'état actuel de l'application App20 est sauvegardé dans la mémoire volatile virtuelle VRAM, et l'application App20 passe dans un mode "veille", ou est non active. [0049] Des données d'exécution relatives à l'application App21 stockées précédemment dans une partie VRAM21 sont chargées dans la mémoire volatile réelle PRAM. Ainsi, l'utilisation de l'application App21 peut reprendre là où elle s'était arrêtée précédemment. Autrement dit, l'application VRAM21 sort de son mode "veille", elle est donc active. [0050] A une troisième phase (vue (c)), l'application App21 continue à s'exécuter, et modifie dans la mémoire volatile réelle les données d'exécution chargées, depuis la mémoire volatile virtuelle VRAM, vers la mémoire volatile réelle PRAM. [0051] La figure 3 comprend trois vues (a), (b), et (c) illustrant chacune une phase d'un mode de mise en oeuvre d'un procédé d'exécution d'applications App30 et App31 de l'élément sécurisé E décrit en relation avec la figure 1. Ces trois vues illustrent plus particulièrement l'utilisation de la mémoire volatile virtuelle (NVM - Virtual RAM), portant la référence VRAM, et d'une mémoire volatile réelle (Physical RAM), portant la référence PRAM, de l'élément sécurisé E pendant l'activation des applications App30 et App31. [0052] Selon un mode de réalisation, l'application App30 est une application à usage fréquent, ou application résidente. Les données d'exécution relatives à l'application 7 résidente App30 sont stockées dans une partie PRAM30 réservée de la mémoire volatile réelle PRAM. La partie PRAM30 de la mémoire PRAM est toujours disponible pour stocker les données d'exécution de l'application App30, et les données d'exécution d'une ou d'autres applications ne peuvent y être stockées. [0053] A une première phase (vue (a)), l'application App31 est démarrée par l'élément sécurisée E. Des données d'exécution, relatives à l'application App31 sont téléchargées/chargées dans une partie PRAM31 la mémoire volatile réelle PRAM. La partie PRAM31 est distincte de la partie PRAM30. [0054] Pendant toute son exécution, et si elle n'est pas interrompue par l'exécution d'une autre application, l'application App31 stocke ses données d'exécution dans la partie PRAM31 de la mémoire volatile réelle PRAM. [0055] A une deuxième phase (vue (h)), l'application résidente App30, déjà chargée au- paravant, demande à être exécutée par l'élément sécurisé E, plus particulièrement, par les systèmes d'exploitation de bas niveaux 113. [0056] Les données d'exécution relatives à l'application App31 présentes dans la partie PRAM31 de la mémoire volatile réelle PRAM sont stockées dans une partie VRAM31 de la mémoire volatile virtuelle VRAM. Ainsi l'état actuel de l'application App31 est sauvegardé dans la mémoire volatile virtuelle VRAM, et l'application App31 passe dans un mode "veille" ou est non active. [0057] Des données d'exécution relatives à l'application App30 stockées précédemment dans une partie VRAM30 sont chargées dans la mémoire volatile réelle PRAM. Ainsi, l'utilisation de l'application App30 peut reprendre là où elle s'était arrêtée précédemment. [0058] A une troisième phase (vue (c)), l'application VRAM30 sort de son mode "veille", elle est alors active. L'application App30 continue à s'exécuter, et modifie dans la mémoire volatile réelle PRAM, pour cela, les données d'exécution chargées, depuis la mémoire volatile virtuelle VRAM, vers la mémoire volatile réelle PRAM. [0059] Un avantage de ce mode de réalisation est qu'une application à usage fréquent ou ap- plication résidente est garantie d'avoir de la place dans la mémoire volatile virtuelle VRAM pour y stocker ses données d'exécution de fonctionnement. [0060] La figure 4 comprend trois vues (a), (b), et (c) illustrant chacune une phase d'une mise en oeuvre d'un procédé d'exécution d'applications App40 et App41 de l'élément sécurisé E décrit en relation avec la figure 1. Ces trois vues illustrent plus particulièrement l'utilisation de la mémoire volatile virtuelle (NVM - Virtual RAM), portant la référence VRAM, et d'une mémoire volatile réelle (Physical RAM), portant la référence PRAM, de l'élément sécurisé E pendant l'activation des applications App40 et App41. [0061] Les applications App40 et App41 sont déjà démarrées par l'élément sécurisé E. 8 Toutes les données d'exécution relatives au démarrage et au fonctionnement des applications App40 et App41 sont stockées dans, respectivement, des parties VRAM40 et VRAM41 de la mémoire volatile virtuelle VRAM. [0062] A une première phase (vue (a)), l'application App40 est exécutée par l'élément sécurisé E. Des données d'exécution de démarrage et de fonctionnement relatives à l'application App40 sont téléchargées/chargées dans une partie PRAM40 de la mémoire volatile réelle PRAM, à partir de la partie VRAM40 de la mémoire volatile virtuelle VRAM. [0063] A une deuxième phase (vue (h)), l'application App41 est exécutée par l'élément sécurisé E. Certaines données d'exécution relatives à l'application App41 sont téléchargées/chargées dans une partie PRAM41 de la mémoire volatile réelle PRAM, à partir de la partie VRAM41 de la mémoire volatile virtuelle VRAM. Ces données sont stockées à la suite des données d'exécution relatives à l'application App40 dans la mémoire volatile réelle PRAM. L'application App40 est alors non active. Seules les données d'exécution de l'application utiles sont chargées dans la mémoire volatile réelle PRAM. [0064] A une troisième phase (vue (c)), l'application App41 est toujours exécutée par l'élément sécurisé E, mais la mémoire volatile réelle PRAM n'a plus d'espace disponible pour stocker des données d'exécution relatives à l'application App41 supplémentaires. Certaines données d'exécution relatives à l'application App40 présentes dans la partie PRAM40 sont déplacées vers la partie VRAM40 de la mémoire volatile virtuelle VRAM pour libérer de l'espace de stockage dans la mémoire volatile réelle PRAM. Seules les données d'exécution de l'application utiles sont chargées dans la mémoire volatile réelle PRAM. [0065] La figure 5 comprend trois vues (a), (b), et (c) illustrant chacune une phase d'un mode de mise en oeuvre d'un procédé d'exécution d'applications App50 et App51 de l'élément sécurisé E décrit en relation avec la figure 1. Ces trois vues illustrent plus particulièrement l'utilisation de la mémoire volatile virtuelle (NVM - Virtual RAM), portant la référence VRAM, et d'une mémoire volatile réelle (Physical RAM), portant la référence PRAM, de l'élément sécurisé E pendant l'activation des applications App50 et App51. [0066] Les applications App50 et App51 sont déjà démarrées par l'élément sécurisé E. Toutes les données d'exécution relatives au démarrage et au fonctionnement des applications App50 et App51 sont stockées dans, respectivement, des parties VRAM50 et VRAM51 de la mémoire volatile virtuelle VRAM. [0067] Selon l'exemple décrit en figure 5, l'application App50 est une application à usage fréquent, appelée par la suite une application résidente, aussi décrite en relation avec la figure 3. 9 [0068] A une première phase (vue (a)), l'application résidente App50 est exécutée par l'élément sécurisé E. Des données d'exécution de démarrage et de fonctionnement relatives à l'application App50 sont téléchargécs/chargées dans une partie PRAM50 réservée de la mémoire volatile réelle PRAM, à partir de la partie VRAM50 de la mémoire volatile virtuelle VRAM. La partie PRAM50 est une partie de la mémoire volatile réelle PRAM toujours disponible pour stocker les données d'exécution de l'application App50, et qui ne peut pas être utilisée pour stocker des données d'exécution d'autres applications. [0069] A une deuxième phase (vue (h)), l'application App51 est exécutée par l'élément sécurisé E. Des données d'exécution de démarrage et de fonctionnement relatives à l'application App51 sont téléchargées/chargées dans une partie PRAM51 de la mémoire volatile réelle PRAM, à partir de la partie VRAM51 de la mémoire volatile virtuelle VRAM. Ces données sont stockées à la suite des données d'exécution relatives à l'application App50 dans la mémoire volatile réelle PRAM. L'application App50 est alors non active. [0070] A une troisième phase (vue (c)), l'application App51 est toujours exécutée par l'élément sécurisé E, mais la mémoire volatile réelle PRAM n'a plus d'espace disponible pour stocker des données d'exécution relatives à l'application App51 supplémentaires. Les données d'exécution relatives à l'application App51 ne pouvant être stockées dans la partie PRAM50, certaines données d'exécution relatives à l'application App51 qui ne sont plus utilisées, sont déplacées vers la partie VRAM51 de la mémoire volatile virtuelle VRAM pour libérer de l'espace de stockage dans la mémoire volatile réelle PRAM. [0071] Dans le cas où l'élément sécurisé E met en oeuvre une troisième application, quand la mémoire volatile réelle PRAM n'a plus d'espace disponible pour stocker des données d'exécution, elle déplacera les données de l'application, qui n'est pas résidente, dont l'exécution est la plus ancienne. [0072] Un avantage de ce mode de réalisation est que toutes les applications sont chargées dans la mémoire volatile virtuelle, ce qui permet un démarrage rapide de chaque application. [0073] Un autre avantage de ce mode de réalisation est qu'une application à usage fréquent est garantie d'avoir de la place dans la mémoire volatile réelle VRAM pour y stocker ses données d'exécution de fonctionnement. [0074] Selon un mode de réalisation, ce sont les systèmes d'exploitation de bas niveau 113 décrits en relation avec la figure 1 qui gèrent le remplissage des mémoires avec les données d'exécution des applications résidente, ou non. Plus particulièrement, les systèmes d'exploitation de bas niveau sont adaptés à détecter si une application est une application résidente ou non. Un un élément sécurisé E peut comprendre plusieurs ap- plications résidentes. Les systèmes d'exploitation de bas niveau 113 sont, en outre, adaptés à refuser l'installation d'une application en tant qu'application résidente, par exemple, si l'élément sécurisé E comprend trop d'applications résidentes, en particulier lorsqu'une trop grande partie, par exemple plus de la moitié, de la mémoire volatile PRAM est réservée à des données d'exécutions d'applications résidentes. Selon une variante, les systèmes d'exploitation de bas niveau 113 sont adaptés à configurcr les tailles des parties de la mémoire volatile PRAM réservées à des données d'exécution d'applications résidentes. En particulier, les systèmes d'exploitation de bas niveau 113 sont adaptés à configurer la taille d'une partie de la mémoire volatile PRAM réservée à des données d'exécution d'une application résidente, pour la rendre égale à zéro. [0075] Divers modes de réalisation et variantes ont été décrits. L'homme de l'art comprendra que certaines caractéristiques de ces divers modes de réalisation et variantes pourraient être combinées, et d'autres variantes apparaitront à l'homme de l'art. [0076] En particulier, l'utilisation de la mémoire volatile virtuelle a été décrite avec l'exécution de deux applications, mais en pratique cette utilisation peut être transposée avec l'utilisation de plus de deux applications. [0077] De plus, une application pourrait être divisée en une sous-application qui est résidente, et une autre sous-application classique. Autrement dit l'application résidente pourrait être une partie d'une autre application. [0078] Enfin, la mise en oeuvre pratique des modes de réalisation et variantes décrits est à la portée de l'homme du métier à partir des indications fonctionnelles données ci-dessus. 11 REVENDICATIONS[Revendication I] Elément sécurisé embarqué (E) comprenant une mémoire volatile (PRAM), et étant configuré pour mettre en oeuvre au moins une partie d'une première application (App30, App50) adaptée à être mise en oeuvre par au moins un système d'exploitation de bas niveau (113) de l'élément sécurisé embarqué (E), dans lequel des données d'exécution de ladite première application (App30, App50) sont stockées dans une partie de ladite mémoire volatile (PRAM) configurée pour stocker uniquement des données d'exécution de ladite première application (App30, App50). [Revendication 2] Procédé d'exécution d'au moins une première application (App30, App50) adaptée à être mise en oeuvre par au moins un système d'exploitation de bas niveau (113) dans un élément sécurisé embarqué (E) comprenant une mémoire volatile (PRAM), dans lequel des données d'exécution de ladite première application (App30, App50) sont stockées dans une partie de ladite mémoire volatile (PRAM) configurée pour recevoir uniquement des données d'exécution de ladite première application. [Revendication 3] Elément selon la revendication 1, ou procédé selon la revendication 2, dans lequel ledit au moins un système d'exploitation de bas niveau (113) est un système d'exploitation adapté à échanger des commandes directement avec des composants (111) de l'élément sécurisé embarqué (E). [Revendication 4] Elément selon la revendication 1 ou 3, ou procédé selon la revendication 2 ou 3, dans lequel les données d'exécution d'une application sont des données temporaires utilisées par une application uniquement pendant son exécution. [Revendication 5] Elément selon l'une quelconque des revendications 1, 3 ou 4, ou procédé selon l'une quelconque des revendications 2 à 4, dans lequel la partie de ladite première application (App30, App50) est la totalité de ladite première application (App30, App50). [Revendication 6] Elément selon l'une quelconque des revendications 1, 3 à 5, ou procédé selon l'une quelconque des revendications 2 à 5, dans lequel l'élément sécurisé embarqué (E) est configuré pour mettre en oeuvre au moins une deuxième application (App31, App51) adaptée à être mise en oeuvre par au moins un système d'exploitation de bas niveau (113) de l'élément sécurisé embarqué (E). 12 [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] [Revendication 11] [Revendication 12] [Revendication 13] [Revendication 14] [Revendication 15] Elément ou procédé selon la revendication 6, dans lequel les données d'exécution de ladite deuxième application (App31) sont stockées dans : une partie de la mémoire volatile (PRAM) quand ladite deuxième application (App31, App51) est active ; et dans une partie d'une mémoire non volatile (VRAM) quand ladite deuxième application (App31) est non active. Elément ou procédé selon la revendication 7, dans lequel les données d'exécution de ladite deuxième application (App31) sont supprimées de la mémoire volatile (PRAM) quand ladite deuxième application (App31, App51) est non active. Elément ou procédé selon la revendication 6, dans lequel toutes les données d'exécution de ladite deuxième application (App51) sont stockées dans une mémoire non volatile (VRAM). Elément ou procédé selon la revendication 9, dans lequel les données d'exécution nécessaires à l'exécution de ladite deuxième application (App51) sont déplacées de la mémoire non volatile (VRAM) vers la mémoire volatile (PRAM) quand ladite deuxième application (App31, App51) est active. Elément ou procédé selon l'une quelconque des revendications 6 à 10, dans lequel des données d'exécution de ladite première ou de ladite deuxième application (App51) sont déplacées vers une partie d'une mémoire non volatile (VRAM) quand la mémoire volatile (PRAM) est pleine. Elément ou procédé selon l'une quelconque des revendications 6 à 11, dans lequel les données d'exécution de ladite deuxième application (App51) sont supprimées de la mémoire volatile (PRAM) quand ladite mémoire est pleine. Elément ou procédé selon l'une quelconque des revendications 7 à 12, dans lequel la mémoire non volatile est interne à l'élément sécurisé (E). Elément ou procédé selon l'une quelconque des revendications 7 à 12, dans lequel la mémoire non volatile est externe à l'élément sécurisé (E). Application adaptée à être mise en oeuvre par au moins un système d'exploitation de bas niveau (113) dans un élément sécurisé embarqué selon l'une quelconque des revendications 1, 3 à 14.