SYSTEM-ON-CHIP AND METHOD FOR ENSURING THE FRESHNESS OF DATA STORED IN AN EXTERNAL MEMORY

Description

Domaine technique

[0001] The invention relates to the field of security, in particular to systems on a chip with a secure element, part of the data of which is stored in a memory external to the system on a chip. The invention relates, in particular, to a system on a chip and methods guaranteeing the freshness of the data stored in this external memory. Etat de la technique

[0002] In systems on chip or SOC (for System On Chip in Anglo-Saxon terminology) including a secure integrated element, the data manipulated by the secure operating system is generally stored in a memory external to the system on chip, for cost reasons.

[0003] Thus, for example, the secure element comprises a processing unit, a volatile memory as well as a small non-volatile memory, typically having low endurance, such as an OTP memory (for One Time Programmable in Anglo-Saxon terminology) or MTP (for Multi Time Programmable in Anglo-Saxon terminology), while external memory is typically a rewritable non-volatile memory with much better endurance. This is for example Flash memory.

[0004] One difficulty is that memory external to the secure element and the SOC can be shared with applications other than those of the secure element or the SOC. In addition, it can be manipulated independently of the secure element or the SOC, which therefore cannot control the use of the data it contains.

[0005] For example, data from external memory can be retrieved for later reuse for fraudulent purposes. Such an attack, which involves changing the current value of a data item by reusing an old value, is known as a rollback. It is all the more difficult to detect in the absence of a connection allowing the 'freshness' of the value used to be checked from a remote server, as for example described in document US 2017 / 0124353 A1.

[0006] The Esegura document: "How do you avoid adding timestamp fields to your tables? [closed]", October 6, 2008, XP055709327, discloses the addition to a database table of a table containing timestamp information associated with that data.

[0007] For example, such an attack could allow a user to access a paid service after their subscription has expired. Another example of this type of attack could allow a user to reset their digital wallet to its maximum value after emptying it.

[0008] There is therefore a need for a local means, i.e. one that does not require connection to a remote server, to check the freshness of the data in such memory external to the SOC, in order to avoid attacks by rollback. Exposé de l'invention

[0009] The present invention thus aims to overcome at least one of these drawbacks.

[0010] In this context, a first aspect of the invention relates to a system-on-chip comprising a secure element comprising a processing unit configured to execute a secure operating system and to send instructions to a rewritable non-volatile memory external to the system-on-chip and connected thereto, the secure element further comprising a secure non-volatile memory as well as a secure volatile memory, the system-on-chip being characterized in that the processing unit is configured to control: storing, in the external rewritable non-volatile memory, at least one object having a current version, and a dedicated directory associating an identifier of each object with an identifier of the current version of this object, the dedicated directory further comprising an identifier of its own current version; and storing, in the non-volatile memory of the secure element, the identifier of the current version of the dedicated directory.

[0011] Correlatively, a second aspect of the invention relates to a method for securely writing an object in a rewritable non-volatile memory external to a system on chip and connected thereto, the system on chip comprising a secure element comprising a processing unit configured to execute a secure operating system and to send instructions to the external rewritable non-volatile memory, the secure element further comprising a secure non-volatile memory as well as a secure volatile memory, the method being characterized in that it comprises the following steps: command to write an identifier of the current version of the object in a dedicated directory stored in the external rewritable non-volatile memory, in association with an identifier of the object, command to update an identifier of the current version of the dedicated directory in the dedicated directory stored in the external rewritable non-volatile memory, command to write the identifier of the current version of the dedicated directory in the secure non-volatile memory of the secure element.

[0012] The invention thus claimed makes it possible to ensure the "freshness" of the data stored in the memory external to the SOC and connected to it, that is to say to ensure that this data corresponds to the version expected at the time considered.

[0013] Indeed, by attaching a current version to each object, and by recording an identifier of this version in a dedicated directory also having a version whose identifier is recorded in the secure non-volatile memory of the secure element, an attack consisting of replacing the data of the object in the external memory by an old version would be immediately detected.

[0014] The overall security of the system-on-chip is therefore improved, without requiring any hardware modification of the system-on-chip. The benefit of using external memory with better endurance than the non-volatile memory of the secure element is therefore retained.

[0015] Furthermore, the version replication system used in the claimed invention allows to differentiate an object that is not up to date due to a simple power outage (called « tearing » in Anglo-Saxon terminology) during the writing (updating) of its data compared to an attack aimed at writing old data.

[0016] Further features of the system-on-chip and method according to embodiments of the invention are described in the dependent claims.

[0017] In embodiments, the processing unit is configured to control writing, in an area of type " rollforward » in external rewritable non-volatile memory, data to be used to update an object.

