FR3028071A1 - ELECTRONIC APPARATUS AND METHOD IMPLEMENTED IN SUCH AN ELECTRONIC APPARATUS - Google Patents

Abstract

An electronic apparatus comprising a processor and a random access memory, and adapted to implement a security monitor adapted to switch (E114) the operation of the electronic apparatus between a first execution environment (TEE) and a second execution environment (REE). The electronic apparatus is adapted to cause the processor, in the first execution environment (TEE), to execute a first application (E102) using a resource stored in a portion of the random access memory and, in the second execution environment (REE), a second application (E118) requiring a resource stored in said portion of the RAM, the security monitor is adapted to determine (E108, E110) whether the required resource corresponds to the resource used and to load (E112) the resource required in the said portion of the RAM if the requested resource does not correspond to the resource used. A method implemented in such an electronic device is also proposed.

Description

TECHNICAL FIELD TO WHICH THE INVENTION RELATES The present invention relates to switching between two execution environments in an electronic device. It relates more particularly to an electronic device and method implemented in such an electronic device. The invention applies particularly advantageously in the case where libraries or data are used by different applications executed in the electronic device. BACKGROUND ART As explained for example in the article "The Untapped Potential of Trusted Execution Environments on Mobile Devices" of J.-E. Ekberg, K. Kostiainen and N. Asokan in IEEE Security & Privacy, volume PP edition 99, April 16, 2014, it is known to secure the operation of electronic devices by the use of a trusted operating system (or " Trusted OS, which provides a Trusted Execution Environment (TEE) in which only certain applications can be installed and executed.

Such a trusted environment is generally offered alongside a versatile environment (or REE for "Rich Execution Environment") in which the security constraints are lower and a greater number of applications can be installed. The versatile environment is based on the execution within the electronic device of a versatile operating system (or "Rich OS" according to the English name), distinct from the trusted operating system. In order to guarantee good isolation between the two environments, it is generally provided that the switching of the operation of the electronic device from one environment to another is managed by a security monitor (or "secure monitor" according to the English name). -saxonne). OBJECT OF THE INVENTION In this context, the present invention proposes an electronic device comprising a processor and a random access memory, and designed to implement a safety monitor able to switch the operation of the electronic device between a first environment of the device. and a second execution environment, wherein the electronic apparatus is adapted to cause the processor, in the first execution environment, to execute a first application using a resource (first resource) stored in a portion of the memory and in the second execution environment, a second application requiring a resource (second resource) stored in said portion of the random access memory, characterized in that the security monitor is adapted to determine if the required resource (second resource) corresponds to the resource used (first resource) and to load the required resource (second e resource) in said portion of the RAM if the required resource (second resource) does not match the resource used (first resource). The security monitor thus verifies that the (second) resource, required by the second application executed in the second environment (that is to say after change of context), does not correspond to the (first) resource present in RAM. . The loading of the required resource (second resource), which may require a non-negligible time, for example from a rewritable non-volatile memory, is thus performed only when necessary.

Note that in some applications, the loading of the required resource (second resource) can in some cases be realized even when the required resource (second resource) corresponds to the resource used (first resource), for example if it is in furthermore detected that the data forming the resource used (first resource) has been corrupted, as explained in the description which follows. In such an application, however, a loading of the required resource (second resource) is avoided when the required resource (second resource) corresponds to the resource used (first resource) and the data forming the resource used (first resource) have not been used. not been corrupted.

