Brevet FR3028071A1 — publié le 20160506

DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne le basculement entre deux environnements d'exécution dans un appareil électronique. Elle concerne plus particulièrement un appareil électronique et procédé mis en oeuvre dans un tel appareil électronique. L'invention s'applique particulièrement avantageusement dans le cas où des bibliothèques ou des données sont utilisées par différentes applications exécutées dans l'appareil électronique. ARRIERE-PLAN TECHNOLOGIQUE Comme expliqué par exemple dans l'article "The Untapped Potential of Trusted Execution Envi ronments on Mobile Devices" de J.-E. Ekberg, K. Kostiainen et N. Asokan in IEEE Security & Privacy, volume PP édition 99, 16 avril 2014, il est connu de sécuriser le fonctionnement des appareils électroniques par l'utilisation d'un système d'exploitation de confiance (ou "Trusted OS" selon la dénomination anglo-saxonne), qui permet de fournir un environnement d'exécution de confiance (ou TEE pour "Trusted Execution Environment") dans lequel certaines applications seulement peuvent être installées et exécutées. Un tel environnement de confiance est en général proposé à côté d'un environnement polyvalent (ou REE pour "Rich Execution Environment") dans lequel les contraintes de sécurité sont moindres et un plus grand nombre d'applications peuvent donc être installées. L'environnement polyvalent repose sur l'exécution au sein de l'appareil électronique d'un système d'exploitation polyvalent (ou "Rich OS" selon la dénomination anglo-saxonne), distinct du système d'exploitation de confiance. Afin de garantir une bonne isolation entre les deux environnements, on prévoit en général que le basculement du fonctionnement de l'appareil électronique d'un environnement à l'autre soit géré par un moniteur de sécurité (ou "secure monitor" selon la dénomination anglo-saxonne). OBJET DE L'INVENTION Dans ce contexte, la présente invention propose un appareil électronique comprenant un processeur et une mémoire vive, et conçu pour mettre en oeuvre un moniteur de sécurité apte à faire basculer le fonctionnement de l'appareil électronique entre un premier environnement d'exécution et un second environnement d'exécution, dans lequel l'appareil électronique est conçu pour faire exécuter par le processeur, dans le premier environnement d'exécution, une première application utilisant une ressource (première ressource) mémorisée dans une partie de la mémoire vive et, dans le second environnement d'exécution, une seconde application requérant une ressource (seconde ressource) mémorisée dans ladite partie de la mémoire vive, caractérisé en ce que le moniteur de sécurité est conçu pour déterminer si la ressource requise (seconde ressource) correspond à la ressource utilisée (première ressource) et pour charger la ressource requise (seconde ressource) dans ladite partie de la mémoire vive si la ressource requise (seconde ressource) ne correspond pas à la ressource utilisée (première ressource). Le moniteur de sécurité vérifie ainsi que la (seconde) ressource, requise par la seconde application exécutée dans le second environnement (c'est-à-dire après changement de contexte), ne correspond pas à la (première) ressource présente en mémoire vive. Le chargement de la ressource requise (seconde ressource), qui peut nécessiter un temps non-négligeable, par exemple en provenance d'une mémoire non-volatile réinscriptible, est ainsi effectué seulement lorsque cela est nécessaire. On remarque que, dans certaines applications, le chargement de la ressource requise (seconde ressource) peut dans certains cas être réalisé même lorsque la ressource requise (seconde ressource) correspond à la ressource utilisée (première ressource), par exemple s'il est en outre détecté que les données formant la ressource utilisée (première ressource) ont été corrompues, comme expliqué dans la description qui suit. Dans une telle application, on évite toutefois un chargement de la ressource requise (seconde ressource) lorsque la ressource requise (seconde ressource) correspond à la ressource utilisée (première ressource) et que les données formant la ressource utilisée (première ressource) n'ont pas été corrompues. D'autres caractéristiques avantageuses et non limitatives de l'appareil électronique conforme à l'invention sont les suivantes : - le moniteur de sécurité est conçu pour charger en mémoire vive une pile d'exécution du second environnement et pour déterminer si la ressource requise (seconde ressource) correspond à la ressource utilisée (première ressource) notamment (c'est-à-dire au moins) par lecture de la pile d'exécution chargée ; - le moniteur de sécurité est conçu pour lire au moins une information relative à la ressource utilisée (première ressource) dans une table et pour déterminer si la ressource requise (seconde ressource) correspond à la ressource utilisée (première ressource) sur la base notamment (c'est-à-dire au moins sur la base) de l'information lue ; - l'appareil électronique est conçu pour mettre en oeuvre des moyens de vérification de l'intégrité de la ressource utilisée (première ressource) lorsque le moniteur de sécurité détermine que la ressource utilisée (première ressource) correspond à la ressource requise (seconde ressource) ; - les moyens de vérification de l'intégrité comprennent notamment des moyens de détermination de données de vérification, mis en oeuvre par le moniteur de sécurité ou par le système d'exploitation de confiance ; - la ressource utilisée (première ressource) est une bibliothèque ; - la ressource requise (seconde ressource) est une bibliothèque ; - la ressource utilisée (première ressource) est un ensemble de données ; - la ressource requise (second ressource) est un ensemble de données. L'invention propose également un procédé mis en oeuvre dans un appareil électronique comprenant un processeur et une mémoire vive, caractérisé en ce qu'il comprend les étapes suivantes : - mise en oeuvre, dans un premier environnement d'exécution, d'une première application utilisant une (première) ressource mémorisée dans une partie de la mémoire vive ; - réception, par un moniteur de sécurité, d'une demande de basculement du premier environnement d'exécution à un second environnement d'exécution ; - détermination, par le moniteur de sécurité, si une (seconde) ressource requise par une seconde application exécutable dans le second environnement d'exécution correspond à la ressource utilisée (première ressource) ; - si le moniteur de sécurité détermine que la ressource requise (seconde ressource) ne correspond pas à la ressource utilisée (première ressource), chargement de la ressource requise (seconde ressource) dans ladite partie de la mémoire vive ; - basculement, par le moniteur de sécurité, du premier environnement d'exécution au second environnement d'exécution ; - exécution de la seconde application. D'autres caractéristiques avantageuses et non limitatives de l'appareil électronique conforme à l'invention sont les suivantes : - le procédé comprend une étape de chargement en mémoire vive, par le moniteur de sécurité, d'une pile d'exécution du second environnement ; - l'étape de détermination inclut une sous-étape de lecture de la pile d'exécution chargée ; - le procédé comprend une étape de lecture, par le moniteur de sécurité, d'au moins une information relative à la ressource utilisée (première ressource) dans une table ; - l'étape de détermination utilise l'information lue ; - le procédé comprend une étape de vérification de l'intégrité de la ressource utilisée (première ressource) lorsque le moniteur de sécurité détermine que la ressource utilisée (première ressource) correspond à la ressource requise (seconde ressource). DESCRIPTION DETAILLEE D'UN EXEMPLE DE REALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. Sur les dessins annexés : - la figure 1 représente schématiquement l'utilisation de deux environnements d'exécution au sein d'un appareil électronique dans lequel est mise en oeuvre l'invention ; - la figure 2 représente des entités fonctionnelles mémorisées au sein de l'appareil électronique 10 et utilisées dans le cadre de la présente invention ; - la figure 3 représente un procédé de basculement de l'environnement d'exécution de confiance à l'environnement d'exécution polyvalent conforme aux enseignements de l'invention ; et - la figure 4 représente un procédé de basculement de l'environnement d'exécution polyvalent à l'environnement d'exécution de confiance conforme aux enseignements de l'invention. La figure 1 représente schématiquement l'utilisation de deux environnements d'exécution au sein d'un appareil électronique 10 dans lequel est mise en oeuvre l'invention. Cet appareil électronique 10, ici un terminal (par exemple de type téléphone intelligent ou "smartphone" selon la dénomination anglo-saxonne), 5 comprend une architecture à base de microprocesseur. Deux systèmes d'exploitation distincts sont utilisés au sein de l'appareil électronique 10: un système d'exploitation polyvalent 20 (ou "Rich OS" selon l'appellation anglo-saxonne) et un système d'exploitation de confiance 30 (ou "Trusted OS"), parfois dénommé système d'exploitation sécurisé ("Secure OS"). 10 Le système d'exploitation polyvalent 20 permet le téléchargement, l'installation et l'exécution d'applications avec une grande liberté pour l'utilisateur. La mise en oeuvre du système d'exploitation polyvalent 20 crée ainsi un environnement polyvalent ou REE (pour "Rich Execution Environment"). Au contraire, dans le cadre du fonctionnement de l'appareil électronique 15 10 sur la base du système d'exploitation de confiance 30, les possibilités de téléchargement et d'installation d'applications sont limitées (par exemple à des applications ayant reçu une certification particulière) de sorte que l'utilisation du système d'exploitation de confiance permet de créer au sein de l'appareil électronique 10 un environnement d'exécution de confiance ou TEE (pour 20 "Trusted Execution Environment"). Cet environnement d'exécution de confiance offre par exemple un niveau de sécurité conforme aux critères communs EAL (pour "Evaluation Assurance Lever), correspondant à la norme ISO 15408, avec un niveau compris entre 2 et 7, ou à la norme FIPS (pour "Federal Information Processing Standard') 140-2. 25 Dans l'exemple décrit ici, le système d'exploitation polyvalent 20 et le système d'exploitation de confiance 30 sont exécutés par un même processeur de l'appareil électronique, par exemple un processeur d'un système sur puce (ou SoC pour "System on Chip"). Outre le processeur, un tel système sur puce comprend d'autres éléments électroniques ayant diverses fonctionnalités, 30 notamment une ou plusieurs mémoires (par exemple une mémoire morte - ou ROM pour "Read Only Memory", une mémoire vive - ou RAM pour "Random Access Memory" - et une mémoire non-volatile réinscriptible, par exemple de type EEPROM pour "Electrically Erasable and Programmable Read Only Memory"); une partie d'au moins une de ces mémoires peut être réservée au système d'exploitation de confiance 30 (c'est-à-dire que cette partie de mémoire peut être lue et/ou écrite seulement par le système d'exploitation de confiance 30 ou, ici, par le moniteur de sécurité 40, et non par le système d'exploitation polyvalent 20). On remarque qu'à l'inverse, le système d'exploitation de confiance 30 (comme d'ailleurs le moniteur de sécurité 40) peut accéder en lecture et/ou en écriture les zones de mémoire utilisées par le système d'exploitation polyvalent 20. On pourrait en variante utiliser un appareil électronique comportant deux processeurs, le système d'exploitation polyvalent 20 étant exécuté sur l'un et le système d'exploitation de confiance 30 étant exécuté sur l'autre. L'appareil électronique 10 met également en oeuvre un moniteur de sécurité 40 (ou "Secure Monitor" selon l'appellation anglo-saxonne), qui s'exécute dans le cas qui vient d'être mentionné sur le processeur de l'appareil électronique 10. Le moniteur de sécurité 40 commande (comme expliqué plus bas) le basculement entre le fonctionnement de l'appareil électronique 10 sur la base du système d'exploitation polyvalent 20 et le fonctionnement de l'appareil électronique 10 sur la base du système d'exploitation de confiance 30 (et vice versa), de sorte que l'appareil électronique 10 fonctionne à chaque instant sur la base d'un seul des deux systèmes d'exploitation 20, 30 (c'est-à-dire dans un seul des deux environnements mentionnés ci-dessus). Selon un mode de réalisation envisageable, le système d'exploitation exécuté avant basculement (par exemple le système d'exploitation polyvalent 20) est mis en veille par le basculement et tout accès à des éléments externes au processeur (par exemple l'interface homme machine comprenant notamment un clavier et/ou un écran et/ou un autre module d'entrée-sortie) est alors inhibé pour le système d'exploitation en veille, de sorte que le système d'exploitation activé par le basculement (ici le système d'exploitation de confiance 30) contrôle totalement l'élément externe, ici l'interface homme machine. La figure 2 représente des entités fonctionnelles mémorisées au sein de l'appareil électronique 10 et utilisées dans le cadre de la présente invention. Une pile d'exécution (en anglais "execution stack") 50 est mémorisée en mémoire vive et comprend une liste ordonnée des prochaines applications APPLI1, APPLI2 dont l'exécution est prévue. Pour chaque application APPLI1, APPLI2, la pile d'exécution indique par exemple un identifiant de l'application et une adresse de mémorisation de l'application (qui peut pointer par exemple vers une zone mémoire située en mémoire vive ou en mémoire non-volatile réinscriptible). On prévoit ici que soient également indiquées dans la pile d'exécution les bibliothèques (en anglais "fibraries") ou les données auxquelles l'application concernée fait appel pour son exécution. En variante, ces indications pourraient être contenues dans une table séparée qui liste, pour chaque application mémorisée dans l'appareil électronique 10, les bibliothèques et les données auxquelles cette application fait appel. Lors d'un changement d'environnement d'exécution, la pile d'exécution courante est sauvegardée en mémoire non-volatile réinscriptible afin que la pile d'exécution puisse être restaurée en l'état lors d'un éventuel retour ultérieur à l'environnement d'exécution actif avant changement. Une zone 60 de la mémoire non-volatile réinscriptible mémorise des bibliothèques identifiées chacune par leur type Ti et par leur identifiant lj. Le type Ti désigne ici la classe (par exemple : chiffrement) et la sous-classe (par exemple : RSA) de la bibliothèque concernée. L'identifiant lj est quant à lui indicatif d'un niveau de performance (compris ici entre 0 et 99), lié par exemple au temps d'exécution de la fonction concernée, et d'un niveau de sécurité (également compris entre 0 et 99 dans l'exemple décrit ici). L'appareil électronique 10 mémorise, par exemple en mémoire vive, une table 70 qui répertorie les bibliothèques LIB1, LIB2 mémorisées dans une zone dédiée 80 de la mémoire vive (après recopie à partir de la zone 60 de la mémoire non-volatile réinscriptible lorsqu'une application a utilisé cette bibliothèque). Pour chaque bibliothèque LIB1, LIB2 mémorisée dans la zone dédiée 80 de la mémoire vive, la table comprend l'adresse de mémorisation en mémoire vive de la bibliothèque concernée LIB1, LIB2. Ainsi, dans l'exemple représenté en figure 2, sont mémorisées dans la zone dédiée 80 de la mémoire vive une bibliothèque LIB1 de type Ti et d'identifiant 112 et une bibliothèque LIB2 de type T2 et d'identifiant 121. On peut prévoir de même que la mémoire non-volatile réinscriptible mémorise des données utilisées par les applications exécutées au sein de l'appareil électronique 10. Ces données sont organisées en ensembles de données, chaque ensemble pouvant être identifié comme indiqué ci-dessus à propos des bibliothèques. Un ensemble de données comprend par exemple des données d'identification de l'utilisateur, des données de connexion à un serveur distant, etc. Comme indiqué pour les bibliothèques, la table 70 (ou, en variante, une autre table du même type) répertorie les ensembles de données qui ont été chargées en mémoire vive. La figure 3 représente un procédé de basculement de l'environnement d'exécution de confiance à l'environnement d'exécution polyvalent conforme aux enseignements de l'invention. Ce procédé débute donc dans le cadre du fonctionnement de l'appareil électronique 10 dans l'environnement d'exécution de confiance TEE, c'est-à-dire que les fonctionnalités de base de l'appareil électronique 10 sont mises en oeuvre par l'exécution du système d'exploitation de confiance 30. Une bibliothèque (par exemple la bibliothèque LIB2) est chargée à l'étape E100 dans la zone dédiée 80 de la mémoire vive à partir de la zone 60 de la mémoire non-volatile. La bibliothèque est alors utilisée à l'étape E102, par exemple du fait d'un appel d'une fonction de cette bibliothèque par une application exécutée dans le cadre de l'environnement d'exécution de confiance. Le procédé se poursuit normalement dans le cadre de l'environnement d'exécution de confiance jusqu'à l'étape E104 où une interruption provoque un appel au moniteur de sécurité 40 en vue du changement d'environnement d'exécution. Une telle interruption est par exemple générée lorsque l'utilisateur bascule sur une application ne demandant pas un contexte sécurisé pour son exécution (telle qu'une application de jeu). Le moniteur de sécurité 40 prend alors la main et commande à l'étape E106 le chargement de la pile d'exécution 50 avec la liste des applications exécutées dans le cadre de l'environnement d'exécution polyvalent REE. Comme indiqué ci-dessus, cette liste a été mémorisée en mémoire non-volatile réinscriptible lors de la précédente sortie de l'environnement d'exécution polyvalent. Le moniteur de sécurité 40 consulte alors la pile d'exécution 50 à l'étape E108 afin de déterminer les bibliothèques utilisées par la prochaine application à exécuter. Dans la variante mentionnée ci-dessus, le moniteur de sécurité 40 consulte la table séparée qui indique, notamment pour la prochaine application à exécuter (indiquée par la pile d'exécution), les bibliothèques utilisées par cette application. Le moniteur de sécurité 40 peut ainsi déterminer à l'étape E110 si la (ou les) bibliothèque(s) utilisée(s) par la prochaine application à exécuter est (sont) 5 déjà mémorisée(s) dans la zone dédiée 80 de la mémoire vive. En pratique, le moniteur de sécurité 40 lit par exemple (dans la pile d'exécution 50 ou dans la table séparée susmentionnée) le type Ti et l'identifiant lj d'une bibliothèque requise par la prochaine application à exécuter, consulte la zone 60 de la mémoire non-volatile réinscriptible afin de déterminer quelle 10 bibliothèque du type Ti indiqué (mémorisée dans cette zone 60) répond le mieux aux critères définis par l'identifiant lj indiqué (ici comme indiqué ci-dessus un niveau de performance et un niveau de sécurité) et détermine si cette bibliothèque est présente dans la zone dédiée 80 de la mémoire vive. Dans l'affirmative, le procédé se poursuit à l'étape E114 décrite plus bas. 15 Dans la négative, le moniteur de sécurité 40 commande à l'étape E112 le chargement dans la mémoire vive, à partir de la zone 60 de mémorisation des bibliothèques dans la mémoire non-volatile réinscriptible, de la bibliothèque utilisée par la prochaine application à exécuter (c'est-à-dire, dans l'exemple mentionné ci-dessus, de la bibliothèque qui répond le mieux aux critères définis 20 par l'identifiant lj). On procède ainsi éventuellement au chargement de plusieurs bibliothèques utilisées par l'application à exécuter qui ne sont pas présentes dans la zone dédiée 80 de la mémoire vive. On remarque que le moniteur de sécurité 40 peut éventuellement procéder, avant chargement de la (ou des) bibliothèque(s) utilisée(s) par 25 l'application à exécuter, à l'effacement des bibliothèques présentes dans la zone dédiée 80 de la mémoire vive mais non utilisées par l'application à exécuter. En variante, cet effacement n'est réalisé que s'il est nécessaire pour libérer de l'espace mémoire en vue du chargement de la (ou des) bibliothèque(s) utilisée(s) par l'application à exécuter, par exemple selon une méthode de gestion de pages 30 mémoire de type FIFO (de l'anglais "First in, first out), ou LRU (de l'anglais "Least Recently Used', ou LFU (de l'anglais "Least Frequently Used'), ou encore de type priorité aléatoire (ou "Random Priority"). Un processus similaire peut également être mis en oeuvre pour les données : le moniteur de sécurité 40 détermine quels ensembles de données sont utilisés par la prochaine application à exécuter (indiquée dans la pile d'exécution 50), par exemple sur la base des informations contenues dans la pile d'exécution 50 ou dans la table séparée mentionné plus haut, puis détermine si ces ensembles de données sont déjà présents en mémoire vive, et ne charge en mémoire vive à partir de la mémoire non-volatile réinscriptible que les ensembles de données qui n'y sont pas déjà présents. Le moniteur de sécurité 40 commande alors le changement de contexte (changement d'environnement d'exécution) et passe la main à l'environnement d'exécution polyvalent REE à l'étape E114: les fonctionnalités de base du système seront mises en oeuvre par l'exécution du système d'exploitation polyvalent 20 et la première application rencontrée APPUI rencontrée dans la pile d'exécution 50 est exécutée dans cet environnement à l'étape E116. L'exécution de l'application APPUI provoque un appel à une bibliothèque mémorisée dans la zone dédiée 80 (par exemple la bibliothèque LIB1) à l'étape E118. Pour ce faire, l'application APPUI consulte la table 70 et y lit l'adresse ADR de mémorisation en mémoire vive de la bibliothèque concernée. La figure 4 représente un procédé de basculement de l'environnement d'exécution polyvalent à l'environnement d'exécution de confiance conforme aux enseignements de l'invention. Ce procédé débute dans le cadre du fonctionnement de l'appareil électronique 10 dans l'environnement d'exécution polyvalent REE, c'est-à-dire que les fonctionnalités de base de l'appareil électronique 10 sont mises en oeuvre par l'exécution du système d'exploitation polyvalent 20. Une bibliothèque (par exemple la bibliothèque LIB2) est chargée à l'étape E200 dans la zone dédiée 80 de la mémoire vive à partir de la zone 60 de mémorisation des bibliothèques dans la mémoire non-volatile. Dès que le chargement est effectué, le système d'exploitation polyvalent 20 détermine à l'étape E202 des données de vérification CRC associées à la bibliothèque chargée LIB2. Dans l'exemple décrit ici, les données de vérification CRC sont obtenues par application d'un algorithme de contrôle de redondance cyclique (en anglais "Cyclic Redundancy Check') aux plages mémoire où est mémorisée la bibliothèque chargée LIB2. On utilise par exemple un des algorithmes suivants : SHA-2, SHA-3 (SHA provenant de l'anglais "Secure Nash Algorithm"), ou MD5 (de l'anglais "Message-Digest" 5). En variante, on pourrait utiliser une somme de contrôle (en anglais "checksum") ou un code d'authentification (ou MAC de l'anglais "Message Authentication Code"). Les données de vérification obtenues sont communiquées au moniteur de sécurité 40, qui mémorise ces données de vérification à l'étape E204, par 5 exemple au sein de la table 70 et/ou dans une zone accessible en écriture par le moniteur de sécurité uniquement. En variante, les données de vérification pourraient être communiquées au système d'exploitation de confiance 30 et mémorisées dans une zone dédiée au système d'exploitation de confiance 30. On remarque que, selon une variante envisageable, les données de 10 vérification relatives à une bibliothèque donnée pourraient être mémorisées au préalable dans une mémoire accessible par le moniteur de sécurité 40 ou par le système d'exploitation de confiance 30 (sans être calculées par conséquent par le système d'exploitation polyvalent 20 comme indiqué ci-dessus à l'étape E202). Cette variante est envisageable en particulier lorsque la bibliothèque est une 15 bibliothèque de base ou fondamentale (mettant en oeuvre par exemple des algorithmes cryptographiques, tels que RSA ou DES), d'utilisation commune, dont les données de vérification peuvent être mémorisées à l'avance. Une fois chargée comme indiqué plus haut, la bibliothèque peut être utilisée à l'étape E206, par exemple du fait d'un appel d'une fonction de cette 20 bibliothèque par une application exécutée dans le cadre de l'environnement d'exécution polyvalent REE. Le procédé se poursuit normalement dans le cadre de l'environnement d'exécution polyvalent jusqu'à l'étape E208 où une interruption provoque un appel au moniteur de sécurité 40 en vue du changement d'environnement d'exécution 25 (ou changement de contexte) ; une telle interruption est générée par exemple par une application qui nécessite la mise en oeuvre d'un service sécurisé, par le système d'exploitation lui-même qui nécessite d'exécuter des instructions en mode sécurisé, par un ordonnanceur du système d'exploitation qui donne périodiquement le contrôle au système d'exploitation de confiance 30, par un 30 événement extérieur (par exemple déclenché par un utilisateur) ou par une exception (générée par exemple par une détection d'erreur de fonctionnement). Le moniteur de sécurité 40 prend alors la main et commande à l'étape E210 le chargement de la pile d'exécution 50 avec la liste des applications exécutées dans le cadre de l'environnement d'exécution de confiance TEE. Comme déjà indiqué, cette liste a été mémorisée en mémoire non-volatile réinscriptible lors de la précédente sortie de l'environnement d'exécution de confiance. Le moniteur de sécurité 40 consulte alors la pile d'exécution 50 à l'étape E212 afin de déterminer les bibliothèques utilisées par la prochaine application à exécuter. Dans la variante mentionnée ci-dessus, le moniteur de sécurité 40 consulte la table séparée qui indique, notamment pour la prochaine application à exécuter (indiquée par la pile d'exécution), les bibliothèques utilisées par cette application. Le moniteur de sécurité 40 peut ainsi déterminer à l'étape E214 si la (ou les) bibliothèque(s) utilisée(s) par la prochaine application à exécuter est (sont) déjà mémorisée(s) dans la zone dédiée 80 de la mémoire vive. Cette vérification peut être réalisée en pratique de la même manière que ce qui a été indiqué pour l'étape E110 décrite ci-dessus en référence à la figure 3. Dans l'affirmative (et pour chaque bibliothèque utilisée par la prochaine application à exécuter et déjà mémorisée dans la zone dédiée 80 de la mémoire vive), le moniteur de sécurité 40 vérifie à l'étape E218 l'intégrité (c'est-à-dire l'absence d'altération) de la bibliothèque, ici en déterminant des données de vérification associées à la bibliothèque concernée (dans son état actuel), au moyen de l'algorithme utilisé à l'étape E202, et en comparant les données de vérification ainsi obtenues aux données de vérification mémorisées à l'étape E204. Dans la variante indiquée ci-dessus où les données de vérification sont mémorisées à l'étape E204 par le système d'exploitation de confiance 30, cette étape de vérification peut être réalisée par le système d'exploitation de confiance 30. Si la vérification se solde par un résultat positif (égalité entre les données de vérification obtenues à l'étape E218 et les données de vérification mémorisées à l'étape E204), le procédé se poursuit normalement à l'étape E222 décrite plus bas. Si la vérification se solde par un résultat négatif (différence entre les données de vérification obtenues à l'étape E218 et les données de vérification mémorisées à l'étape E204), on lance à l'étape E220 un mécanisme de traitement d'erreur. Selon les applications, un tel mécanisme de traitement d'erreur pourra être par exemple un blocage de l'entité électronique 10, l'arrêt du basculement vers l'environnement d'exécution de confiance TEE (avec retour à l'environnement d'exécution polyvalent sans exécution d'une application sécurisée) ou un saut (représenté en pointillés en figure 4) à l'étape E216 décrite ci-dessous de manière à forcer un nouveau chargement de la bibliothèque concernée, avec effacement éventuel de l'ensemble des ressources (bibliothèques et données) mémorisées en mémoire vive afin d'éviter tout problème de sécurité. Dans la négative à l'étape E214 (c'est-à-dire si la bibliothèque n'est pas présente en mémoire vive), le moniteur de sécurité 40 commande à l'étape E216 le chargement dans la mémoire vive, à partir de la zone 60 de mémorisation des bibliothèques dans la mémoire non-volatile réinscriptible, de la bibliothèque utilisée par la prochaine application à exécuter. En variante, ce chargement pourrait également être effectué par le système d'exploitation de confiance 30. Les étapes E214 à E218 sont répétées pour chacune des bibliothèques utilisées par la prochaine application à exécuter (indiquée par la pile d'exécution 15 50). On propose ici que le moniteur de sécurité 40 procède, avant chargement de la (ou des) bibliothèque(s) utilisée(s) par l'application à exécuter, à l'effacement des bibliothèques présentes dans la zone dédiée 80 de la mémoire vive mais non utilisées par l'application à exécuter, ou pour lesquelles la 20 vérification d'intégrité de l'étape E218 s'est soldée de manière négative. Ainsi, la zone dédiée 80 de la mémoire vive ne contient alors que des bibliothèques pour lesquelles les données de vérification ont été vérifiées (par le moniteur de sécurité 40 ou, en variante, par le système d'exploitation de confiance 30) à l'étape E218 ou des bibliothèques chargées par le moniteur de sécurité 40 (ou, en variante, le 25 système d'exploitation de confiance 30) à l'étape E216. Dans l'exemple qui vient d'être décrit, la vérification de l'intégrité de la bibliothèque est confiée au moniteur de sécurité 40. On peut prévoir en variante qu'une bibliothèque inclut une fonction de vérification de sa propre intégrité, et retourne un code d'authentification au moniteur de sécurité 40 lorsque l'intégrité 30 est vérifiée. On remarque par ailleurs qu'un processus similaire peut également être mis en oeuvre pour les données : le moniteur de sécurité 40 détermine quels ensembles de données sont utilisés par la prochaine application à exécuter (indiquée dans la pile d'exécution 50), puis détermine si ces ensembles de données sont déjà présents en mémoire vive et si leur intégrité est respectée, et ne charge un ensemble de données en mémoire vive à partir de la mémoire non-volatile réinscriptible que si cet ensemble n'y est pas déjà présent ou si les données de cet ensemble ont été corrompues (intégrité non respectée). Le moniteur de sécurité 40 commande ensuite à l'étape E222 le changement de contexte (changement d'environnement d'exécution) et passe la main à l'environnement d'exécution de confiance TEE : les fonctionnalités de base du système seront mises en oeuvre par l'exécution du système d'exploitation de confiance 30 et la première application APPUI rencontrée dans la pile d'exécution 50 est exécutée dans cet environnement à l'étape E224. L'exécution de l'application APPUI provoque un appel à une bibliothèque mémorisée dans la zone dédiée 80 (par exemple la bibliothèque LIB1) à l'étape E226. Dans l'exemple qui vient d'être décrit, les étapes de vérification de l'intégrité E218 et E220 sont mises en oeuvre par le moniteur de sécurité 40. On pourrait toutefois prévoir en variante que ces étapes soient mises en oeuvre par le système d'exploitation de confiance 30, après basculement dans l'environnement d'exécution de confiance TEE (la vérification de l'intégrité pouvant alors par exemple être réalisée pour toutes les bibliothèques mémorisées dans la zone dédiée 80, c'est-à-dire pour les bibliothèques déjà présentes dans la zone dédiée 80 avant appel du moniteur de sécurité 40 à l'étape E208 comme pour les bibliothèques chargées dans la zone dédiée 80 par le moniteur de sécurité à l'étape E216). REVENDICATIONS1. Appareil électronique (10) comprenant un processeur et une mémoire vive, et conçu pour mettre en oeuvre un moniteur de sécurité (40) apte à faire basculer (E114; E222) le fonctionnement de l'appareil électronique (10) entre un premier environnement d'exécution (TEE; REE) et un second environnement d'exécution (REE ; TEE), dans lequel l'appareil électronique (10) est conçu pour faire exécuter par le processeur, dans le premier environnement d'exécution (TEE ; REE), une première application (E102 ; E206) utilisant une ressource mémorisée dans une partie de la mémoire vive et, dans le second environnement d'exécution (REE; TEE), une seconde application (E118 ; E226) requérant une ressource mémorisée dans ladite partie de la mémoire vive, caractérisé en ce que le moniteur de sécurité (40) est conçu pour déterminer (E108, E110 ; E212, E214) si la ressource requise correspond à la ressource utilisée et pour charger (E112; E216) la ressource requise dans ladite partie de la mémoire vive si la ressource requise ne correspond pas à la ressource utilisée. 2. Appareil électronique selon la revendication 1, dans lequel le moniteur de sécurité (40) est conçu pour charger en mémoire vive une pile d'exécution (50) du second environnement (REE; TEE) et pour déterminer si la ressource requise correspond à la ressource utilisée notamment par lecture de la pile d'exécution chargée (50). 3. Appareil électronique selon la revendication 1 ou 2, dans lequel le moniteur de sécurité (40) est conçu pour lire au moins une information (Ti, 112, T2, 121) relative à la ressource utilisée dans une table (70) et pour déterminer si la ressource requise correspond à la ressource utilisée sur la base notamment de l'information lue (Ti, 112, T2, 121). 4. Appareil électronique selon l'une des revendications 1 à 3, conçu pour mettre en oeuvre (E218) des moyens de vérification de l'intégrité de la ressource utilisée lorsque le moniteur de sécurité détermine que la ressource utilisée correspond à la ressource requise. 5. Appareil électronique selon l'une des revendications 1 à 4, dans lequel la ressource utilisée est une bibliothèque (LIB1, LIB2). 6. Appareil électronique selon l'une des revendications 1 à 4, dans lequella ressource utilisée est un ensemble de données. 7. Procédé mis en oeuvre dans un appareil électronique (10) comprenant un processeur et une mémoire vive, caractérisé en ce qu'il comprend les étapes suivantes : - mise en oeuvre (E102; E206), dans un premier environnement d'exécution (TEE ; REE), d'une première application utilisant une ressource mémorisée dans une partie de la mémoire vive ; - réception (E104; E208), par un moniteur de sécurité (40), d'une demande de basculement du premier environnement d'exécution (TEE; REE) à 10 un second environnement d'exécution (REE ; TEE) ; - détermination (E108, E110 ; E212, E214), par le moniteur de sécurité (40), si une ressource requise par une seconde application exécutable dans le second environnement d'exécution (REE ; TEE) correspond à la ressource utilisée ; 15 - si le moniteur de sécurité (40) détermine que la ressource requise ne correspond pas à la ressource utilisée, chargement (E112 ; E216) de la ressource requise dans ladite partie de la mémoire vive ; - basculement (E114; E222), par le moniteur de sécurité (40), du premier environnement d'exécution (TEE ; REE) au second environnement 20 d'exécution (REE ; TEE) ; - exécution (E118 ; E226) de la seconde application. 8. Procédé selon la revendication 7, comprenant une étape (E106; E210) de chargement en mémoire vive, par le moniteur de sécurité (40), d'une pile d'exécution (50) du second environnement (REE ; TEE) et dans lequel l'étape de 25 détermination inclut une sous-étape (E108; E212) de lecture de la pile d'exécution chargée (50). 9. Procédé selon la revendication 7 ou 8, comprenant une étape de lecture, par le moniteur de sécurité (40), d'au moins une information (Ti, 112, T2, 121) relative à la ressource utilisée dans une table (70) et dans lequel l'étape de 30 détermination utilise l'information lue (Ti, 112, T2, 121). 10. Procédé selon l'une des revendications 7 à 9, comprenant une étape (E128) de vérification de l'intégrité de la ressource utilisée lorsque le moniteur de sécurité (40) détermine que la ressource utilisée correspond à la ressource requise. 11. Procédé selon l'une des revendications 7 à 10, dans lequel la ressource utilisée est une bibliothèque (LIB1, LIB2). 12. Procédé selon l'une des revendications 7 à 10, dans lequel la ressource utilisée est un ensemble de données.5