[0018] In embodiments, the processing unit is configured to control the creation of a copy of at least a portion of the contents of the external rewritable non-volatile memory in the secure volatile memory of the secure element.

[0019] In embodiments, the processing unit is configured to control the modification of said copy in the secure volatile memory of the secure element before the modification of the external rewritable non-volatile memory.

[0020] In embodiments, the processing unit is configured to control: reproduction of the modifications made to the copy of the dedicated directory and the zone of type " rollforward » in secure volatile memory on the dedicated directory and the area of type " rollforward » stored in the external rewritable non-volatile memory, then modifying the relevant object(s) stored in the external rewritable non-volatile memory in accordance with the contents of the area of type “ rollforward » and the dedicated directory.

[0021] In embodiments, the processing unit is configured to command the updating of the identifier of the current version of the dedicated directory in the secure non-volatile memory of the secure element before the modification of the object(s) concerned stored in the external rewritable non-volatile memory in accordance with the content of the zone of type " rollforward » and the dedicated directory.

[0022] In embodiments, the processing unit is configured to control the reproduction of modifications in external rewritable non-volatile memory, after several copies of objects have been modified in the secure volatile memory of the secure element.

[0023] In embodiments, the secure non-volatile memory of the secure element is a limited-life memory of the OTP or MTP type.

[0024] In embodiments, the identifier of the current version of an object and / or the identifier of the current version of the dedicated directory is a version number.

[0025] In embodiments, the identifier of the current version of an object and / or the identifier of the current version of the dedicated directory is a checksum (checksum in Anglo-Saxon terminology) calculated from the object and / or the dedicated directory, uniquely identifying its version.

[0026] In embodiments, the identifier of the current version of an object and / or the identifier of the current version of the dedicated directory is a signature of the object and / or the dedicated directory uniquely identifying its version.

[0027] In embodiments, the processing unit implements a first comparison function and a second comparison function in order to determine whether a version identifier corresponds to a current version or to an old version, the first function consisting of determining whether the values are identical, the second function consisting of determining whether said version is strictly greater or strictly less than the current version.

[0028] For example, the first function is to determine whether the values of the version of the copy of the directory in secure volatile memory and that of the current version of the directory stored in the secure non-volatile OTP / MTP memory of the secure element are identical. The second function is to determine whether the version of the copy of the directory in secure volatile memory is strictly greater than or strictly less than the current version of the directory stored in the secure non-volatile OTP / MTP memory of the secure element.

[0029] In embodiments, the processing unit is configured to operate in either an unsecured execution mode or a secure execution mode.

[0030] In embodiments, the processing unit is configured to control a memory controller controlling the external rewritable non-volatile memory. This controller may be on the SOC or external thereto.

[0031] In embodiments, the method comprises a step of verifying the freshness of an object stored in the external rewritable non-volatile memory, comprising: creating a copy of the dedicated directory and the object in the secure volatile memory of the secure element, comparing the identifier of the current version of the dedicated directory stored in the copy (in secure volatile memory) of the dedicated directory, with the identifier of the current version of the dedicated directory stored in the secure non-volatile memory of the secure element; in case of equality, comparing the identifier of the current version of the copy (in secure volatile memory) of the object with the identifier of the version of this object stored in the copy (in secure volatile memory) of the dedicated directory, in order to verify the freshness of the object.

[0032] In embodiments, in the event of version equality between the identifier of the current version of the dedicated directory stored in the copy (in secure volatile memory) of the dedicated directory and the identifier of the current version of the dedicated directory stored in the secure non-volatile memory of the secure element, but of difference between the versions of the object indicated in the object itself and in the dedicated directory, the method comprises a step of updating the version and / or the content of said object.

[0033] In embodiments, this method is implemented at startup of the processing unit of the secure element.

[0034] In embodiments, the method further comprises a step of writing, in an area of type " rollforward » in external rewritable non-volatile memory, data to be used to update an object.

[0035] In embodiments, the processing unit implements a first comparison function and a second comparison function in order to determine whether a version identifier corresponds to a current version or to an old version, the first function consisting of determining whether the values are identical, the second function consisting of determining whether said version is strictly greater or strictly less than the current version.

[0036] For example, the first function is to determine whether the values of the version of the copy of the directory in secure volatile memory and that of the current version of the directory stored in the secure non-volatile OTP / MTP memory of the secure element are identical. The second function is to determine whether the version of the copy of the directory in secure volatile memory is strictly greater than or strictly less than the current version of the directory stored in the secure non-volatile OTP / MTP memory of the secure element.

[0037] The advantages, goals and special characteristics of the methods are similar to those of the system-on-chip that implements them.