Other advantageous and non-limiting features of the electronic device according to the invention are the following: the security monitor is designed to load in RAM an execution stack of the second environment and to determine if the required resource ( second resource) corresponds to the resource used (first resource) including (i.e. at least) by reading the loaded execution stack; the security monitor is designed to read at least one information relating to the resource used (first resource) in a table and to determine if the required resource (second resource) corresponds to the resource used (first resource) on the basis notably ( that is, at least on the basis of the information read; the electronic device is designed to implement means for verifying the integrity of the resource used (first resource) when the security monitor determines that the resource used (first resource) corresponds to the required resource (second resource) ; the means for verifying the integrity comprise, in particular, means for determining verification data, implemented by the security monitor or by the trusted operating system; - the resource used (first resource) is a library; - the required resource (second resource) is a library; - the resource used (first resource) is a set of data; - the required resource (second resource) is a set of data.

The invention also proposes a method implemented in an electronic apparatus comprising a processor and a random access memory, characterized in that it comprises the following steps: implementation, in a first execution environment, of a first application using a (first) resource stored in a portion of the RAM; receiving, by a security monitor, a request to switch from the first execution environment to a second execution environment; determining, by the security monitor, whether a (second) resource required by a second executable application in the second execution environment corresponds to the resource used (first resource); if the security monitor determines that the required resource (second resource) does not correspond to the resource used (first resource), loading the required resource (second resource) in said part of the random access memory; - Failover, by the security monitor, the first runtime environment to the second runtime environment; - execution of the second application. Other advantageous and non-limiting characteristics of the electronic device according to the invention are the following: the method comprises a step of loading in RAM, by the safety monitor, a run stack of the second environment ; the determination step includes a substep of reading the loaded execution stack; the method comprises a step of reading, by the security monitor, at least one information relating to the resource used (first resource) in a table; the determination step uses the information read; the method comprises a step of verifying the integrity of the resource used (first resource) when the security monitor determines that the resource used (first resource) corresponds to the required resource (second resource). DETAILED DESCRIPTION OF AN EXEMPLARY EMBODIMENT The following description with reference to the accompanying drawings, given as non-limiting examples, will make it clear what the invention consists of and how it can be achieved. In the accompanying drawings: FIG. 1 schematically represents the use of two execution environments within an electronic device in which the invention is implemented; FIG. 2 represents functional entities stored in the electronic device 10 and used in the context of the present invention; FIG. 3 represents a method of switching from the trusted execution environment to the polyvalent execution environment in accordance with the teachings of the invention; and FIG. 4 represents a method of switching from the polyvalent execution environment to the trusted execution environment in accordance with the teachings of the invention. FIG. 1 schematically represents the use of two execution environments within an electronic device 10 in which the invention is implemented. This electronic device 10, here a terminal (for example of the smart phone type or "smartphone" according to the English name), 5 comprises a microprocessor-based architecture. Two different operating systems are used within the electronic apparatus 10: a versatile operating system 20 (or "Rich OS") and a trusted operating system (or " Trusted OS "), sometimes referred to as a secure operating system (" Secure OS "). The versatile operating system 20 allows the download, installation and execution of applications with great freedom for the user. The implementation of the versatile operating system 20 thus creates a versatile environment or REE (for "Rich Execution Environment"). On the contrary, in the context of the operation of the electronic apparatus 15 based on the trusted operating system 30, the possibilities of downloading and installing applications are limited (for example to applications having received a certification particular) so that the use of the trusted operating system makes it possible to create within the electronic apparatus 10 a trusted execution environment or TEE (for 20 "Trusted Execution Environment"). This trusted execution environment offers, for example, a level of security in accordance with the common criteria EAL (for "Evaluation Assurance Lever"), corresponding to the ISO 15408 standard, with a level between 2 and 7, or to the FIPS standard (for "Federal Information Processing Standard") 140-2. In the example described here, the versatile operating system 20 and the trusted operating system 30 are executed by the same processor of the electronic apparatus, for example a system-on-a-chip (or SoC) processor. "System on Chip"). In addition to the processor, such a system-on-a-chip comprises other electronic elements having various functionalities, including one or more memories (for example a read-only memory or ROM for "Read Only Memory", a RAM - or RAM for "Random"). Access Memory "- and a rewritable non-volatile memory, for example of the EEPROM type for" Electrically Erasable and Programmable Read Only Memory "); a portion of at least one of these memories may be reserved for the trusted operating system (i.e., that portion of memory may be read and / or written only by the trusted operating system 30 or, here, by the security monitor 40, and not by the versatile operating system 20). Note that conversely, the trusted operating system 30 (as also the security monitor 40) can access read and / or write memory areas used by the versatile operating system 20 Alternatively, an electronic apparatus with two processors could be used with the versatile operating system 20 running on one and the trusted operating system 30 running on the other. The electronic device 10 also implements a security monitor 40 (or "Secure Monitor" in English), which executes in the case just mentioned on the processor of the electronic device 10. The safety monitor 40 controls (as explained below) the switchover between the operation of the electronic apparatus 10 based on the multipurpose operating system 20 and the operation of the electronic apparatus 10 based on the computer system. operation of trust 30 (and vice versa), so that the electronic apparatus 10 operates at all times on the basis of only one of the two operating systems 20, 30 (i.e. in a single of the two environments mentioned above). According to one conceivable embodiment, the operating system executed before switchingover (for example the polyvalent operating system 20) is put on standby by the switchover and any access to elements external to the processor (for example the human machine interface including a keyboard and / or a screen and / or other input-output module) is then inhibited for the operating system in standby, so that the operating system activated by the failover (here the system of 'exploitation of confidence 30) totally controls the external element, here the man-machine interface. FIG. 2 represents functional entities stored in the electronic device 10 and used in the context of the present invention. An execution stack 50 is stored in RAM and comprises an ordered list of the next applications APPLI1, APPLI2 whose execution is planned. For each application APPLI1, APPLI2, the execution stack indicates for example an identifier of the application and an address of storage of the application (which can point for example to a memory zone located in random access memory or in non-volatile memory rewritable). It is provided here that are also indicated in the execution stack libraries (in English "fibraries") or data to which the application concerned uses for its execution. As a variant, these indications could be contained in a separate table which lists, for each application stored in the electronic apparatus 10, the libraries and the data to which this application makes use.

