FR3114670A1

FR3114670A1 - Elément sécurisé embarqué

Info

Publication number: FR3114670A1
Application number: FR2009751A
Authority: FR
Inventors: Olivier Van Nieuwenhuyze; Amedeo Veneroso
Original assignee: Proton World International NV; STMicroelectronics SRL
Current assignee: Proton World International NV; STMicroelectronics SRL
Priority date: 2020-09-25
Filing date: 2020-09-25
Publication date: 2022-04-01

Abstract

Elément sécurisé embarqué La présente description concerne un système électronique embarqué ou un procédé mise en oeuvre par un tel système comportant : au moins une mémoire volatile (RAM) ; au moins un système d'exploitation de bas niveau gérant l'allocation de zones de la mémoire volatile à plusieurs systèmes d’exploitation de haut niveau comportant chacun une ou plusieurs applications (App20, App21), dans lequel des données d’exécution d'une ou plusieurs tâches de ladite première application (App20) sont transférées, en tout ou en partie, par le système d'exploitation de bas niveau, de ladite mémoire volatile vers une mémoire non volatile (WM) lorsque l'exécution de ladite tâche de la première application est interrompue par l'exécution d'au moins une tâche d'une deuxième application (App21). Figure pour l'abrégé : Fig. 3

Description

Elément sécurisé embarqué

La présente description concerne de façon générale les systèmes électroniques et, plus particulièrement, les systèmes électroniques embarqués. La présente description concerne, encore plus particulièrement, l'utilisation de mémoires dans un système électronique embarqué.

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.

Les difficultés de conception d'un système embarqué sont fréquemment liées à des contraintes de gestion de mémoires internes ou externes au système embarqué. Le système peut comprendre des mémoires non volatiles réinscriptibles ou non et des mémoires volatiles, chacune adaptée à stocker des données de différents types avec les contraintes et atouts propres à chaque type de mémoire. La gestion de ces mémoires engendre des contraintes en termes de sécurité des données en particulier lorsque que le système est utilisé pour des applications différentes.

Il serait souhaitable de pouvoir améliorer, au moins en partie, certains aspects des systèmes électroniques embarqués connus, plus particulièrement de pouvoir améliorer, au moins en partie, certains aspects de l'utilisation des mémoires dans les systèmes électroniques embarqués.

Il existe un besoin pour des systèmes embarqués adaptés à gérer plusieurs applications de façon indépendante les unes des autres.

Il existe, plus particulièrement, un besoin pour des systèmes embarqués dans lesquels l'utilisation des mémoires est optimisée.

Un mode de réalisation d'un premier aspect prévoit un système électronique embarqué comportant :
- au moins une mémoire volatile ; et
- au moins un système d'exploitation de bas niveau gérant l'allocation de zones de la mémoire volatile à plusieurs systèmes d’exploitation de haut niveau comportant chacun une ou plusieurs applications,
dans lequel ladite mémoire volatile comporte :
au moins une première partie réservée à des données d'exécution d'une première application ; et
au moins une deuxième partie destinée à stocker des données d'exécution d'au moins une deuxième application,
les données d'exécution de la première application restant dans la mémoire volatile en cas de désactivation ou de mise en veille de cette première application.

Un mode de réalisation du premier aspect prévoit un procédé mis en œuvre par un système électronique embarqué comportant :
- au moins une mémoire volatile ; et
- au moins un système d'exploitation de bas niveau gérant l'allocation de zones de la mémoire volatile à plusieurs systèmes d’exploitation de haut niveau comportant chacun une ou plusieurs applications,
dans lequel ladite mémoire volatile comporte :
au moins une première partie réservée à des données d'exécution d'une première application ; et
au moins une deuxième partie destinée à stocker des données d'exécution d'au moins une deuxième application,
les données d'exécution de la première application restant dans la mémoire volatile en cas de désactivation ou de mise en veille de cette première application.

Selon un mode de réalisation du premier aspect, des données d’exécution d'une ou plusieurs tâches d'une application sont transférées, en tout ou en partie, par le système d'exploitation de bas niveau, de ladite mémoire volatile vers une mémoire non volatile lorsque que l'exécution de ladite tâche est interrompue par l'exécution d'au moins une tâche d'une autre application.

Selon un mode de réalisation du premier aspect, une zone de mémoire volatile est allouée à la deuxième application alors qu'elle n'est pas exécutée, les données d'exécution de cette deuxième application étant transférées en mémoire non volatile si la taille de mémoire volatile disponible n'est pas suffisante à l'exécution d'une troisième application.

Un mode de réalisation d'un deuxième aspect prévoit un système électronique embarque comportant :
- au moins une mémoire volatile ;
- au moins un système d'exploitation de bas niveau gérant l'allocation de zones de la mémoire volatile à plusieurs systèmes d’exploitation de haut niveau comportant chacun une ou plusieurs applications,
dans lequel des données d’exécution d'une ou plusieurs tâches de ladite première application sont transférées, en tout ou en partie, par le système d'exploitation de bas niveau, de ladite mémoire volatile vers une mémoire non volatile lorsque que l'exécution de ladite tâche de la première application est interrompue par l'exécution d'au moins une tâche d'une deuxième application.