[0038] In a particular embodiment, the different steps of the aforementioned methods are determined by computer program instructions.

[0039] Consequently, the invention also relates to computer programs on an information medium, these programs being capable of being implemented by a microprocessor, these programs comprising instructions adapted to the implementation of the steps of the methods as mentioned above.

[0040] These programs may use any programming language, and may be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0041] The invention also relates to an information medium readable by a microprocessor, and comprising computer program instructions as mentioned above.

[0042] The information carrier may be any entity or device capable of storing the program. For example, the carrier may include a storage medium, such as a ROM, for example a microcircuit ROM, or a magnetic recording medium, for example a hard disk, or a flash memory.

[0043] On the other hand, the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention may in particular be downloaded onto a storage platform of an Internet-type network.

[0044] Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to carry out or to be used in carrying out the method in question.

[0045] The aforementioned information medium and computer programs have characteristics and advantages similar to the methods they implement. Brève description des dessins

[0046] Other features and advantages of the invention will appear in the description below, illustrated by the attached figures which illustrate exemplary embodiments which are not limiting in nature. [ Fig. 1 ] There figure 1 represents an exemplary architecture for a system-on-chip according to embodiments of the invention. Fig. 2 ] There figure 2 represents, in flowchart form, steps implemented by the system-on-chip to verify the freshness of an object in accordance with embodiments of the invention. Fig. 3 ] There figure 3 which includes the figures 3A, 3B , 3C, 3D And 3E, schematically illustrates the successive state of the different memories considered during an implementation of the stages of the figure 2 . [ Fig. 4 ] There figure 4 represents, in flowchart form, steps implemented by the system-on-chip during a secure write in accordance with embodiments of the invention. Fig. 5 ] There figure 5 which includes the figures 5A à 5M , schematically illustrates the successive state of the different memories considered during the implementation of the stages of the figure 4 . Subsequently, the same references are used to designate the same elements when they appear in different figures. Description détaillée

[0047] La figure 1 represents an exemplary architecture for a system on chip ('SOC' hereinafter) according to embodiments of the invention.

[0048] According to embodiments, the SOC 10 is configured to be connected to an external rewritable non-volatile memory NVM 12. Hereinafter, the word 'connected' means 'locally connected' as opposed to a remote connection with a server. This local connection is typically implemented using a bus 14.

[0049] The rewritable non-volatile memory NVM 12 is typically a Flash memory, or any other memory having good endurance. This memory may constitute a medium within the meaning of the invention, that is to say it may comprise a computer program comprising instructions for implementing a method according to the invention. The program is then loaded into RAM memory 1026 at boot of the SOC 10.

[0050] In this example, the SOC 10 comprises a first processing unit or microprocessor 101 denoted CPU1 (for Central Processing Unit in English terminology) and a secure element 102. The first processing unit (CPU1) 101 and the secure element 102 communicate for example via a communication interface 103, for example comprising a DMA module (for Direct Memory Access in Anglo-Saxon terminology) or a mailbox (not shown).

[0051] The secure element 102 comprises the following elements, connected by a communication bus 1020: a processing unit - or microprocessor - 1022 denoted CPU2 implementing a secure operating system (OS). According to embodiments, this processing unit can operate in secure mode only or in several modes (secure or not). According to embodiments, this processing unit CPU2 is configured to send instructions to the CPU1 or to a memory controller (on the SOC or connected to it) controlling the NVM memory 12 in order to act on this memory 12; a non-volatile memory 1024 for example OTP or MTP; a random access memory or cache memory or volatile memory 1026 for example RAM (acronym for Random Access Memory in English terminology) comprising registers adapted to the recording of variables and parameters created and modified during the execution of the aforementioned program; during the implementation of the invention, the instruction codes of the program stored in non-volatile memory (eg NVM) are loaded into RAM memory in order to be executed by the processing unit CPU2; and a communication interface 103 adapted to transmit and receive data, for example with the rewritable non-volatile memory 12 via CPU1.

[0052] The communication bus enables communication and interoperability between the different elements included in the secure element or connected to it. The representation of the bus is not limiting and, in particular, the CPU2 processing unit is capable of communicating instructions to any element of the secure element directly or via another element of this secure element.

[0053] It is noted that in this example, the intelligence of the invention is located at the level of CPU2 which transmits its instructions to CPU1, which transfers to the NVM memory 12 via the bus 14. Indeed, CPU1 could be a simple memory controller.

[0054] According to a variant not shown, CPU1 could be replaced by a memory controller external to SOC 10, to which CPU2 would send its instructions / commands directly.