During a change of execution environment, the current execution stack is saved in rewritable non-volatile memory so that the execution stack can be restored to the state for any subsequent return to the Active runtime environment before change. An area 60 of the non-volatile rewritable memory stores libraries each identified by their type Ti and by their identifier lj. The type Ti here denotes the class (for example: encryption) and the subclass (for example: RSA) of the library concerned. The identifier lj is indicative of a performance level (here between 0 and 99), related for example to the execution time of the function concerned, and a security level (also between 0 and 99 in the example described here). The electronic device 10 stores, for example in random access memory, a table 70 which lists the libraries LIB1, LIB2 stored in a dedicated area 80 of the random access memory (after copying from the area 60 of the non-volatile memory rewritable when an application used this library). For each library LIB1, LIB2 stored in the dedicated area 80 of the RAM, the table includes the RAM storage address of the library concerned LIB1, LIB2. Thus, in the example shown in FIG. 2, a library LIB1 of type Ti and identifier 112 and a library LIB2 of type T2 and of identifier 121 are stored in the dedicated zone 80 of the random access memory. same as the rewritable non-volatile memory stores data used by the applications executed within the electronic device 10. These data are organized into data sets, each set can be identified as indicated above about the libraries. A data set includes, for example, user identification data, connection data to a remote server, and so on. As indicated for the libraries, the table 70 (or, alternatively, another table of the same type) lists the data sets that have been loaded into RAM. FIG. 3 represents a method of switching from the trusted execution environment to the polyvalent execution environment in accordance with the teachings of the invention. This method therefore starts as part of the operation of the electronic apparatus 10 in the trusted execution environment TEE, that is to say that the basic functionalities of the electronic apparatus 10 are implemented by the Execution of the Trusted Operating System 30. A library (e.g. library LIB2) is loaded in step E100 into the dedicated area 80 of the RAM from the area 60 of the non-volatile memory. The library is then used in step E102, for example due to a call of a function of this library by an application executed as part of the trusted execution environment. The method continues normally as part of the trusted execution environment until step E104 where an interrupt causes a call to the security monitor 40 for the purpose of changing the execution environment. Such an interruption is for example generated when the user switches to an application that does not require a secure context for its execution (such as a game application).