Un mode de réalisation du deuxième aspect prévoit un procédé mis en oeuvre dans un système électronique embarqué comportant :
- au moins une mémoire volatile ;
- au moins un système d'exploitation de bas niveau gérant l'allocation de zones de la mémoire volatile à plusieurs systèmes d’exploitation de haut niveau comportant chacun une ou plusieurs applications,
dans lequel des données d’exécution d'une ou plusieurs tâches de ladite première application sont transférées, en tout ou en partie, par le système d'exploitation de bas niveau, de ladite mémoire volatile vers une zone d'une mémoire non volatile lorsque que l'exécution de ladite tâche de la première application est interrompue par l'exécution d'au moins une tâche d'une deuxième application.

Selon un mode réalisation du deuxième aspect, dans lequel une zone de mémoire volatile est allouée à la première application alors qu'elle n'est pas exécutée, les données de cette première application étant transférées en mémoire non volatile si la taille de mémoire volatile disponible n'est pas suffisante à l'exécution d'une deuxième application

Selon un mode de réalisation de l'un ou l'autre des aspects, les applications d'un système d'exploitation de haut niveau n'ont pas accès aux zones de la mémoire volatile allouées aux applications d'un autre système d'exploitation de haut niveau.

Selon un mode de réalisation de l'un ou l'autre des aspects, une fonction ou unité de gestion de mémoires exécutée par le système d'exploitation de bas niveau empêche l'accès des données d'exécution d'une application à d'autres applications.

Selon un mode de réalisation du premier aspect, la fonction ou unité de gestion de mémoires adapte la taille des première et deuxième parties de la mémoire volatile en fonction des besoins des différentes applications.

Selon un mode de réalisation de l'un ou l'autre des aspects, les données d'exécution de plusieurs applications sont simultanément présentes en mémoire volatile.

Selon un mode de réalisation de l'un ou l'autre des aspects, la mémoire non volatile est externe au système électronique embarqué.

Selon un mode de réalisation de l'un ou l'autre des aspects, un code d'exécution d'une application est transféré en mémoire volatile pour son exécution.

Selon un mode de réalisation de l'un ou l'autre des aspects, la mémoire non volatile est interne au système électronique embarqué.

Selon un mode de réalisation de l'un ou l'autre des aspects, un code d'exécution d'une application reste en mémoire non volatile lors de l'exécution d'une tâche.

Selon un mode de réalisation de l'un ou l'autre des aspects, une zone de mémoire non volatile allouée à un système d'exploitation de haut niveau est vue par celui-ci comme une mémoire de travail volatile.

Selon un mode de réalisation de l'un ou l'autre des aspects, les systèmes d'exploitation de haut niveau gèrent une image virtuelle des mémoires dans laquelle les mémoires volatile et non volatile ne font qu'une.

Selon un mode de réalisation de l'un ou l'autre des aspects, lors de son exécution, une tâche principale d'une application se voit allouer une zone de mémoire volatile.

Un mode de réalisation prévoit un élément sécurisé embarqué, configuré pour la mise en oeuvre du système ou du procédé décrit.

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 :

la représente, de façon schématique et sous forme de blocs, un mode de réalisation de constituants matériels d'un élément sécurisé embarqué ou système électronique embarqué ;

la représente, de façon schématique et sous forme de blocs, une architecture logicielle d'un système électronique embarqué ;

la 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é des figures 1 et 2 ;

la 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é des figures 1 et 2 ;

la 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é des figures 1 et 2 ; et

la représente des vues (a), (b) 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é des figures 1 et 2.

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.

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.

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.

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 figures.

Sauf précision contraire, les expressions "environ", "approximativement", "sensiblement", et "de l'ordre de" signifient à 10 % près, de préférence à 5 % près.

La représente, de façon très schématique et sous forme de blocs, un mode de réalisation de constituants matériels HW (Hardware) d'un élément sécurisé embarqué E ou système électronique embarqué.

L'élément E est réalisé sous la forme d'un circuit électronique comportant, de façon matérielle, :
- une ou plusieurs unité 11 de traitement numérique (PU), par exemple de type machine d'états, microprocesseur ou unité centrale de traitement (CPU), circuit logique programmable, etc. ;
- une ou plusieurs mémoire 12, 13 de stockage volatil (RAM) et/ou non volatil (NVM) de données et programmes ;
- un ou plusieurs bus 14 de données, d'adresses et/ou de commandes entre les différents éléments internes au circuit 1 ;
- une ou plusieurs interfaces 15 d'entrée-sortie (I/O) de communication avec ou sans fil avec l'extérieur du circuit
1 ;
- un ou plusieurs circuits de communication, par exemple un circuit de communication en champ proche 16 (NFC – Near Field Communication) ; et
- divers autres circuits en fonction de l'application, symbolisés en par un bloc 17 (FCT), par exemple un dispositif de communication à courte distance utilisant, par exemple, la norme Bluetooth, des capteurs biométriques, etc. .

La 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é.

L'architecture logicielle 100 est mise en oeuvre par les composants matériels HW de l'élément sécurisé E décrits en .

L'architecture 100 comprend une plateforme primaire 110, généralement désignée plateforme primaire virtuelle (Virtual Primary Platform VPP) comprenant l'accès aux composants électroniques 111 (HW) de l'élément sécurisé E, et comprenant un ou plusieurs systèmes d'exploitation de bas niveau 113 (LLOS, Low Level Operating System).

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 ) 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 pilotes des composants 111.