[0055] In general, the CPU2 OS uses objects as memory containers. An object is commonly referred to as a block of bits that includes a header and data (payload). The header usually indicates the size of the data, while the data contains information used either by an application running on the OS or by the OS itself. The OS can allocate objects dynamically (during runtime) or statically (when building the operating system image). It can use these objects for its own purposes, or for object-oriented applications using a virtual machine. The OS usually accesses the object by an address or an identifier that redirects to an address.

[0056] La figure 2 represents, in the form of a flowchart, steps implemented by the system on chip to verify the freshness of an object, for example when reading it, in accordance with embodiments of the invention. Typically, the steps described are implemented by the CPU2 processing unit 1022 of the secure element 102.

[0057] During a step E20, the processing unit CPU2 1022 of the secure element is started (boot in English terminology). It is noted that the SOC and the processing unit CPU2 1022 of the secure element generally have an independent power supply. However, the invention is not limited to this and in one embodiment, the SOC and the secure element share the same power supply.

[0058] In this example, the NVM memory 12 then includes at least one object having a current version, as well as a dedicated directory associating an identifier of each object with an identifier of the current version of this object. The dedicated directory further includes an identifier of its own current version.

[0059] Depending on the embodiments, the version identifier may be either a version number, a signature, or a checksum. (checksum in Anglo-Saxon terminology) allowing the version to be uniquely identified. For example, the signature can be calculated on the version number and the object data. Subsequently, for the sake of simplicity, we consider only the version number. However, the person skilled in the art will be able to transpose the following teachings to a signature or a checksum.

[0060] NVM 12 memory may also include an area of type " rollforward » used to ensure the atomicity and security of updating an object's data. To do this, the area rollforward includes the data to be used to update a given object. In other words, this area contains the latest (most recent) version of the data. This area makes it possible, for example, to restore the latest version of the data in an object in the event of a power outage and thus prevent corruption of an object.

[0061] In this example, the OTP / MTP memory 1024 also stores the identifier of the current version of the dedicated directory.

[0062] During a step E22, at least part of the content of the NVM memory 12, in particular at least the directory mentioned previously as well as the zone rollforward present in the same memory page, are copied into RAM memory 1026 of the secure element 102.

[0063] During a step E24, the identifier of the current version of the dedicated directory stored in the copy of the dedicated directory (i.e. in RAM memory 1026) is compared with the identifier of the current version of the dedicated directory stored in the secure non-volatile memory (OTP / MTP 1024) of the secure element. In the preferred hypothesis where the zone rollforward shares the same memory page as the dedicated directory, the version identifier also allows to check the validity of the contents of the zone rollforward. Indeed, the integrity of a memory page is guaranteed. This means that version checking allows you to test the "freshness" of all the contents of the memory page, i.e. to check whether the contents of the page correspond to the expected one. In the case where the area rollforward is not on the same memory page as the dedicated directory, the embodiment based on signatures or checksums (checksum) can be advantageously favored.

[0064] If it is determined in step E24 that the current version of the copy of the directory in RAM memory 1026 is strictly lower than the current version of the directory indicated in secure non-volatile memory (OTP / MTP 1024), this means that an attack by rollback took place.

[0065] If it is determined in step E24 that the current version of the copy of the directory in RAM memory 1026 is strictly greater than the current version of the directory indicated in secure non-volatile memory (OTP / MTP 1024), this means that there has been a power outage (“ tearing » in English terminology) during the update in external non-volatile memory 12. The method then continues with a step E26 called 'repair' of the secure non-volatile memory (OTP / MTP 1024) aimed at updating the value of the version of the directory in OTP / MTP memory so that it is identical to that of the copy of the directory in RAM memory 1026. Following this repair step E26 or if it is determined in step E24 that the current version of the copy of the directory in RAM memory 1026 is equal to the current version of the directory indicated in secure non-volatile memory (OTP / MTP 1024), the method continues with a step E27 during which an object referenced in the copy of the zone rollforward in RAM memory is in turn copied from NVM 12 memory into RAM memory (object reading). For simplicity, we subsequently consider that only one object is referenced in the area rollforward but this example is not limiting and this area could reference several objects.

[0066] During a step E28, the identifier of the current version of the copy of the object in RAM memory is compared with the identifier of the version of this object stored in the copy of the dedicated directory in RAM memory, in order to check the freshness of this object.

[0067] If the versions match, this means that the data in this object is fresh, i.e. has the expected value.

[0068] If these versions do not match, the version of the object (if necessary) as well as its contents in RAM memory 1026 are updated (step E29). The contents of the object in external non-volatile memory 12 are also updated. Once this update step is complete, the contents of the copy of the area rollforward in RAM memory 1026 is erased (step E30). Preferably, the above operations are performed at CPU startup 2. Copying the directory and the area rollforward will then be maintained in RAM memory 1026 for the duration of the execution.