The safety monitor 40 then takes control and controls in step E106 the loading of the execution stack 50 with the list of applications executed as part of the versatile REE runtime environment. As noted above, this list has been stored in rewritable non-volatile memory at the previous output of the multi-purpose runtime environment. The security monitor 40 then consults the execution stack 50 in step E108 to determine the libraries used by the next application to be executed. In the variant mentioned above, the security monitor 40 consults the separate table which indicates, in particular for the next application to be executed (indicated by the execution stack), the libraries used by this application. The safety monitor 40 can thus determine in step E110 whether the library (or libraries) used by the next application to be executed is (are) already stored in the dedicated zone 80 of the RAM. In practice, the security monitor 40 reads for example (in the execution stack 50 or in the aforementioned separate table) the type Ti and the identifier lj of a library required by the next application to be executed, consult the zone 60 re-writable non-volatile memory to determine which library of the indicated type Ti (stored in this area 60) best meets the criteria defined by the indicated identifier ij (here as indicated above a level of performance and a level). security) and determines if this library is present in the dedicated area 80 of the RAM. If so, the method continues in step E114 described below. If not, the security monitor 40 controls in step E112 the loading in the random access memory, from the zone 60 for storing the libraries in the non-volatile rewritable memory, of the library used by the next application to perform (i.e., in the example mentioned above, the library that best meets the criteria defined by the identifier lj). This is possibly the process of loading several libraries used by the application to be executed that are not present in the dedicated area 80 of the RAM. It should be noted that the security monitor 40 may possibly proceed, before loading the library (s) used by the application to be executed, to erase the libraries present in the dedicated zone 80 of the RAM but not used by the application to execute. As a variant, this erasure is realized only if it is necessary to release memory space for the purpose of loading the library (or libraries) used by the application to be executed, for example according to FIFO (first in, first out) memory management method, or LRU (Least Recently Used) (LFU). or a random priority (or "Random Priority") method A similar process can also be implemented for the data: the security monitor 40 determines which data sets are used by the next application to be executed (indicated in FIG. execution stack 50), for example on the basis of the information contained in the execution stack 50 or in the separate table mentioned above, then determines whether these sets of data are already present in RAM, and do not load in memory live from the non-volatile memory writable only data sets that are not already present. The security monitor 40 then controls the change of context (change of execution environment) and passes the hand to the versatile execution environment REE in step E114: the basic functionalities of the system will be implemented by execution of the versatile operating system 20 and the first encountered APP encountered in the execution stack 50 is executed in this environment in step E116. The execution of the APPUI application causes a call to a library stored in the dedicated zone 80 (for example the LIB1 library) in step E118. To do this, the APPUI application consults the table 70 and reads there the address ADR of storage in RAM of the library concerned. FIG. 4 represents a method of switching from the polyvalent execution environment to the trusted execution environment in accordance with the teachings of the invention.

This method starts as part of the operation of the electronic apparatus 10 in the versatile REE execution environment, i.e. the basic functionality of the electronic apparatus 10 is implemented by the execution of the versatile operating system 20. A library (for example the library LIB2) is loaded in step E200 in the dedicated area 80 of the random access memory from the zone 60 for storing the libraries in the non-volatile memory. As soon as the loading is carried out, the polyvalent operating system 20 determines in step E202 CRC verification data associated with the loaded library LIB2. In the example described here, the CRC verification data are obtained by applying a cyclic redundancy check algorithm to the memory areas where the LIB2 loaded library is stored. the following algorithms: SHA-2, SHA-3 (SHA from the "Secure Nash Algorithm"), or MD5 (from the English "Message-Digest" 5) Alternatively, one could use a checksum (in English "checksum") or an authentication code (or MAC of the English "Message Authentication Code"). The verification data obtained are communicated to the security monitor 40, which stores these verification data in step E204, for example in table 70 and / or in a write-accessible area by the safety monitor only Alternatively, the verification data could be communicated to the trusted operating system 30 and stored in an area It will be noted that, according to one conceivable variant, the verification data relating to a given library could be stored beforehand in a memory accessible by the security monitor 40 or by the system of the security system. trusted operation 30 (therefore not computed by the versatile operating system as described above in step E202). This variant can be envisaged, in particular when the library is a basic or basic library (using, for example, cryptographic algorithms, such as RSA or DES), of common use, whose verification data can be stored in memory. advanced. Once loaded as indicated above, the library can be used in step E206, for example because of a call of a function of this library by an application executed as part of the versatile execution environment REE. The method continues normally as part of the multi-purpose execution environment until step E208 where an interrupt causes a call to the security monitor 40 for the purpose of changing the execution environment (or changing context ); such an interruption is generated for example by an application which requires the implementation of a secure service, by the operating system itself which requires executing instructions in secure mode, by a scheduler of the operating system which periodically gives control to the trusted operating system 30, by an external event (for example triggered by a user) or by an exception (generated for example by an operating error detection). The security monitor 40 then takes control and controls in step E210 the loading of the execution stack 50 with the list of applications executed as part of the trusted execution environment TEE.