Un système d'exploitation 113 de bas niveau est composé d’un code d’exécution (ou code exécutable) et de données d’exécution. Le code d’exécution contient des instructions permettant l’exécution des fonctions du programme. Par définition, les instructions sont invariables pour un programme donné, à l'exception d'une mise à jour du programme qui modifie alors les instructions. Les données d’exécution sont utilisées par le code d’exécution pour contextualiser l’exécution et réaliser la fonction souhaitée. Les données d’exécution peuvent être réparties en deux catégories. Les données d’exécution dites "temporaires" et les données d’exécution dites "permanentes" ou "fixes". Par exemple, si la fonction consiste en la vérification d’un code PIN, cette fonction est décomposée en trois parties, le code d’exécution contient des instructions de vérification du code PIN tandis que les données d’exécution permanentes contiennent le code PIN de référence et le nombre d’essais restants et que les données d’exécution temporaires contiennent le code PIN soumis à vérification.

Dans un élément sécurisé embarqué, le système de bas niveau gère les composants mémoire de l'élément, c'est-à-dire les mémoires physiques, volatiles 12 ( ) et non volatiles 13 (réinscriptibles ou non).

Les systèmes d’exploitation de haut niveau 124A et 124B utilisent des images virtuelles des mémoires disponibles pour la gestion des codes d’exécution et des données d’exécutions. Grâce à cette technique, les systèmes d’exploitation de haut niveau n’ont pas accès directement à la gestion des mémoires physiques qu'elles soient volatiles ou non-volatiles. En d'autres termes, dans les modes de réalisation décrits, les systèmes d'exploitation de haut niveau gèrent une image virtuelle des mémoires dans laquelle les mémoires volatile(s) et non volatile(s) ne font qu'une. La gestion de la répartition physique dans les mémoires volatiles(s) et non volatile(s) est assurée par le ou les systèmes d'exploitation de bas niveau.

La plateforme 110 a, selon les modes de réalisation décrits, notamment pour rôles ;
- de définir un système d'exploitation de bas niveau entre les composants matériels (HW), notamment le processeur et les mémoires, et les systèmes d'exploitation de haut niveaux et des applications qu'ils exécutent ;
- de gérer les échanges entre les systèmes d'exploitation de haut niveau et les composant matériels ;
- de mettre en oeuvre une fonction (pare-feu ou firewall) empêchant les interaction entre les systèmes d'exploitation de haut niveau ; et
- de permettre un partage des mêmes composants matériels de l'élément sécurisé entre plusieurs systèmes d'exploitation de haut niveau tout en faisant en sorte qu'un seul soit actif à instant donné.

Le système d'exploitation de bas niveau 113 exploite une fonction 115 de gestion des mémoires (Memory Management Function – MMF) pour contrôler ou gérer l'accès des systèmes d'exploitation de haut niveau aux mémoires physiques en réalisant le lien entre les mémoires virtuelles et les mémoires physique en fonction des besoins et demandes des systèmes d'exploitation de haut niveau 124A et 124B. Plus particulièrement, les systèmes d'exploitation de bas niveau 113, en utilisant la fonction de gestion des mémoires 115 (MMF), mettent en oeuvre l’isolation des systèmes d’exploitation de haut niveau 124A et 124B les uns par rapport aux autres et gèrent l'accès des systèmes d'exploitation de haut niveau 124A, 124B aux différentes mémoires. Par exemple, les systèmes d'exploitation de bas niveau 113 peuvent 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 à certaines données à un système d'exploitation de haut niveau.

L'architecture 100 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 formant l'application, par exemple des instructions, des lignes de code, ou des données permanentes telles que des données utilisateurs comme un identifiant, et de données temporaires, données d'exécution, ou variables comme des piles de données, des clés de chiffrement temporaires. Les données d'exécution d'une application sont des données utilisées par l'application uniquement pendant son exécution et non conservées une fois que l'exécution de l'application est terminée

Plus particulièrement, une application met en oeuvre une ou plusieurs tâches, chaque tâche étant, par exemple, une succession d'instructions. C'est la mise en oeuvre d'une tâche qui produit des données d'exécution. Certaines données d'exécution peuvent être utilisées par différentes tâches de l'application, alors que d'autres peuvent n'être utilisées que par une seule tâche. On considère qu'une application ne peut être mettre en oeuvre qu'une seule tâche à la fois.

Ainsi, dans la suite de la description, on appelle "tâche principale" la tâche qui est en cours d'exécution par l'application et "tâches secondaires" les autres tâches de l'application qui ne sont pas en cours d'exécution. Les tâches d'exécution sont par exemple des tâches qui n'ont pas encore été mises en oeuvre, et qui n'ont pas permis de générer des données d'exécution, ou des tâches qui ont déjà été mises en oeuvre mais qui ont été, par exemple, interrompues (et mises en pause), et qui ont donc déjà permis de générer des données d'exécution. Ainsi on distingue, dans la suite de la description, des données d'exécution relatives à la tâche principale, et des données d'exécution relatives aux tâches secondaires.

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.

Selon un exemple de type d'application, une application 121 (App1) est adaptée à être mise en oeuvre directement par la 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).

Selon un autre exemple de type d'application, une application 122 (App2) est adaptée à envoyer des commandes à la plateforme primaire 110 par l'intermédiaire d'un des systèmes d'exploitation de haut niveau, par exemple le système d'exploitation 124B. Ce 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 de haut niveau, ainsi que toutes les applications qui lui sont attachées, sont une application adaptée à être mise en oeuvre par la plateforme primaire 110.