[0069] In practice, when an object is subsequently read, if it is not already in RAM memory 1026, the corresponding object is copied from the external non-volatile memory 12 to the RAM memory 1026. The version of this object is compared to that of the copy of the directory in RAM memory 1026 in order to check the freshness of the object, in a similar manner to steps E27 and following.

[0070] La figure 3 schematically illustrates the successive state A, B, C, D, E of the different memories considered (RAM 1026, OTP / MTP 1024, NVM 12) during an implementation of the steps of the figure 2 , according to a particular example given for illustration purposes only.

[0071] In this example, when the CPU2 1022 is switched on (state A, step E20), the OTP memory 1024 contains the identifier of the current version of the dedicated directory, here 'v3'. The NVM memory 12 comprises two objects: 'Object 1' and 'Object 2'. Object 1 has a version v3 and contains W data. Object 2 has a version v2 and contains Y data. The NVM memory 12 also comprises a directory indicating the correspondence between objects 1 and 2 and their respective version, as well as its own version, also stored in the OTP memory 1024, namely 'v3'. The NVM memory 12 also comprises an area rollforward which includes the W and Y data of objects 1 and 2.

[0072] [ Fig.3A ] In this state A, corresponding to the boot of CPU 2, RAM 1026 is empty.

[0073] [ Fig.3B ] State B corresponds to the result of the implementation of step E22. Thus, after copying part of the contents of the NVM memory 12 into the RAM memory 1026, this RAM memory 1026 includes a copy of the directory mentioned above as well as a copy of the zone rollforward.

[0074] [ Fig.3C ] State C illustrates the comparison of the versions of the directory in RAM 1026 and OTP 1024 during step E24. In this example, the versions match.

[0075] [ Fig.3D ] State D illustrates the copy of object 1 into RAM 1026 during step E27, then the comparison of the versions of object 1 in the copy of object 1 and in the copy of the directory in RAM 1026 during step E28. In this example, the versions match.

[0076] [ Fig.3E ] State E illustrates the copy of object 2 into RAM 1026 during step E27, then the comparison of the versions of object 2 in the copy of object 2 and in the copy of the directory in RAM 1026 during step E28. In this example, the versions match.

[0077] The objects are therefore in line with what is expected in terms of version (freshness).

[0078] La figure 4 represents, in flowchart form, steps implemented by the system on chip during a secure write in accordance with embodiments of the invention.

[0079] The process shown in the figure 4 starts after a check of the "freshness" of the data (objects, directory) already present in NVM 12 memory when the CPU2 1022 is switched on. Typically, this check consists of implementing the steps described with reference to the figure 2 .

[0080] In this example, OTP / MTP memory 1024 stores a copy of the current version identifier of the dedicated directory.

[0081] Objects are preferably processed one after the other, that is, only one object is copied at a time into RAM, its version is checked and then, if necessary, it is updated.

[0082] If the number of objects to be checked for freshness is too large to keep a copy of all objects in RAM, at least some objects (not currently in use in an application) are removed from RAM to allow other objects to be checked.

[0083] During a step 405, if the object to which one wishes to write is not already present in RAM memory, a copy is made in RAM memory 1026. It is then verified that its version is indeed that corresponding to its entry in the copy of the directory in volatile memory 1026.

[0084] If this is the case, steps E410 to E418 are then implemented in the RAM memory 1026. If the versions do not match, the method considers that it may be an attack or tearing, and therefore stops preventively.

[0085] During step E410, the data of the copy of an object Oi are updated as well as in the area rollforward. Then, the version of the object Oi is updated in the copy of this object (step E412) then in the copy of the directory (step E414).

[0086] Then, steps E405 to E414 are repeated for each object to which one wishes to write (E416). Once the RAM memory and / or the area rollforward is full and / or all objects have been processed, the modifications made in RAM memory can be reflected in the NVM 12 memory (steps E420, E422, E440, E442).

[0087] Before this, the directory version is updated in the copy of the directory in RAM memory (step E418).

[0088] The CPU2 1022 then orders the updating of the directory in NVM 12 memory (step E420). This consists, for example, of replacing (i.e. erasing then writing in its place) the directory in NVM 12 with the copy of it updated in RAM memory in step E418.

[0089] CPU2 1022 then orders the zone to be updated rollforward in NVM 12 memory (step E422). This consists, for example, of updating the zone rollforward in NVM memory 12 based on the most recent data of the objects successively updated in RAM memory. It should be noted that for the sake of completeness, the write steps E420 and E422 have been described as two separate steps. However, in a context in which the NVM memory is in the form of memory pages, the write is performed in one go, on the same NVM memory page. In such a context, the write is considered to be either completed (all data is written) or not completed (no data written).

