• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    A method of loading a RAM file into an electronic apparatus configured to operate in a Trusted Execution Environment (TEE), by executing a trusted operating system by a processor of the electronic device, or in a versatile execution environment (REE), characterized in that it comprises the following steps: - reception (E10), by the trusted operating system, of information (L1) identifying at least one file; - checking (E11), by the trusted operating system, the conformity of the identified file to at least one given criterion; - in case of compliance, loading (E13) of the identified file in a zone (Z2) of read-only RAM during operation in the versatile execution environment (REE). An associated electronic device is also proposed.
    公开号:FR3028069A1
    申请号:FR1460679
    申请日:2014-11-05
    公开日:2016-05-06
    发明作者:Axel Francois；Michele Sartori
    申请人:Oberthur Technologies SA；
    IPC主号:
    专利说明:

    [0001] TECHNICAL FIELD TO WHICH THE INVENTION RELATES The present invention relates to file sharing between a trusted execution environment and a versatile execution environment. More particularly, it relates to a method for loading a RAM file into an electronic apparatus designed to operate in a trusted execution environment and in a versatile runtime environment, as well as such an electronic apparatus. The invention is particularly advantageous in the case where there is provided a shared memory area usable by both the trusted execution environment and the versatile execution environment. 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 less and a greater number of applications can therefore 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 execution environments and thus good operational safety, dedicated memory spaces are generally provided for each execution environment, in particular in random access memory. However, it has been proposed to use in addition a shared memory area accessible by the two runtime environments, as mentioned in particular in T. Roth's presentation "Next Generation Mobile Rootkits", BlackHat Europe 2013 (cited as reference [15] in the article mentioned above).
    [0002] OBJECT OF THE INVENTION In this context, the present invention proposes a method for loading a file in RAM into an electronic device designed to operate in a trusted execution environment, because of the execution of a system of trusted operation by a processor of the electronic device, or in a versatile execution environment, characterized in that it comprises the following steps: receiving, by the trusted operating system, information identifying at least A file ; verification, by the trusted operating system, of the conformity of the identified file with at least one given criterion; - in case of compliance, loading (for example by the trusted operating system) of the identified file into a read-only RAM area when operating in the versatile runtime environment.
    [0003] The trusted operating system thus controls the loading of files into an area of shared RAM between the trusted runtime environment and the versatile runtime environment; this shared zone is read-only when operating in the general-purpose runtime environment, and the files stored in it, which are used in particular in the trusted execution environment, can not be altered by application running in the multi-purpose runtime environment. This charging method can be implemented at the start of the electronic device, as described in detail below, or during operation, for example at the time of launching (in the multi-purpose execution environment) of an application corresponding to the file or using the file. The identified file is for example an application, a library or a set of data.
    [0004] According to other optional and therefore non-limiting features: the information identifying the file is contained in a requirements document (for example a list of requirements) prepared during operation in the polyvalent execution environment; the requirements document is constructed based on data representative of the usage frequencies of the applications installed in the multipurpose execution environment; - the requirements document is constructed according to usage statistics related to several criteria; the method comprises a step of construction, by the trusted operating system, of a sharing list including a designation of the loaded file and a storage address of the loaded file (for example a virtual address as indicated below) ; the sharing list includes integrity verification information associated with the loaded file; the share list includes a certificate generated by the trusted operating system and relating to the loaded file; the sharing list is stored in said read-only RAM area when operating in the multi-purpose execution environment; said loading is performed from a non-volatile memory (for example a rewritable non-volatile memory); said zone is read-only when operating in the multi-purpose execution environment by means of virtual addresses pointing to physical addresses distinct from the virtual addresses concerned; the information identifying the file is received during a switch from the general-purpose runtime environment to the trusted runtime environment. The method may further comprise the following steps, performed in the multipurpose execution environment for each file mentioned in the requirements document: - determining whether the mentioned file is loaded in said read-only RAM area; - If not, load the affected file into another write-accessible RAM area when operating in the multi-purpose runtime environment. The proposed method may further include the following steps: - following installation of a new application in the multi-purpose execution environment, transmission to the trusted operating system of an updated requirements document; - Loading in the read-only RAM area when operating in the multi-purpose runtime environment a new file named in the updated requirements document.
    [0005] The invention also provides an electronic apparatus comprising at least one processor and a random access memory, and adapted to operate in a trusted execution environment, due to the execution of a trusted operating system by the processor, or in a versatile execution environment, characterized in that the trusted operating system is adapted to receive information identifying at least one file, to check the conformity of the identified file to at least one given criterion and to load, in case of compliance, the identified file in a read-only RAM area when operating in the multi-purpose runtime environment.
    [0006] This electronic device may further include one or more of the optional features formulated above in terms of method. 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: - Figure 1 shows the main elements of an electronic device used in the context of the invention; FIG. 2 schematically represents the use of two execution environments within the electronic apparatus of FIG. 1; FIG. 3 illustrates the sharing of the RAM proposed in the context of the invention; FIG. 4a shows functional tables stored in the electronic apparatus of FIG. 1 and used in the context of the present invention; FIG. 4b represents a three-dimensional table for storing usage statistics that can be used in an alternative embodiment; FIG. 5 represents an exemplary method of loading files in RAM in accordance with the invention; FIG. 6 represents functional lists developed during the process of FIG. 5. FIG. 1 represents the main elements of an electronic apparatus 10 in which the invention is implemented.
    [0007] This electronic device 10, here a terminal (for example of the smart phone type or "smartphone" according to the English name), includes a microprocessor-based architecture. Alternatively, the electronic device could be a video decoder (sometimes called "set-top box") or a connected electronic device (such as a bracelet, a watch, glasses or a counter of not). The electronic apparatus 10 includes a processor 2, for example a microprocessor of a system on chip (or SoC for "System on Chip"). In addition to the processor 2, such a system-on-a-chip comprises other electronic elements having various functionalities, for example a read-only memory (not represented), or ROM for "Read Only Memory", a RAM 4 - or RAM for "Random Access" Memory "- and a rewritable non-volatile memory 6, for example of the EEPROM type for" Electrically Erasable and Programmable Read Only Memory "). FIG. 2 diagrammatically shows the use of two execution environments within the electronic apparatus 10. To do this, two different operating systems can be executed by the processor 2 of the electronic apparatus 10: polyvalent exploitation 20 (or "Rich OS" according to the Anglo-Saxon name) and a trusted operating system 30 (or "Trusted OS"), sometimes referred to as secure operating system ("Secure OS"). The versatile operating system 20 allows 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").
    [0008] On the contrary, in the context of the operation of the electronic apparatus 10 on the basis of the trusted operating system 30, the possibilities of downloading and installing applications are limited (for example to applications having received a particular certification ) 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 "Trusted Execution Environment"). This trusted execution environment offers, for example, a security level in accordance with the common criteria EAL (for "Evaluation Assurance 10 Level"), 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 The electronic apparatus 10 also uses a security monitor 40 (or "Secure Monitor"), which can be executed by processor 2 of the 10. The safety monitor 40 controls the switching 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 operating system of the electronic operating system 10. 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 only one of the two mentio environments The operation of the security monitor 40 meets the same security requirements as the trusted operating system 30 and therefore it is generally considered that the security monitor 40 is part of the operating environment of the security system. TEE, as shown in FIG. 2. According to one conceivable embodiment, the operating system executed before failover (for example the versatile operating system 20) is put on standby by the switchover and any access to external elements. the processor (for example the man-machine interface comprising in particular a keyboard and / or a screen and / or another input-output module) is then inhibited for the idle operating system, so that the system of operation activated by the failover (here the trusted operating system 30) completely controls the external element, here the man-machine interface. The security monitor 40 may also allow, during the switchover, the passage of information from the operating system executed before failover to the operating system executed after failover, as illustrated in the example of a process for loading files in RAM. presented later. In the example described here, the versatile operating system 20 and the trusted operating system 30 are executed by the processor 2 of the electronic apparatus 10. Alternatively, an electronic apparatus comprising two processors could be used. The multi-purpose operating system 20 is run on one and the trusted operating system 30 is running on the other.
    [0009] FIG. 3 represents the sharing of the random access memory 4 in three zones Z1, Z2, Z3 used in the context of the present invention. A first zone Z1 of the RAM 4 is accessible for reading and writing by the trusted operating system 30 only. The versatile operating system 20, and hence the applications executed in the versatile environment REE, do not have access to the first zone Z1. For example, it is provided that the first zone Z1 is accessible by the trusted operating system 30 to addresses included in a first range P1 of addresses, here addresses whose high byte is between h00 and hOF ( the notation hxy meaning that the number xy is expressed in hexadecimal notation). These addresses correspond, for example, to the physical addresses in the RAM 4. A second zone Z2 of the RAM 4 is a shared zone used by both the trusted operating system 30 and the polyvalent operating system 20. Precisely, the second zone Z2 is accessible in read and write by the trusted operating system 30; the second zone Z2 is however accessible read-only by the versatile operating system 20. The versatile operating system 20, and thus the applications executed in the versatile environment REE, can not write in the second zone Z2.
    [0010] For example, it is provided that the second zone Z2 is accessible by the trusted operating system 30 to addresses in a second range P2 of addresses, here addresses whose high byte is between hl 0 and hl. F. These addresses correspond for example to the physical addresses in the random access memory 4. The second zone Z2 is however accessible (in read only) from the polyvalent operating system 20 by means of addresses included in a third range P3 d. addresses, distinct from the second range P2 of addresses, here addresses whose byte of high weight is between h20 and h2F.
    [0011] A third zone Z3 of the RAM 4 is provided for use by the versatile operating system 20 (and applications executed in the versatile REE environment). This third zone Z3 is thus accessible in reading and writing by the polyvalent operating system 20 and, through it, by the applications executed in the versatile environment REE.
    [0012] Although the use of the third zone Z3 by the trusted operating system 30 is not provided for in normal operation, it can be provided that the trusted operating system 30 has the possibility of accessing the third zone Z3 in reading and / or writing. Restrictions on applications running in the TEE trust environment (for example, in terms of certification) make it possible to guarantee that access to the third zone Z3 from the TEE trust environment will be limited to exceptional cases, for example when the entire RAM 4 must be reset for a security reason. Thus, the trusted operating system 30 may for example read data related to the user (name, interface information, etc.) in the third zone Z3. The writing of data in the third zone Z3 will for its part be limited to specific cases (for example to particular commands and / or to particular operating states of the trusted operating system 30). For example, it is provided that the third zone Z3 is accessible by the multipurpose operating system 20 to addresses within a fourth address range P4 different from the third address range P4; the fourth address range P4 corresponds here to the addresses whose most significant byte is between h00 and hl F. In the cases where the third zone Z3 is accessible from the trusted operating system 30, the accesses can be made by means of addresses comprised in a fifth range P5 of addresses, distinct from the first and second ranges Pi, P2 of addresses, here addresses whose byte of high weight is between h20 and h3F. These last addresses correspond for example to the physical addresses in the RAM 4.
    [0013] Note that the second and third zones Z2, Z3 are accessible by the versatile operating system 20 (and therefore for applications executed in the versatile environment REE) to (virtual) addresses distinct from the physical addresses in the RAM 4 , for example through the use of aliases, which makes it possible to partition the RAM 4 between the different zones Z1, Z2, Z3 and to prevent any access in the first zone Z1 by applications executed in the multipurpose environment REE, while allowing such applications to read only access to the second zone Z2.
    [0014] FIG. 4a represents functional tables stored in the electronic device 10, for example in the rewritable non-volatile memory 6. A first table Ti stores, for each application APPL1, APPL2, APPL3 installed in the execution environment versatile REE, a data representative of the frequency of use of the application concerned. This data representative of the frequency of use is for example the number of uses of the application over a given period, here a period of one week. As a variant, the number of uses could be counted over a period of time of variable duration, defined for example by means of a criterion distinct from the time criterion, such as a criterion related to a charge or discharge cycle of a battery equipping the electronic device. The various applications APPL1, APPL2, APPL3 installed can thus be classified by decreasing frequency of use, for example within the first table Ti as represented in FIG. 4a.
    [0015] Alternatively, one could use multidimensional tables (for example three-dimensional as shown in Figure 4b) to store usage statistics according to several criteria. For example, for each APPLi application, for example, as shown in FIG. 4b, a usage statistic S (for example a usage frequency) is memorized as a function of the time T (time and day of the week for example) and the location L In this case, the different applications APPLi can be classified by decreasing frequency of use by using the statistics relating to the moment T in the week corresponding to the current moment and to the place L corresponding to the current place.
    [0016] A second table T2 stores, for each application APPL1, APPL2, APPL3 installed in the versatile execution environment REE, the various resources (or files) used by the application concerned during its execution; these resources are for example libraries of functions LIB1, LIB2, LIB3 or sets (or files) of data DAT1, DAT2, DAT4, DAT6. The applications installed on the electronic apparatus 10 (for use in the versatile REE execution environment with regard to the applications APPL1, APPL2, APPL3 mentioned above), as well as the resources they use (here the functions LIB1, LIB2, LIB3 and the data DAT1, DAT2, DAT4, DAT6) are stored in rewritable non-volatile memory 6 (for example following their download from a remote computer, such as a service distributor server, thanks to unrepresented telecommunication means of the electronic apparatus 10).
    [0017] The applications that must be executed by the processor 2 (as well as possibly at least some of the resources that the application can use) are however loaded into RAM 4, after the application has been selected by the user, or beforehand as explained below to make the launch of the application faster.
    [0018] FIG. 5 represents an example of a process for loading files in RAM 4 when the electronic device 10 is started. This method starts with a step E0 of initialization of the electronic device 10 following its start (for example from powered by the user). After this initialization step E0, all the bytes of the random access memory 4 generally have a predetermined value (for example h00 or hFF), because of the physical design of the RAM 4 or of a reset sub-step. forcing included in the initialization step E0. The initialization step E0 comprises other substeps necessary for the initialization of the operation of the electronic device 10, for example the loading, from the non-volatile rewritable memory 6 to the random access memory 4, of the electronic memory system. trusted operation 30 and the launch of its execution. The initialization step E0 is followed by a step E2 during which the trusted operating system 30 controls the loading, in the first zone Z1 of the random access memory 4, of files (applications and resources used by the this includes libraries and data) used in the context of the TEE trust execution environment. In the embodiment described here, the files are loaded (i.e., copied) into the first zone Z1 from the non-volatile rewritable memory 6 (where they were previously installed as already indicated). The correct storage of the files in the first zone Z1 is possibly verified by the trusted operating system 30, for example by waiting for a good functioning indicator from the RAM 4 (possibly accompanied by a checksum data written in memory) and / or read data written for comparison with the data to be written. The applications loaded in the first zone Z1 during the step E2 are, for example, applications that implement basic functionalities (such as those relating to the safe operation of the electronic apparatus 10) or applications frequently used during the operation of the electronic apparatus 10 as part of the TEE trust execution environment. The method continues in step E4 at which the trusted operating system 30 issues a REQ request to the versatile operating system 20 to obtain a list of requirements and hands over to the versatile operating system 20. As already indicated, the transmission of information (here the REQ request) and the switching of the trusted operating system 30 to the multi-purpose operating system 20 are for example carried out by means of the security monitor 40.
    [0019] The multipurpose operating system 20 is thus executed by the processor 2 in the step E6 (for example after being loaded into the RAM 4 by the security monitor 40) and receives the REQ request issued by the operating system. confidence in step E4. The multipurpose operating system 20 then prepares in step E7 the list of requirements L1 requested, which indicates as explained below the files (applications and resources used by these applications, including libraries and data) whose use as part of the versatile REE runtime environment is predictable. To do this, the versatile operating system 20 consults for example the first table Ti to determine the most frequently used application (here the application APPL2), then consults the second table T2 to determine the resources used by this application (here libraries LIB1, LIB3 and data file DAT1).
    [0020] References to the files thus determined (namely the most frequently used application APPL2 and resources LIB1, LIB3, DAT1 used by this application) are then added to the list of needs L1. This process may possibly be repeated for other applications, for example in descending order of frequency of use, until the memory size corresponding to the files listed in the list of needs L1 reaches a predefined threshold (for example equal to the size of the second zone Z2 of RAM 4) or, alternatively, for all applications installed for use in the versatile REE runtime environment. In the case of FIG. 6, a reference to the application APPL3 and the resources LIB2, DAT2 is thus added to the list of needs L1. (Note that we do not add again in the list of needs L1 a reference to a file already mentioned in the list of needs L1, here the library LIB3.) In the case where no statistics of use n ' is available (as for example during the first commissioning of the electronic device 10), the versatile operating system 20 uses for example as a list of needs L1 a default list (stored for this purpose in memory no -volatile rewritable 6). The versatile operating system 20 issues the L1 requirement list to the trusted operating system 30 in step E8. As already indicated above, this transfer of information is here managed by the security monitor 40 and is accompanied by the switchover from the operation of the electronic device of the versatile execution environment REE to the trusted execution environment. TEE.
    [0021] The execution of the trusted operating system 30 therefore resumes in step E10, with reception of the list of needs L1. The trusted operating system 30 then determines in step El 1, for each file referenced in the list of requirements L 1, if this file is compatible with a loading in the shared memory zone (or second zone) Z 2, in checking the compliance of the file with certain criteria, here at least one of the following criteria: - the file is likely to be used in the TEE trust execution environment (which is the case when the file is certified and / or has been installed - that is, loaded into rewritable non-volatile memory 6 - by the trusted operating system 30); - the use of this (same) file on the one hand while operating in the TEE trusted environment and on the other hand when operating in the versatile REE runtime environment is allowed (some files can be specified as reserved for use in the TEE trusted execution environment and therefore prohibited from use in the versatile REE runtime environment, eg files requiring a high level of security). In practice, the trusted operating system 30 determines for example whether a file is compatible with a loading in the shared memory zone Z2 by means of a flag (or binary indication) contained in a dedicated location of the file concerned, such as as the flags provided in the legal systems used by some operating systems. In the example described here with reference to FIG. 6, the application APPL2 is an application installed during the operation of the electronic device 10 in the versatile REE execution environment, without certification, and the library LIB2 is a library cryptographic functions (for example encryption, decryption and / or electronic signature) which are not desired to be used either in the context of the TEE trust execution environment and sometimes in the context of the Versatile execution environment REE. In general, such a library requiring a high level of security is certified and its implementation involves a check of its integrity. The trusted operating system 30 therefore determines in this example in step El 1 that the following files can be loaded in the second zone Z2 of RAM 4: LIB1, LIB3, DAT1, APPL3, DAT2. The trusted operating system 30 calculates in step E12 a global checksum relating to these files to be loaded in the second zone Z2.
    [0022] The trusted operating system 30 can then proceed to step E13 when loading, in the second zone Z2, the files determined in step E1 (here the files LIB1, LIB3, DAT1, APPL3, DAT2). These files are here loaded from the rewritable non-volatile memory 6 (that is to say, copied from the non-volatile rewritable memory 6 to the second zone Z2 of the RAM 4 under the control of the operating system trusted 30). The correct storage of the files in the second zone Z2 is possibly verified by the trusted operating system 30, for example by waiting for a good functioning indicator from the RAM 4 (possibly accompanied by a verification of the checksum of the data written in memory, calculated as indicated above in step E12) and / or reading the data written for comparison with the data to be written. Alternatively, instead of using a global checksum for all files to load as proposed above, we can use a checksum file to load. It can furthermore be provided that the trusted operating system 30 releases, in the first zone Z1, memory spaces in which, in step E2, files have been loaded, a copy of which has been loaded in the second zone Z2 to the second zone Z1. step E13. During operation in the trusted execution environment TEE, these files can indeed be consulted or executed by reading in the second zone Z2 and it is therefore unnecessary to keep a copy in the first zone Zl. The trusted operating system 30 then proceeds to step E14 in the preparation of a partition list L2 which comprises for example for each file loaded in the second zone Z2, as represented in FIG. 6: a designation DES of the file concerned; the address (here virtual) ADR for storing the file concerned, as used by the versatile operating system 20 to access the file (ie an address in the third range P3 of addresses); INT information for checking the integrity of the file concerned, for example in the form of a cyclic redundancy check code (or CRC for "cyclic redundancy check"); a CERT certificate generated for the file concerned by the trusted operating system 30 (in order later to allow the polyvalent operating system 20 to verify that the trusted operating system 30 is indeed at the origin of the loading of the concerned file in the second zone Z2). In the example described here, the verification information INT is obtained as indicated above by applying a cyclic redundancy check algorithm to the memory areas where the file concerned is stored. One uses for example one of 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 (English "checksum") or an authentication code (or MAC, the English "Message Authentication Code"). The sharing list L2 may optionally furthermore contain, for each file loaded in the second zone Z2, the physical address for storing the file in the random access memory 4.
    [0023] The trusted operating system 30 transmits in step E16 the partition list L2 thus developed to the multipurpose operating system 20. As before, this transmission is here carried out via the safety monitor 40 with failover in the versatile execution environment REE.
    [0024] Alternatively, the sharing list L2 could be stored by the trusted operating system 30 in a predefined memory location accessible by the versatile operating system 20, for example in a predefined location of the second memory zone Z2. 4. In order to verify that the L2 sharing list is not corrupted when it is used, a cyclic redundancy code (or CRC) generated by the trusted operating system 30 and associated with the L2 sharing list. Due to the failover initiated in step E16, the multi-purpose operating system 20 is executed again in step E18 and stores the received L2 share list (or has access to the L2 share list at the predefined location in the variant just mentioned), with possible verification of the cyclic redundancy code associated with the L2 sharing list. In subsequent operation of the electronic apparatus 10, the versatile operating system 20 and the applications executed as part of the versatile REE runtime environment will thus be able to consult the L2 partition table and access the files stored in the second zone Z2 at the address ADR indicated in the partition table L2 for the file concerned, possibly checking the integrity of the file thanks to the INT information present in the L2 sharing table for the file concerned and / or the origin of the file thanks to the CERT certificate present in the L2 sharing table for the file concerned. Based on the L2 sharing list received (or searchable at the predefined location) and the L1 requirement list prepared in step E7, the multipurpose operating system 20 determines (by difference) in step E20 which files referenced in the list of needs L1 have not been loaded in the second zone Z2 (the files loaded in the second zone Z2 being designated in the sharing list L2). The files determined in step E20 as present in the list of needs L1 and absent from the sharing list L2 are then loaded in step E22 in the third zone Z3, that is to say, copied from the non memory. -volatile 15 rewritable 6 (where they were previously installed) to the third zone Z3 RAM 4 under the control of the multi-purpose operating system 20. The correct storage of files in the third zone Z3 is also possibly verified by the versatile operating system 20, for example by waiting for a functioning indicator from the RAM 4 (optionally accompanied by a checksum of the data written in memory) and / or reading the written data for comparison with the data to be written. The loading of the files in the different zones Z1, Z2, Z3 of the random access memory 4 is thus completed and the normal operation can therefore begin at the step E24, for example by waiting for a command from the user at the level of the man-machine interface (not shown) of the electronic apparatus 10. Normal operation continues until a new application is installed as part of the operation in the versatile REE runtime environment.
    [0025] The versatile operating system 20 then prepares an updated requirement list L1 'and transmits this list of requirements to the trusted operating system 30 in step E26. The trusted operating system 30 receives the list of updated needs L1 'and determines (as in step E10) the new files to be loaded in the second zone Z2, as well as possibly the files to be deleted from the second zone Z2 to free memory space for new files. For example, a FIFO (First In, First Out) memory page management method, or LRU (from Least Recently Used, or LFU), is used in this context. English "Least Frequently Used"), or random priority (or "Random Priority"). The trusted operating system 30 then calculates a cyclic redundancy code relating to the new files to be loaded in the second zone Z2 and command writing the new files in the second zone Z2 (step E30) The trusted operating system 30 then updates in step E32 the sharing list L2 (to take account of the new files loaded in the second zone Z2) .The method then proceeds to step E16 described below for switching to the REE multi-purpose execution environment with sending of the sharing list (update) and loading in the zone Z3 of the files necessary for operation. of the new application and that have not been charged to the zone Z2. As a variant of steps E26 to E32 that have just been described, the method could loop in step E4 during the installation of a new application in the versatile REE execution environment in order to implement in full the method of loading files in zone Z2 as described above in steps E4 to E16.
    权利要求:
    Claims (14)
    [0001]
    REVENDICATIONS1. A method of loading a RAM file (4) into an electronic apparatus (10) adapted to operate in a trusted execution environment (TEE), due to the execution of a trusted operating system (30) ) by a processor (2) of the electronic apparatus (10), or in a multipurpose execution environment (REE), characterized in that it comprises the following steps: - reception (E10), by the system of trusted operation (30), information (L1) identifying at least one file; checking (El 1), by the trusted operating system (30), of the conformity of the identified file with at least one given criterion; - In case of compliance, loading (E13) of the identified file into a zone (Z2) RAM (4) accessible read-only when operating in the versatile execution environment (REE).
    [0002]
    2. Loading method according to claim 1, wherein the information identifying the file is contained in a requirements document (L1) prepared during operation in the versatile execution environment (REE).
    [0003]
    3. Loading method according to claim 2, wherein the requirements document (L1) is constructed (E7) based on data (Ti) representative of the usage frequencies of the applications installed in the multipurpose execution environment (REE). ).
    [0004]
    4. Loading method according to claim 2 or 3, wherein the requirements document (L1) is constructed (E7) according to usage statistics relating to several criteria.
    [0005]
    5. Loading method according to one of claims 2 to 4, comprising the following steps, executed in the versatile execution environment (REE) for each file mentioned in the requirements document (L1): - determination if the file mentioned is loaded into said zone (Z2) of random access memory (4) read-only; if not, loading the concerned file into another zone (Z3) of random access memory (4) which is writable during operation in the multipurpose execution environment (REE).
    [0006]
    6. Loading method according to one of claims 1 to 5, comprising a step of construction (E14), by the trusted operating system (30), a sharing list (L2) including a designation (DES ) of the loaded file and an address (ADR) for storing the loaded file.
    [0007]
    The loading method of claim 6, wherein the sharing list (L2) includes integrity verification information (INT) associated with the loaded file.
    [0008]
    8. Loading method according to claim 6 or 7, wherein the sharing list (L2) includes a certificate (CERT) generated by the trusted operating system (30) and relating to the loaded file.
    [0009]
    9. Loading method according to one of claims 6 to 8, wherein the sharing list (L2) is stored in said zone (Z2) of random access memory (4) read-only when operating in the environment d Versatile Performance (REE).
    [0010]
    10. Loading method according to one of claims 1 to 9, wherein said loading is performed from a non-volatile memory (6).
    [0011]
    The charging method according to one of claims 1 to 10, wherein said zone (Z2) is read-only when operating in the multipurpose execution environment (REE) by means of virtual addresses pointing to separate physical addresses of the virtual addresses concerned.
    [0012]
    12. Loading method according to one of claims 1 to 11, wherein the information (L1) identifying the file are received during a switch from the versatile execution environment (REE) to the runtime environment trusted (TEE).
    [0013]
    13. Loading method according to one of claims 1 to 12, further comprising the following steps: - following an installation of a new application in the versatile execution environment (REE), transmission (E26) to the system trusted operating system (30) of an updated requirements document (L1 '); - loading (E30), in the zone (Z2) of random access memory (4) accessible in read-only mode during operation in the multipurpose execution environment (REE), of a new file designated in the requirements document set to day (L1 ').
    [0014]
    An electronic apparatus (10) comprising at least a processor (2) and a random access memory (4), and adapted to operate in a trusted execution environment (TEE), due to the execution of a computer system. trusted operation (30) by the processor (2), or in a versatile execution environment (REE), characterized in that the trusted operating system (30) is adapted to receive information (L1) identifying the least one file, to check the conformity of the identified file with at least one given criterion and to load, in case of conformity, the identified file into a zone (Z2) of the random access memory (4) accessible in read-only mode during operation in Versatile Execution Environment (REE) .10
    类似技术:
    公开号 | 公开日 | 专利标题
    JP2021509189A|2021-03-18|Blockchain-based transaction processing methods and equipment
    EP3018609B1|2019-01-02|Method for loading a file into ram in an electronic apparatus and associated electronic apparatus
    US20190176038A1|2019-06-13|Application state backup and restoration across multiple devices
    EP1688818A1|2006-08-09|Process for the secure management of the execution of an application
    US20090113558A1|2009-04-30|Progressive boot for a wireless device
    US20170177694A1|2017-06-22|System and method for maintaining device state coherency
    EP3108361A2|2016-12-28|Method of deploying a set of software application|
    EP3654618A1|2020-05-20|Audio broadcasting method, device, and system, and smart broadcasting apparatus
    EP2735969A1|2014-05-28|Electronic assembly including a deactivation module
    FR2901038A1|2007-11-16|METHOD AND DEVICE FOR SECURELY CONFIGURING A TERMINAL USING A STARTING DATA STORAGE DEVICE
    WO2015063405A1|2015-05-07|Intrusion detection system in a device comprising a first operating system and a second operating system
    CN109964227B|2021-08-13|Method and terminal for updating SELinux security policy
    CN106547628B|2020-05-01|Multi-system resource release method and device
    FR2906380A1|2008-03-28|SYSTEM AND METHOD FOR SECURING DATA.
    US9729698B2|2017-08-08|Increasing user memory space on end-of-life mobile user devices
    KR102376229B1|2022-03-18|Method of loading files into random access memory in an electronic device and associated electronic device
    FR3071630A1|2019-03-29|METHOD FOR MANAGING ONBOARD SOFTWARE MODULES FOR AN ELECTRONIC COMPUTER OF AN ELECTRICAL CUTTING APPARATUS
    EP3080706B1|2018-12-05|Method of backup of data stored in a terminal
    FR3028071A1|2016-05-06|ELECTRONIC APPARATUS AND METHOD IMPLEMENTED IN SUCH AN ELECTRONIC APPARATUS
    FR3079044A1|2019-09-20|SECURE DATA PROCESSING
    CN113886180A|2022-01-04|Control method and electronic device
    FR3083344A1|2020-01-03|REMOVABLE DATA STORAGE MEDIUM
    FR3078469A1|2019-08-30|CONFIGURING AN INBOARD SUBSCRIBER IDENTITY MODULE
    CN113835642A|2021-12-24|Distributed storage network construction method based on IPFS and distributed storage network
    Fowler2011|An Overview of Small Scale Digital Forensics
    同族专利:
    公开号 | 公开日
    CN105574414A|2016-05-11|
    ES2718322T3|2019-07-01|
    US20160125186A1|2016-05-05|
    EP3018609B1|2019-01-02|
    EP3018609A1|2016-05-11|
    FR3028069B1|2016-12-09|
    CN105574414B|2020-11-10|
    US10037426B2|2018-07-31|
    KR20160053814A|2016-05-13|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US7299292B2|2002-03-29|2007-11-20|Widevine Technologies, Inc.|Process and streaming server for encrypting a data stream to a virtual smart card client system|
    US7921303B2|2005-11-18|2011-04-05|Qualcomm Incorporated|Mobile security system and method|
    EP2126694A2|2006-12-22|2009-12-02|VirtualLogix SA|System for enabling multiple execution environments to share a device|
    US20120110575A1|2010-10-29|2012-05-03|Unisys Corp.|Secure partitioning with shared input/output|
    US9413538B2|2011-12-12|2016-08-09|Microsoft Technology Licensing, Llc|Cryptographic certification of secure hosted execution environments|
    WO2013174503A1|2012-05-21|2013-11-28|Eth Zurich|Secure loader|
    CN102722665B|2012-05-22|2015-04-29|中国科学院计算技术研究所|Method and system for generating trusted program list based on trusted platform module /virtual trusted platform module |
    US20140250290A1|2013-03-01|2014-09-04|St-Ericsson Sa|Method for Software Anti-Rollback Recovery|US10430706B2|2016-12-01|2019-10-01|Via Alliance Semiconductor Co., Ltd.|Processor with memory array operable as either last level cache slice or neural network unit memory|
    CN106875562B|2017-03-02|2021-09-10|钟晓华|File network authentication device|
    WO2018162040A1|2017-03-07|2018-09-13|Huawei Technologies Co., Ltd.|Hypervisor measurement agent|
    CN110555293A|2019-09-10|2019-12-10|百度在线网络技术（北京）有限公司|Method, apparatus, electronic device and computer readable medium for protecting data|
    法律状态:
    2015-11-23| PLFP| Fee payment|Year of fee payment: 2 |
    2016-05-06| PLSC| Publication of the preliminary search report|Effective date: 20160506 |
    2016-10-24| PLFP| Fee payment|Year of fee payment: 3 |
    2017-10-20| PLFP| Fee payment|Year of fee payment: 4 |
    2018-10-24| PLFP| Fee payment|Year of fee payment: 5 |
    2019-10-22| PLFP| Fee payment|Year of fee payment: 6 |
    2020-10-02| CA| Change of address|Effective date: 20200826 |
    2020-10-02| CJ| Change in legal form|Effective date: 20200826 |
    2020-10-21| PLFP| Fee payment|Year of fee payment: 7 |
    2021-10-20| PLFP| Fee payment|Year of fee payment: 8 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1460679A|FR3028069B1|2014-11-05|2014-11-05|METHOD FOR LOADING SAFE MEMORY FILE IN AN ELECTRONIC APPARATUS AND ASSOCIATED ELECTRONIC APPARATUS|FR1460679A| FR3028069B1|2014-11-05|2014-11-05|METHOD FOR LOADING SAFE MEMORY FILE IN AN ELECTRONIC APPARATUS AND ASSOCIATED ELECTRONIC APPARATUS|
    EP15192654.0A| EP3018609B1|2014-11-05|2015-11-02|Method for loading a file into ram in an electronic apparatus and associated electronic apparatus|
    ES15192654T| ES2718322T3|2014-11-05|2015-11-02|File upload procedure in random access memory in an electronic device and associated electronic device|
    US14/932,347| US10037426B2|2014-11-05|2015-11-04|Method of loading files into random access memory in an electronic device and associated electronic device|
    KR1020150154362A| KR102376229B1|2014-11-05|2015-11-04|Method of loading files into random access memory in an electronic device and associated electronic device|
    CN201510740529.1A| CN105574414B|2014-11-05|2015-11-04|Method of loading a file into a random access memory in an electronic device and associated electronic device|
    [返回顶部]