Selon un autre exemple de type d'application, une application 123 (App3) est 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, par exemple 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.

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 et le code d’exécution d’une ou plusieurs applications. La mémoire volatile sert généralement à stocker les données d’exécution d'une ou plusieurs applications. Dans le cas où les données fixes et les données d'exécution de plusieurs applications sont stockées en même temps dans la mémoire volatile et dans la mémoire non volatile, il existe une protection, par exemple un logiciel de protection et/ou un mécanisme pare-feu, permettant d'empêcher une application d'accéder aux données fixes et aux données d'exécution d'une autre application. Cette fonction est, comme indiqué précédemment, mise en oeuvre par une fonction 115 de gestion de mémoires MMF (Memory Management Function) ou unité de gestion de mémoires (Memory Management Unit – MMU). Cette fonction 115 permet de faire le lien entre la mémoire "virtuelle" connue par l’application et les mémoires physiques (volatiles et non-volatiles). Les systèmes d’exploitation de haut niveau (124A et 124B) n’ont pas accès "directement" à la gestion de la mémoire physique. Ils utilisent une image virtuelle de cette mémoire. Cependant, la gestion de cette image virtuelle ou mémoire virtuelle est découpée afin de permettre aux systèmes d’exploitation de haut niveau (124A et 124B) de gérer les codes d’exécution, ainsi que les données fixes ou les données d’exécutions en fonction de leur nature. Ce sont bien les systèmes d’exploitation de haut niveau qui font la gestion de leurs données et non les systèmes d’exploitation de bas niveau. Les systèmes d'exploitation de bas niveau et la fonction de gestion de mémoires font la correspondance entre les données d'exécution virtuelles (la mémoire virtuelle) et leur stockage en mémoire physique.

Selon un mode de réalisation, au moins une zone ou partie de la mémoire non volatile est utilisée comme une mémoire de travail (working memory). Autrement dit, cette zone de la mémoire non volatile fonctionne, vu des applications de haut niveau, comme une mémoire volatile, pour stocker des données temporaires utilisées par les applications pendant leur fonctionnement. La mémoire non volatile peut être interne ou externe à l'élément sécurisé E (interne ou externe au circuit HW). Selon que la mémoire non volatile (sa zone utilisée en mémoire de travail par les systèmes d'exploitation de haut niveau) est interne ou externe à l'élément sécurisé, la gestion de cette mémoire diffère lors de l’exécution d’un système d'exploitation de haut niveau.