As already indicated, this list has been stored in non-volatile rewritable memory during the previous output of the trusted execution environment. The security monitor 40 then consults the execution stack 50 in step E212 to determine the libraries used by the next application to be executed. In the variant mentioned above, the security monitor 40 consults the separate table which indicates, in particular for the next application to be executed (indicated by the execution stack), the libraries used by this application.

The security monitor 40 can thus determine in step E214 whether the library (or libraries) used by the next application to be executed is (are) already stored in the dedicated area 80 of the memory vivid. This verification can be carried out in practice in the same way as that indicated for step E110 described above with reference to FIG.

If so (and for each library used by the next application to be executed and already stored in the dedicated area 80 of the RAM), the security monitor 40 verifies in step E218 the integrity (ie the absence of alteration) of the library, here by determining verification data associated with the library concerned (in its current state), using the algorithm used in step E202, and comparing the data thus obtained verification data stored in step E204. In the variant indicated above where the verification data are stored in step E204 by the trusted operating system 30, this verification step can be performed by the trusted operating system 30. If the verification is balance by a positive result (equality between the verification data obtained in step E218 and the verification data stored in step E204), the method continues normally in step E222 described below.

If the verification results in a negative result (difference between the verification data obtained in step E218 and the verification data stored in step E204), step E220 initiates an error processing mechanism. Depending on the application, such an error-handling mechanism could for example be a blocking of the electronic entity 10, stopping the switchover to the trusted execution environment TEE (with return to the execution environment versatile without running a secure application) or a jump (shown in dashed lines in Figure 4) in step E216 described below so as to force a new load of the library concerned, with eventual erasure of all resources (libraries and data) stored in RAM to avoid any security problem. If not in step E214 (that is, if the library is not present in RAM), the security monitor 40 controls at step E216 the loading in the random access memory, starting from the zone 60 for storing the libraries in the rewritable non-volatile memory of the library used by the next application to be executed. Alternatively, this loading could also be performed by the trusted operating system 30. The steps E214 to E218 are repeated for each of the libraries used by the next application to be executed (indicated by the execution stack 50). It is proposed here that the security monitor 40 proceeds, before loading the (or) library (s) used by the application to be executed, the erasure libraries present in the dedicated area 80 of the RAM but not used by the application to be performed, or for which the integrity check of step E218 ended negatively. Thus, the dedicated zone 80 of the random access memory only contains libraries for which the verification data have been verified (by the security monitor 40 or, alternatively, by the trusted operating system 30) at the same time. step E218 or libraries loaded by the security monitor 40 (or, alternatively, the trusted operating system 30) in step E216. In the example which has just been described, the verification of the integrity of the library is entrusted to the security monitor 40. It may be provided in a variant that a library includes a function of checking its own integrity, and returns a authentication code to the security monitor 40 when integrity 30 is verified. Note also that a similar process can also be implemented for the data: the security monitor 40 determines which sets of data are used by the next application to be executed (indicated in the execution stack 50) and then determines if these data sets are already present in RAM and if their integrity is respected, and only load a set of RAM data from the non-volatile rewritable memory if this set is not already present there or if the data in this set has been corrupted (integrity not respected).