[0090] The CPU2 1022 then commands the update of the directory version in the OTP / MTP memory (step 430).

[0091] The CPU2 1022 then orders the updating of the objects in NVM memory 12, i.e. their data (step E440) in accordance with the area rollforward updated to step E422, as well as their own version (step E442).

[0092] It is noted that in the example described with reference to the figure 4 , the version of the directory is updated in step E418 after several objects Oi have been modified. This grouping of modifications makes it possible to limit the number of writes to OTP / MTP memory (step E430) and to optimize its lifetime. Alternatively, the version of the directory could be updated in RAM memory each time an object is written (step E418 integrated into the loop), with only the latest version of the directory subsequently being written to OTP / MTP memory in step E430. This would also make it possible to limit the number of writes to OTP / MTP memory and to optimize its lifetime.

[0093] In a final step (E444), the CPU2 1022 then erases the contents of the rollforward area in volatile memory 1026.

[0094] La figure 5 schematically illustrates the successive state (A to M) of the different memories considered (RAM 1026, OTP / MTP 1024, NVM 12) during the implementation of the steps of the figure 4 , according to a particular example given for illustration purposes only.

[0095] In this example, when CPU2 1022 is switched on (state A, step E400), OTP memory 1024 contains the identifier of the current version of the dedicated directory, here 'v3'. NVM memory 12 includes two objects: 'Object 1' and 'Object 2'. Object 1 has version v3 and contains W data. Object 2 has version v2 and contains Y data. NVM memory 12 also includes a directory indicating the correspondence between objects 1 and 2 and their respective version, as well as its own version, also stored in OTP memory 1024, namely 'v3'. NVM memory 12 also includes an area rollforward which includes the W and Y data of objects 1 and 2.

[0096] [ Fig.5A ] In this state A, corresponding to the boot of CPU2 1022, RAM 1026 is empty.

[0097] [ Fig.5B ] State B corresponds to the result of the verification of the “freshness” of the data (objects, directory) already present in NVM 12 memory when the CPU2 1022 is switched on, i.e. after implementation of the steps described with reference to the figure 2 .

[0098] At this point, RAM 1026 includes a copy of the previously mentioned directory, a copy of object 1, a copy of object 2, and a copy of the area rollforward, whose contents have been erased (step E30 of the figure 2 ) after the initial freshness check.

[0099] [ Fig.5C ] State C illustrates the writing of data X (replacing data W) in the copy of object 1 and in the copy of area rollforward (step E410) in RAM memory.

[0100] [ Fig.5D ] State D illustrates the update of the version of object 1 (v4 instead of v3) in the copy of object 1 in RAM memory 1026 (step E412).

[0101] [ Fig.5E ] State E illustrates the update of the version of object 1 (v4 instead of v3) in the copy of the directory in RAM memory 1026 (step E414).

[0102] [ Fig.5F ] State F illustrates the writing of data Z (replacing data Y) in the copy of object 2 and in the copy of area rollforward (second step E410) in RAM memory.

[0103] [ Fig.5G ] State G illustrates the update of the version of object 2 (v3 instead of v2) in the copy of object 2 in RAM memory 1026 (second step E412).

[0104] [ Fig.5H ] State H illustrates the update of the version of object 2 (v3 instead of v2) in the copy of the directory in RAM memory 1026 (second step E414).

[0105] [ Fig.5I ] All objects having been processed, the directory version is updated (v4 instead of v3) in the directory copy (step E418), as illustrated in state I.

[0106] If a power outage (tearing) of CPU2 1022 occurs before step E420, this has the effect of erasing the contents of the RAM memory. However, since no update of the NVM memory or the OTP memory has been performed, the versions of the objects (v3 for object 1 and v2 for object 2) in the directory and in the objects themselves match and the versions of the directory (v3) in the directory in NVM and in the OTP memory also match. It is therefore easy to verify that this was not an attack by rollback. This avoids a false positive that would indicate a bad version solely because of the power outage, without being attributable to an attack by rollback.

[0107] [ Fig.5J ] State J illustrates the update of the directory in NVM memory (step E420) as well as the zone rollforward (step 422) in accordance with the modified copies of the directory and the successively updated objects in the zone copy rollforward in RAM memory.