Dans le cas où la mémoire non volatile est interne à l’élément sécurisé E, le système d’exploitation de haut-niveau peut être directement exécuté à partir de la mémoire où le système d'exploitation se trouve (est chargé). On parle d’exécution "in place" (XIP) ou "en place". En général, les systèmes d'exploitation de bas niveau permettent alors la gestion de l'exécution de plusieurs systèmes d'exploitation de haut niveau. Dans le cas où une application est exécutée "en place", la partie instructions (le code d'exécution) de l'application reste en mémoire non volatile. Les données d'exécution (permanentes et temporaires) sont le cas échéant déplacées en mémoire de travail (mémoire non volatile).

A l’inverse, si la mémoire non volatile est externe à l’élément sécurisé E, l’exécution "in place" n’est pas possible. La gestion de la mémoire non volatile implique un déplacement en tout ou en partie du système d’exploitation de haut niveau dans une mémoire volatile interne de l’élément sécurisé. Dans ce cas, le système d’exploitation de bas niveau peut autoriser ou non la gestion de l’exécution de plusieurs systèmes d’exploitation de haut-niveau dans sa mémoire interne.

Par ailleurs, on considère qu'une application peut être dans au moins trois états différents :
- un état actif ou en cours d'exécution (running) par la plateforme primaire 110 ;
- un état de veille, c'est-à-dire que son exécution est interrompue mais qu'elle peut reprendre à tout moment ; et
- un état inactif ou désactivée, c'est-à-dire que son exécution ne peut être redémarrée sans une ou plusieurs opérations préalables.

Lorsqu’une application sort de veille pour être exécutée à nouveau, elle reprend son exécution là où elle s’est arrêtée. Elle n’est pas besoin d’utiliser de routine particulière pour continuer son traitement (processing). Du point de vue de l’application, tout apparaît comme si l'application n’a pas été interrompue.

Plus particulièrement, lorsqu'une application est en cours d'exécution, tout ou partie des données relatives à sa tâche principale sont stockées dans la mémoire volatile du circuit et sont utilisées pour la mise en oeuvre de l'application. Les données relatives à des tâches secondaires de l'application peuvent être stockées dans la mémoire volatile ou dans la mémoire de travail (non volatile). En variante, certaines données d'exécution (permanentes ou temporaires) relatives à la tâche principale peuvent se trouver dans la mémoire de travail (non volatile) et être chargées dans la mémoire volatile lorsque que la tâche principale en a besoin.

Lorsqu'une application est en veille, les données relatives à sa tâche principale sont stockées dans la mémoire volatile et ne sont pas en cours d'utilisation pour la mise en oeuvre de l'application. Les données relatives à des tâches secondaires de l'application peuvent être stockées dans la mémoire volatile ou dans la mémoire de travail. Une application peut, en outre, être en veille si son exécution est interrompue par l'exécution d'une autre application qui peut se trouver dans un système d'exploitation de haut niveau différent. Dans ce cas, toutes les tâches de l'application en veille sont considérées comme étant des tâches secondaires puisqu'aucune n'est exécutée. Ainsi, lorsque qu'une application est en veille parce qu'une autre application est en cours d'exécution, l'ensemble de ses données se retrouve physiquement, soit dans une zone dédiée de la mémoire volatile non accessible aux autres systèmes d'exploitation, soit dans la mémoire non volatile. Cette gestion est réalisée par la fonction de gestion de mémoire 115. Toutefois, vu de l'application (du système d'exploitation de haut niveau), les données temporaires sont dans une mémoire de travail assimilée, par l'image virtuelle qu'utilise ce système d'exploitation, à une mémoire volatile. Selon un autre exemple de réalisation, des données d'exécution de plusieurs applications différentes de plusieurs systèmes d'exploitation de haut niveau différents se trouvent en même temps dans la mémoire volatile. Dans ce cas, chaque application n'a accès qu'à ses propres données et n'a pas accès aux données de l'autre ou dans autres application. Par l'emploi du système de bas niveau et de la fonction de gestion de mémoires, les applications n'ont pas connaissance de la présence de données d'autres applications dans la mémoire volatile.

Lorsqu'une application est désactivée, toutes ses données (qu'elles soient relatives à une tâche principale ou à une tâche principale) sont stockées en mémoire de la même façon que pour une application en veille.

Les figures 3 à 6 illustrent différentes mises en oeuvre d'applications de l'élément sécurisé E, et plus particulièrement l'utilisation des mémoires physiques volatile et non volatile (de travail).

On aurait pu penser laisser les systèmes d'exploitation de haut niveau gérer directement les mémoires volatiles 12 et non volatile 13. Toutefois, certaines transactions opérées par certaines applications (par exemple des transactions en champs proche – NFC) requièrent une rapidité d'exécution incompatible avec une gestion d'une mémoire non volatile par un système d'exploitation de haut niveau. Le fait de transférer cette gestion au système d'exploitation de bas niveau et de "faire croire" au système d'exploitation de haut niveau qu'il transfère ses données en mémoire volatile accélère le processus.

La 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 les figures 1 et 2. Ces trois vues illustrent plus particulièrement l'utilisation de la mémoire de travail WM utilisant la mémoire non volatile (Physical NVM), considérée par les applications comme une mémoire volatile, et de la mémoire volatile RAM réelle (Physical RAM), de l'élément sécurisé E pendant l'exécution des applications App20 et App21.

Les applications App20 et App21, en fonction de leur implémentation, peuvent se trouver dans un même système d’exploitation de haut niveau ou dans deux systèmes d’exploitation de haut niveau différents.

Selon l'exemple décrit en , on suppose que l'application App21 est désactivée, mais a déjà été démarrée, avant le démarrage de l'application App20. Les données d’exécution relatives à la tâche principale et secondaires de l'application App21 sont stockées dans une zone W21 de la mémoire non volatile de travail WM.

L'application App20 est aussi désactivée mais n'a jamais été démarrée. Elle n'a donc pas encore généré de données d'exécution.

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 le système d'exploitation de bas niveau 113. L'application App20 est alors en cours d'exécution. Des données d’exécution, relatives à la tâche principale de l'application App20 sont téléchargées ou chargées dans la mémoire volatile RAM.

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 RAM.

A une deuxième phase (vue (b)), on suppose que l'application App21, jusqu'ici désactivée, demande à être exécutée par l'élément sécurisé E.

Les données d’exécution relatives à la tâche principale, et, éventuellement, à des tâches secondaires, de l'application App20, présentes dans la mémoire volatile RAM sont transférées et stockées dans une zone WM20 de la mémoire non volatile de travail WM et sont supprimées de la mémoire volatile RAM. Ainsi, l'état actuel de l'application App20 est sauvegardé dans la mémoire WM, vue par l'application App20 comme une mémoire volatile, et l'application App20 devient alors désactivée.

Des données d’exécution relatives à l'application App21 stockées précédemment dans la zone WM21 sont chargées dans la mémoire volatile RAM. Ainsi, l'utilisation de l'application App21 peut reprendre là où elle s'était arrêtée précédemment. Autrement dit, l'application App21 passe d'un état désactivé à un état "en cours d'exécution".

A une troisième phase (vue (c)), l'application App21 continue de s'exécuter, et modifie dans la mémoire volatile RAM ses données d’exécution relatives à sa tâche principale et, éventuellement, à des tâches secondaires. Des données sont pour cela transférées de la mémoire non volatile de travail WM vers la mémoire volatile PRAM.

La 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 les figures 1 et 2. Ces trois vues illustrent plus particulièrement l'utilisation de la mémoire non volatile de travail WM et d'une mémoire volatile RAM de l'élément sécurisé E pendant l'activation des applications App30 et App31.

Les applications App30 et App31, en fonction de leur implémentation, peuvent se trouver dans un même système d’exploitation de haut niveau ou dans deux systèmes d’exploitation de haut niveau différents.

Selon un mode de réalisation, l'application App30 est une application à usage fréquent, ou application résidente, ou met en oeuvre une tâche à usage fréquent, une tâche résidente. Le fait de considérer une application comme étant "fréquente" est décidé, demandé et/ou indiqué par le système d’exploitation de haut niveau qui héberge l’application. Les données d’exécution relatives à l'application résidente App30 sont stockées dans une zone PRAM30 réservée de la mémoire volatile RAM. La zone (ou plage d'adresses physiques) PRAM30 de la mémoire RAM 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.

On suppose que l'application App30 est active et en cours d'exécution.

A une première phase (vue (a)), l'application App30 est mise en veille. Des données d’exécution relatives à la tâche principale de l'application App30 sont stockées dans la zone PRAM30. La tâche principale de l'application App30 est, par exemple, une tâche résidente.

L'application App31 est, ensuite, démarrée par l'élément sécurisée E. Des données d’exécution, relatives à la tâche principale, et, éventuellement à des tâches secondaires, de l'application App31, sont téléchargées ou chargées dans une zone PRAM31 de la mémoire volatile RAM. La zone PRAM31 est distincte de la zone PRAM30. L'application App31 se trouve alors en cours d'exécution.

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 zone PRAM31 de la mémoire volatile RAM.

A une deuxième phase (vue (b)), l'application résidente App30, jusque-là en veille, demande à être exécutée par l'élément sécurisé E, plus particulièrement, par le système d'exploitation de bas niveaux 113.

Si la capacité de la mémoire volatile n'est pas suffisante pour contenir les données d'exécution des zone App30 et App31, les données d’exécution relatives à l'application App31, présentes dans la zone PRAM31 de la mémoire volatile RAM, sont alors transférées dans une zone WM31 de la mémoire non volatile de travail WM. Ainsi, l'état actuel de l'application App31 est sauvegardé dans la mémoire de travail WM et l'application App31 est alors désactivée. Cette situation peut également se produire si deux applications sont déjà présentes dans la mémoire volatile et qu'une troisième application demande à être exécutée.

A une troisième phase (vue (c)), des données d’exécution relatives à la tâche principale de l'application App30, déjà présentes dans la zone PRAM30 de la mémoire volatile RAM dédiée à l'application 30, peuvent être directement traitées. Ainsi, l'utilisation de l'application App30 peut reprendre là où elle s'était arrêtée précédemment. L'application App30 est alors en cours d'exécution.

Un avantage de ce mode de réalisation est qu'une application à usage fréquent, ou application résidente, est garantie d'avoir de la place dans la mémoire volatile physique PRAM pour y stocker ses données d’exécution. Dans le cas où, la taille de la mémoire volatile résidente demandée par une nouvelle application résidente qui devrait être activée serait supérieure à la taille de la mémoire volatile physique PRAM, son activation serait refusée jusqu’à ce que la mémoire PRAM soit libérée, ou que la taille disponible de la mémoire PRAM soit suffisante, ou que la taille de la mémoire dite résidente demandée par l'application à activer soit compatible avec la taille disponible de la mémoire PRAM. Ce cas peut se produire si plusieurs applications résidentes sont activées.

La 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 les figures 1 et 2. Ces trois vues illustrent plus particulièrement l'utilisation de la mémoire non volatile de travail WM et de la mémoire volatile RAM de l'élément sécurisé E pendant l'activation des applications App40 et App41.

Les applications App40 et App41, en fonction de leur implémentation, pourraient se trouver dans un même système d’exploitation de haut niveau ou dans deux systèmes d’exploitation de haut niveau différents.

On suppose que les applications App40 et App41 ont déjà été préalablement démarrées ou exécutées par l'élément sécurisé E, mais sont désormais en veille ou inactives. Toutes les données d’exécution relatives au démarrage et au fonctionnement des applications App40 et App41 sont alors stockées dans, respectivement, des zones WM40 et WM41 de la mémoire non volatile de travail WM.

A une première phase (vue (a)), l'application App40 demande à être exécutée par l'élément sécurisé E, et devient alors "en cours d'exécution". Des données d’exécution de démarrage et de fonctionnement relatives à l'application App40 sont transférées, téléchargées ou chargées dans une zone PRAM40 de la mémoire volatile RAM, à partir de la zone WM40 de la mémoire non volatile de travail WM, lorsque la tâche principale de l'application App40 en a besoin.

A une deuxième phase (vue (b)), l'application App41 demande à son tour à être exécutée par l'élément sécurisé E. Les données d’exécution relatives à la tâche principale de l'application App41 sont transférées, téléchargées ou chargées dans une zone PRAM41 de la mémoire volatile RAM, à partir de la zone WM41 de la mémoire non volatile de travail WM. Ces données sont stockées à la suite des données d’exécution relatives à l'application App40 dans la mémoire volatile RAM. L'application App41 est alors en cours d'exécution, et l'application App40 est alors en veille.

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 RAM n'a plus d'espace disponible pour stocker des données d’exécution supplémentaires relatives à cette application App41. Des données d’exécution relatives à des tâches secondaires de l'application App40, présentes dans la zone PRAM40, sont alors transférées ou déplacées vers la zone WM40 de la mémoire non volatile WM pour libérer de l'espace de stockage dans la mémoire volatile RAM.

Il peut également se produire que des données de l'application App41 soient transférées dans la mémoire de travail, par exemple si toutes les données d'exécution de l'application App40 ont déjà été transférées en mémoire de travail mais que la capacité de la mémoire volatile n'est pas suffisante pour toutes les données d'exécution de l'application App41. Dans ce cas, les données les moins utilisées ou les plus anciennes sont transférées en mémoire de travail.

La 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 . Ces trois vues illustrent plus particulièrement l'utilisation de la mémoire non volatile de travail WM et de la mémoire volatile RAM de l'élément sécurisé E pendant l'activation des applications App50 et App51.

. Les applications App50 et App51, en fonction de leur implémentation, pourraient se trouver dans un même système d’exploitation de haut niveau ou dans deux systèmes d’exploitation de haut niveau différents.

On suppose que les applications App50 et App51 ont déjà été démarrées par l'élément sécurisé E et sont désactivées. Toutes les données d’exécution relatives au démarrage et au fonctionnement des applications App50 et App51 sont respectivement stockées dans des zones WM50 et WM51 de la mémoire non volatile de travail WM.

Selon l'exemple décrit en , l'application App50 est une application à usage fréquent, appelée par la suite application résidente, aussi décrite en relation avec la .

A une première phase (vue (a)), l'application résidente App50 demande à être 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 transférées, téléchargées ou chargées dans une zone PRAM50 réservée de la mémoire volatile RAM, à partir de la zone WM50 de la mémoire non volatile de travail WM. La zone PRAM50 est une zone de la mémoire volatile RAM 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. L'application App50 est alors en cours d'exécution.

A une deuxième phase (vue (b)), l'application App51 demande à être 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 transférées, téléchargées ou chargées dans une zone PRAM51 de la mémoire volatile RAM, à partir de la zone WM51 de la mémoire non volatile de travail WM. Ces données sont stockées à la suite des données d’exécution relatives à l'application App50 dans la mémoire volatile RAM. L'application App51 est alors en cours d'exécution, et l'application App50 est alors en veille.

A une troisième phase (vue (c)), l'application App51 est toujours en cours d'exécution par l'élément sécurisé E, mais la mémoire volatile RAM n'a plus d'espace disponible pour stocker des données d’exécution supplémentaires relatives à l'application App51. Les données d’exécution relatives à l'application App51 ne pouvant être stockées dans la zone PRAM50, certaines données d’exécution relatives à des tâches secondaires de l'application App51 sont alors déplacées vers la zone WM51 de la mémoire non volatile de travail WM pour libérer de l'espace de stockage dans la mémoire volatile RAM.

Dans le cas où l'élément sécurisé E a besoin de mettre en oeuvre une troisième application, alors que la mémoire volatile RAM n'a plus d'espace disponible pour stocker des données d’exécution, le système de bas niveau (sa fonction de gestion de mémoire MMF) déplacera les données de l'application, qui n'est pas résidente, dont l'exécution est la plus ancienne.

En variante, une application résidente a une partie des données d'exécution en mémoire volatile dédiée (résidente) et une autre partie en mémoire volatile partagée avec d'autres applications. Cette partie partagée peut alors être transférée en mémoire de travail (non volatile) lorsque l'exécution de la tâche de l'application concernée est interrompue ou a besoin de plus de place en mémoire volatile.

Un avantage des modes de réalisation décrits est que toutes les applications sont chargées dans une mémoire vue, par les systèmes d'exploitation de haut niveau de ces applications, comme une mémoire volatile. Cela permet un démarrage rapide de chaque application.

Un autre avantage des modes de réalisation décrits est qu'une application à usage fréquent est garantie d'avoir de la place dans la mémoire volatile RAM du circuit pour y stocker ses données d’exécution de fonctionnement.

De préférence, les systèmes d'exploitation de bas niveau 113, décrits en relation avec la , gèrent l'affectation des zones mémoire et leur remplissage avec les données d'exécution des applications (résidentes ou non). Plus particulièrement, le ou les systèmes d'exploitation de bas niveau sont adaptés à détecter si une application est une application résidente ou non. Un élément sécurisé E peut comprendre plusieurs applications 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 RAM 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 à configurer les tailles des parties de la mémoire volatile RAM 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 RAM réservée à des données d'exécution d'une application résidente, pour la rendre égale à zéro.

De plus, si l'élément sécurisé comprend plusieurs applications résidentes, alors les données d'exécution de ces applications résidentes sont toutes stockées dans une même partie "résidente" de la mémoire volatile RAM. Lorsque cette partie "résidente" est pleine, les données d'exécution relatives à des tâches secondaires des applications résidentes sont déplacées vers la mémoire non volatile de travail WM.

De plus, si toutes les applications résidentes de l'élément sécurisé sont désactivées, la partie "résidente" de la mémoire volatile RAM, qui est réservée aux données d'exécution des applications résidentes, peut être utilisée pour stocker des données d'exécution d'autres applications de l'élément sécurisé. Par ailleurs, la taille de la partie "résidente" de la mémoire volatile RAM peut être ajustée en fonction des besoins des applications résidentes. En outre, si une application résidente, qui demande à être exécuté, n’a pas assez de place pour charger ses données dans la partie "résidente" de la mémoire volatile RAM, son exécution est suspendue et elle reste dans l’état désactivé. L'application concernée ne pourra être exécutée que lorsqu’il y aura assez de place dans la partie "résidente" de la mémoire volatile RAM. A titre d'exemple, de la place peut être libérée en désactivant d'autres applications résidentes. Selon un autre exemple, la taille de la partie "résidente" de la mémoire volatile PRAM peut être augmentée.

Selon un autre mode de réalisation, les données d'exécution d'une application inactive ou en veille qui sont stockées dans la mémoire de travail WM ne sont transférées en mémoire volatile, lors d'une nouvelle activation de cette application, qu'au fur et à mesure des besoins de l'application. Cette action est effectuée par le système d'exploitation de bas niveau et est transparente pour l'application et le système d'exploitation de haut niveau correspondant. En effet, les déplacements de données entre la mémoire volatile et la mémoire non volatile de travail et inversement ne sont pas vus par les systèmes d'exploitation de haut niveau. Dans le cas où toute la mémoire volatile a besoin d'être utilisée lors d'un chargement, le système d'exploitation de bas niveau déplace au préalable, vers la mémoire de travail, une donnée d'exécution qui est considérée comme la plus ancienne (celle qui a été utilisée le moins récemment) ou la moins utilisée.

Divers modes de réalisation, aspects et variantes ont été décrits. L’homme de l’art comprendra que certaines caractéristiques de ces divers modes de réalisation, aspects et variantes pourraient être combinées, et d’autres variantes apparaitront à l’homme de l’art.

En particulier, l'utilisation de la mémoire non volatile de travail a été surtout 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.

De plus, une application pourrait être divisée en une ou plusieurs sous-applications résidentes et une ou plusieurs sous-applications non résidentes. Autrement dit, l'application résidente pourrait être une partie d'une autre application.

Enfin, la mise en oeuvre pratique des modes de réalisation et variantes décrits est à la portée de la personne du métier à partir des indications fonctionnelles données ci-dessus.

Claims

Système électronique embarqué (E) comportant :
- au moins une mémoire volatile (12, RAM) ;
- au moins un système d'exploitation de bas niveau (113) gérant l'allocation de zones de la mémoire volatile à plusieurs systèmes d’exploitation de haut niveau comportant chacun une ou plusieurs applications (App20, App21 ; App40, App41),
dans lequel des données d’exécution d'une ou plusieurs tâches d'une première application (App20 ; App40) sont transférées, en tout ou en partie, par le système d'exploitation de bas niveau, de ladite mémoire volatile vers une mémoire non volatile (13, WM) lorsque que l'exécution de ladite tâche de la première application est interrompue par l'exécution d'au moins une tâche d'une deuxième application (App21 ; App41).
Procédé mis en oeuvre dans un système électronique embarqué (E) comportant :
- au moins une mémoire volatile (12, RAM) ;
- au moins un système d'exploitation de bas niveau (113) gérant l'allocation de zones de la mémoire volatile à plusieurs systèmes d’exploitation de haut niveau comportant chacun une ou plusieurs applications (App20, App21 ; App40, App41),
dans lequel des données d’exécution d'une ou plusieurs tâches d'une première application (App20 ; App40) sont transférées, en tout ou en partie, par le système d'exploitation de bas niveau, de ladite mémoire volatile vers une zone d'une mémoire non volatile (13, WM) lorsque que l'exécution de ladite tâche de la première application est interrompue par l'exécution d'au moins une tâche d'une deuxième application (App21 ; App41).
Procédé selon la revendication 2, dans lequel les applications d'un système d'exploitation de haut niveau n'ont pas accès aux zones de la mémoire volatile allouées aux applications d'un autre système d'exploitation de haut niveau.
Procédé selon la revendication 2 ou 3, dans lequel la mémoire non volatile est externe au système électronique embarqué.
Procédé selon la revendication 4, dans lequel un code d'exécution d'une application est transféré en mémoire volatile (12) pour son exécution.
Procédé selon la revendication 2 ou 3, dans lequel la mémoire non volatile est interne au système électronique embarqué.
Procédé selon la revendication 6, dans lequel un code d'exécution d'une application reste en mémoire non volatile (13) lors de l'exécution d'une tâche.
Procédé selon l'une quelconque des revendications 2 à 7, dans lequel une zone de mémoire non volatile allouée à un système d'exploitation de haut niveau est vue par celui-ci comme une mémoire de travail volatile.
Procédé selon l'une quelconque des revendications 2 à 8, dans lequel les systèmes d'exploitation de haut niveau gèrent une image virtuelle des mémoires dans laquelle les mémoires volatile et non volatile ne font qu'une.
Procédé selon l'une quelconque des revendications 2 à 9, dans lequel, lors de son exécution, une tâche principale d'une application se voit allouer une zone de mémoire volatile.
Procédé selon l'une quelconque des revendications 2 à 10, dans lequel une zone de mémoire volatile est allouée à la première application alors qu'elle n'est pas exécutée, les données de cette première application étant transférées en mémoire non volatile si la taille de mémoire volatile disponible n'est pas suffisante à l'exécution d'une deuxième application.
Procédé selon l'une quelconque des revendications 2 à 11, dans lequel des données d'exécution de plusieurs applications sont simultanément présentes en mémoire volatile (12).
Procédé selon l'une quelconque des revendications 2 à 12, dans lequel une fonction ou unité de gestion de mémoires (115) exécutée par le système d'exploitation de bas niveau empêche l'accès des données d'exécution d'une application à d'autres applications.
Système selon la revendication 1, configuré pour la mise en œuvre du procédé selon l'une quelconque des revendications 2 à 13.
Elément sécurisé embarqué, configuré pour la mise en oeuvre du procédé selon l'une quelconque des revendications 2 à 13.