The security monitor 40 then controls the change of context (change of execution environment) in step E222 and hands over to the TEE trusted execution environment: the basic functionalities of the system will be implemented by the execution of the trusted operating system 30 and the first APPUI application encountered in the execution stack 50 is executed in this environment in step E224. The execution of the APPUI application causes a call to a library stored in the dedicated area 80 (for example the library LIB1) in step E226. In the example just described, the integrity verification steps E218 and E220 are implemented by the security monitor 40. However, it could alternatively be provided that these steps are implemented by the security system. trusted operation 30, after switching to the trusted execution environment TEE (the integrity check can then for example be performed for all the libraries stored in the dedicated zone 80, that is to say for the libraries already present in the dedicated zone 80 before calling the security monitor 40 in step E208 as for the libraries loaded in the dedicated zone 80 by the security monitor in step E216).

Claims (12)

REVENDICATIONS1. An electronic apparatus (10) comprising a processor and a random access memory, and adapted to implement a security monitor (40) adapted to switch (E114; E222) the operation of the electronic apparatus (10) between a first environment execution (TEE; REE) and a second execution environment (REE; TEE), wherein the electronic apparatus (10) is adapted to execute by the processor in the first execution environment (TEE; REE) , a first application (E102; E206) using a resource stored in a part of the random access memory and, in the second execution environment (REE; TEE), a second application (E118; E226) requiring a resource stored in said part RAM, characterized in that the security monitor (40) is adapted to determine (E108, E110; E212, E214) whether the required resource corresponds to the resource used and to load (E112; E216) the required resource in said p part of the RAM if the required resource does not match the resource used. An electronic apparatus according to claim 1, wherein the security monitor (40) is adapted to load in RAM an execution stack (50) of the second environment (REE; TEE) and to determine if the requested resource corresponds to the resource used in particular by reading the loaded execution stack (50). An electronic apparatus according to claim 1 or 2, wherein the security monitor (40) is adapted to read at least one information (Ti, 112, T2, 121) relating to the resource used in a table (70) and to determining whether the resource required corresponds to the resource used based in particular on the information read (Ti, 112, T2, 121). 4. Electronic device according to one of claims 1 to 3, adapted to implement (E218) means for verifying the integrity of the resource used when the security monitor determines that the resource used corresponds to the required resource. 5. Electronic device according to one of claims 1 to 4, wherein the resource used is a library (LIB1, LIB2). 6. Electronic device according to one of claims 1 to 4, in which the resource used is a set of data. 7. A method implemented in an electronic apparatus (10) comprising a processor and a random access memory, characterized in that it comprises the following steps: - implementation (E102; E206), in a first execution environment ( TEE; REE), of a first application using a resource stored in a part of the random access memory; receiving (E104; E208), by a security monitor (40), a request to switch from the first execution environment (TEE; REE) to a second execution environment (REE; TEE); determination (E108, E110, E212, E214) by the security monitor (40), if a resource required by a second application executable in the second execution environment (REE; TEE) corresponds to the resource used; - if the security monitor (40) determines that the requested resource does not correspond to the resource used, loading (E112; E216) the required resource in said portion of the RAM; - switching (E114; E222), by the security monitor (40), from the first execution environment (TEE; REE) to the second execution environment (REE; TEE); - execution (E118; E226) of the second application. 8. A method according to claim 7, comprising a step (E106; E210) of loading in RAM, by the safety monitor (40), of an execution stack (50) of the second environment (REE, TEE) and wherein the determining step includes a read sub-step (E108; E212) of the loaded execution stack (50). 9. The method of claim 7 or 8, comprising a step of reading, by the security monitor (40), at least one information (Ti, 112, T2, 121) relating to the resource used in a table (70). ) and wherein the determining step uses the information read (Ti, 112, T2, 121). The method according to one of claims 7 to 9, comprising a step (E128) for verifying the integrity of the resource used when the security monitor (40) determines that the resource used corresponds to the resource required. 11. Method according to one of claims 7 to 10, wherein the resource used is a library (LIB1, LIB2). 12. Method according to one of claims 7 to 10, wherein the resource used is a set of data.