[0108] A power outage (tearing) of CPU2 1022 occurring between steps E422 and E430 has the effect of erasing the contents of RAM memory while the directory and the area rollforward have been updated in NVM 12 memory. However, the contents of the area rollforward (X and Y) differs from that of the objects in NVM 12 memory (W and Z) and since no OTP memory update has been performed, the directory versions in NVM (v4) and in OTP memory (v3) also differ. This indicates that a power outage occurred before the OTP secure memory update or that an attack by rollback took place, which explains the divergence in content and versions. In order to verify that this is not an attack by rollback, we can check if the version of the directory in NVM is strictly greater than that of the OTP memory (see step E24).

[0109] [ Fig.5K ] State K illustrates the update of the OTP memory (v4 instead of v3) of step E430. A power failure (tearing) of CPU2 1022 occurring between steps E430 and E440 has the effect of erasing the contents of RAM memory while the objects in NVM 12 memory have not been updated. On the other hand, as the directory and the area rollforward have been updated in NVM 12 memory and OTP memory has also been updated, it is possible to reliably know the content and version that the objects in NVM 12 memory should have. In fact, the correspondence between the versions of the directory in the directory in NVM memory and in OTP memory (v4) indicates that the versions of the objects indicated in the directory are the correct ones (the most "fresh"), as well as the content of the zone rollforward is the correct one. It is then sufficient to update the objects according to these elements, which will be copied into RAM memory to do this (see steps E28, E29).

[0110] [ Fig.5L ] State L illustrates the updating of objects 1 and 2 in NVM 12 memory, i.e. their content in accordance with the content of the area rollforward update at step E422: X and Z instead of W and Y (step E440) and their version (step E442).

[0111] [ Fig.5M ] Finally, state M illustrates the erasure of the contents of the zone rollforward in RAM (step E444) once the content and version of the NVM objects have been updated.

[0112] Generally speaking, it should be noted that the version number of an object provides information on the wear rate of certain areas of NVM memory. For example, a high version number indicates that an object has been modified many times. This information allows for better memory management. Thus, a better distribution of writes in NVM memory can be done to avoid premature wear of a particular area.

[0113] In one embodiment, the versions of each object are not incremented relative to their old version as described with reference to step E412; rather, they are assigned the value in OTP / MTP 1024 incremented by 1. Advantageously, this allows the acceleration of the performance of an incremental garbage collector allowing steps of a cycle to be executed alternately with the execution of the application. If we use the color abstraction introduced by Dijkstra et al [1976,1978] well known to those skilled in the art, an object is: white if it is never encountered during the marking phase, gray if it was encountered during the marking phase black if it was encountered during the marking phase and all its references were scanned to gray out the referenced objects.

[0114] When resuming marking, we will have taken care to change back to gray all the black objects whose version number is higher than the maximum of the versions of the objects during the previous marking step. We will therefore avoid a write barrier of the incremental garbage collector on the objects during the execution of the application ( mutator in Anglo-Saxon terminology).

[0115] The preceding examples are only embodiments of the invention. For example, for the sake of simplification, the description mainly concerns object-oriented systems. However, it could be applied to a system of a different nature.

Claims

1. System on a chip (10) comprising a secure element (102) comprising a processing unit (1022) configured to execute a secure operating system and to send instructions to a rewritable non-volatile memory (12) which is external to the system on a chip and connected to it, the secure element (102) further comprising a secure non-volatile memory (1024) as well as a secure volatile memory (1026), the system on a chip (10) being characterized in that the processing unit (1022) is configured to control: - the storage, in the external rewritable non-volatile memory (12), of at least one object having a current version, and of a dedicated directory associating an identifier of each object with an identifier of the current version of this object, the dedicated directory further comprising an identifier of its own current version; and - the storage, in the non-volatile memory (1024) of the secure element, of the identifier of the current version of the dedicated directory.

2. System on a chip (10) according to Claim 1, wherein the processing unit (1022) is configured to control the writing, to a roll-forward area in the external rewritable non-volatile memory (12), of data to be used to update an object.

3. System on a chip (10) according to Claim 2, wherein the processing unit (1022) is configured to control the creation of a copy of at least a portion of the contents of the external rewritable non-volatile memory (12) in the secure volatile memory (1026) of the secure element.

4. System on a chip (10) according to Claim 3, wherein the processing unit (1022) is configured to control the modification of said copy in the secure volatile memory (1026) of the secure element before the external rewritable non-volatile memory (12) is modified.

5. System on a chip (10) according to Claim 4, wherein the processing unit (1022) is configured to control: - the reproduction of the modifications carried out on a copy of the dedicated directory and of the roll-forward area in the secure volatile memory (1026) on the dedicated directory and the roll-forward area which are stored in the external rewritable non-volatile memory (12), then - the modification of the one or more relevant objects concerned stored in the external rewritable non-volatile memory (12) in accordance with the contents of the roll-forward area and of the dedicated directory.

6. System on a chip (10) according to Claim 5, wherein the processing unit (1022) is configured to control the updating of the identifier of the current version of the dedicated directory in the secure non-volatile memory (1024) of the secure element before the one or more relevant objects stored in the external rewritable non-volatile memory (12) are modified in accordance with the contents of the roll-forward area and of the dedicated directory.

7. System on a chip (10) according to Claim 5, wherein the processing unit (1022) is configured to control the reproduction of the modifications in the external rewritable non-volatile memory (12) after several copies of objects have been modified in the secure volatile memory (1026) of the secure element.

8. System on a chip (10) according to any one of the preceding claims, wherein the secure non-volatile memory of the secure element is an OTP or MTP memory with a limited lifetime.

9. System on a chip (10) according to any one of the preceding claims, wherein the identifier of the current version of an object and / or the identifier of the current version of the dedicated directory is a version number.

10. System on a chip (10) according to any one of the preceding claims, wherein the identifier of the current version of an object and / or the identifier of the current version of the dedicated directory is a signature or a checksum calculated on the basis of the object and / or of the dedicated directory, uniquely identifying its version.

11. System on a chip (10) according to any one of Claims 1 to 9, wherein the identifier of the current version of an object and the identifier of the current version of the dedicated directory are version numbers, wherein the processing unit (1022) implements a first comparison function and a second comparison function in order to determine whether a version identifier corresponds to a current version or an old version, the first function consisting in determining whether the values are identical, the second function consisting in determining whether said version is strictly higher or strictly lower than the current version.

12. System on a chip (10) according to any one of the preceding claims, wherein the processing unit (1022) is configured to operate at times in a non-secure execution mode and at times in a secure execution mode.

13. System on a chip (10) according to any one of the preceding claims, wherein the processing unit (1022) is configured to control a memory controller (101) controlling the external rewritable non-volatile memory (12).

14. Method for securely writing an object to a rewritable non-volatile memory (12) which is external to a system on a chip (10) and connected to it, the system on a chip (10) comprising a secure element (102) comprising a processing unit (1022) configured to execute a secure operating system and to send instructions to the external rewritable non-volatile memory (12), the secure element (102) further comprising a secure non-volatile memory (1024) as well as a secure volatile memory (1026), the method being characterized in that it comprises the following steps: - controlling the writing (E420) of an identifier of the current version of the object in a dedicated directory stored in the external rewritable non-volatile memory (12), in association with an identifier of the object, - controlling the updating (E420) of an identifier of the current version of the dedicated directory in the dedicated directory stored in the external rewritable non-volatile memory (12), - controlling the writing (E430) of the identifier of the current version of the dedicated directory in the secure non-volatile memory (1024) of the secure element.

15. Method according to Claim 14, including a step of verifying the freshness of an object stored in the external rewritable non-volatile memory (12), comprising: - creating (E22) a copy of the dedicated directory and of the object in the secure volatile memory (1026) of the secure element, - comparing (E24) the identifier of the current version of the dedicated directory stored in the copy of the dedicated directory with the identifier of the current version of the dedicated directory stored in the secure non-volatile memory (1024) of the secure element; - in the event of equality, comparing (E28) the identifier of the current version of the copy of the object with the identifier of the version of this object stored in the copy of the dedicated directory, in order to verify the freshness of the object.

16. Method according to Claim 14 or 15, implemented at the startup (E20) of the processing unit (1022) of the secure element (102).

17. Method according to any one of Claims 14 to 16, wherein the identifier of the current version of an object and / or the identifier of the current version of the dedicated directory is a version number.

18. Method according to any one of Claims 14 to 17, wherein the identifier of the current version of an object and / or the identifier of the current version of the dedicated directory is a signature or checksum calculated on the basis of the object and / or of the dedicated directory, uniquely identifying its version.

19. Method according to any one of Claims 14 to 18, further comprising a step of writing, to a roll-forward area in the external rewritable non-volatile memory (12), data to be used to update an object.

20. Method according to any one of Claims 14 to 19, wherein the identifier of the current version of an object and the identifier of the current version of the dedicated directory are version numbers, wherein a first comparison function and a second comparison function are implemented in order to determine whether a version identifier corresponds to a current version or to an old version, the first function consisting in determining whether the values are identical, the second function consisting in determining whether said version is strictly higher or strictly lower than the current version.

21. Method according to Claim 15, comprising a step of updating (E26) the version and / or the contents of said object in the event of a difference detected during said comparison (E29) of the identifier of the current version of the copy of the object with the identifier of the version of this object stored in the copy of the dedicated directory.