System-on-chip and method for ensuring the up-to-dateness of data stored in external memory

Abstract

The present invention relates to a system-on-chip (10) comprising a security element (102) comprising a processing unit (1022) configured to transmit instructions to a rewritable non-volatile memory (12) located outside the system-on-chip and connected to the system, wherein the security element (102) further comprises a secure non-volatile memory (1024) and a secure volatile memory (1026), and the system-on-chip (10) comprises a processing unit (1022). - Storage in rewritable non-volatile memory (12) of at least one object having a current version and a dedicated directory associating the identifier of the current version of the object with the identifier of each object - the dedicated directory additionally includes its own identifier of the current version -; and - It is characterized by being configured to instruct the storage of the identifier of the current version of the dedicated directory in the non-volatile memory (1024) of the security element.

Description

Technology Field

[0001] The present invention relates to the field of security, in particular, to a system-on-a-chip having a security element in which a portion of the data is stored in memory outside the system-on-a-chip. In particular, the present invention relates to a system-on-a-chip and methods for ensuring the up-to-dateness of data stored in such external memory. Background Technology

[0002] In a system-on-chip (SOC) containing security integration elements, data manipulated by the security operating system is typically stored in memory outside the system-on-chip for cost reasons.

[0003] Therefore, for example, the security element includes a processing unit, volatile memory, as well as small non-volatile memory with typically low durability, such as One-Time Programmable (OTP) or Multi-Time Programmable (MTP) memory, while the external memory is typically rewritable non-volatile memory with much higher durability. One example is flash memory.

[0004] One difficulty is that memory outside the security element and SOC can be shared with applications other than those within the security element or SOC. Furthermore, it can be manipulated independently of the security element or SOC, and therefore, the use of the data it contains cannot be controlled.

[0005] For example, data in external memory can be restored to be reused later for fraudulent purposes. Such an attack, which involves modifying the current value of data by reusing a previous value, is known by the name "rollback." For example, as described in document US 2017 / 0124353 A1, it is much more difficult to detect in the absence of a connection that enables the "freshness" of the value used to be verified from a remote server.

[0006] As an example, such an attack can allow a user to access paid services after their subscription has ended. Another example of this type of attack can cause a user to reset their digital wallet to its maximum value after emptying it.

[0007] Therefore, there is a need for a local means that does not require a connection to a remote server to verify the freshness of data from such memory outside the SOC, particularly to avoid rollback attacks.

[0008] Therefore, the objective of the present invention is to overcome at least one of these disadvantages.

[0009] In this context, a first aspect of the present invention relates to a system-on-chip comprising a security element including a processing unit configured to execute a security operating system and transmit instructions to a rewritable non-volatile memory located outside the system-on-chip and connected to the system, wherein the security element further comprises a security volatile memory as well as a security non-volatile memory, and the system-on-chip comprises a processing unit,

[0010] - Storage in external rewritable non-volatile memory of at least one object having a current version and a dedicated directory associating the identifier of the current version of the object with the identifier of each object - the dedicated directory additionally contains its own identifier of the current version -; and

[0011] - It is characterized by being configured to instruct the storage of the identifier of the current version of a dedicated directory in the non-volatile memory of the security element.

[0012] Correlatively, a second aspect of the present invention is a method for securely writing an object in a rewritable non-volatile memory located outside the system-on-chip and connected to the system, wherein the system-on-chip comprises a security element comprising a processing unit configured to execute a secure operating system and transmit instructions to an external rewritable non-volatile memory, and the security element further comprises a secure volatile memory as well as a secure non-volatile memory, and the method is

[0013] - A step of directing the recording of the identifier of the current version of an object in a dedicated directory stored in externally rewritable non-volatile memory in association with the identifier of an object,

[0014] - A step of instructing the update of the identifier of the current version of a private directory in a private directory stored in externally rewritable non-volatile memory,

[0015] - Characterized by including a step of instructing the recording of the identifier of the current version of a dedicated directory within the secure non-volatile memory of the security element.

[0016] Accordingly, the claimed invention makes it possible to ensure the "latestness" of data stored in the external memory of the SOC and connected thereto, that is, to ensure that these data correspond well to the version expected at that time.

[0017] In fact, by attaching the current version to each object and recording the identifier of that version in a dedicated directory that also contains the version with the identifier recorded in the secure non-volatile memory of the security element, an attack consisting of replacing the data of an object in external memory with an older version will be detected immediately.

[0018] Therefore, the general security of the system-on-a-chip is improved without requiring any material modifications to the system-on-a-chip. Consequently, the advantage of using external memory with better durability than the non-volatile memory of the security element is preserved.

[0019] In addition, the version replication system used in the claimed invention enables distinguishing objects that have not been updated due to a simple power failure (referred to as tearing) while recording (updating) their own data in relation to an attack attempting to record old data.

[0020] Other features of the system-on-chip and method according to some embodiments of the present invention are disclosed in dependent claims.

[0021] In some embodiments, the processing unit is configured to direct the writing of data to be used to update an object in a "rollforward" type area within external rewritable non-volatile memory.

[0022] In some embodiments, the processing unit is configured to direct the creation of at least a copy of the contents of an externally rewritable non-volatile memory into the secure volatile memory of the security element.

[0023] In some embodiments, the processing unit is configured to direct the modification of the copy in the secure volatile memory of the security element before modifying the external rewritable nonvolatile memory.

[0024] In some embodiments, the processing unit is,

[0025] - Replay of modifications made in copies of rollforward type zones and private directories within secure volatile memory from rollforward type zones and private directories stored in external rewritable non-volatile memory, followed

[0026] - Modification of related objects or objects stored in external rewritable non-volatile memory based on the contents of dedicated directories and rollforward type zones

[0027] It is configured to instruct.

[0028] In some embodiments, the processing unit is configured to direct the update of the identifier of the current version of the private directory within the secure non-volatile memory of the security element before modifying the associated object or objects stored in external rewritable non-volatile memory according to the contents of the private directory and the rollforward type zone.

[0029] In some embodiments, the processing unit is configured to direct the retrieval of modifications in external rewritable non-volatile memory after some copies of the objects have been modified in the secure volatile memory of the security element.

[0030] In some embodiments, the security non-volatile memory of the security element is a memory with a limited lifespan of the OTP or MTP type.

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

[0032] In some embodiments, the identifier of the current version of the object and / or the identifier of the current version of the private directory is a checksum that uniquely identifies its version, calculated from the object and / or the private directory.

[0033] In some embodiments, the identifier of the current version of the object and / or the identifier of the current version of the private directory is a signature that uniquely identifies the version of the object and / or the private directory.

[0034] In some embodiments, the processing unit performs a first comparison function and a second comparison function to determine whether a version identifier corresponds to a current version or a previous version, the first function is composed of determining whether the values ​​are identical, and the second function is composed of determining whether the version is strictly higher or strictly lower than the current version.

[0035] For example, the first function consists of determining whether the values ​​of the version of the directory copy in the secure volatile memory are identical to those of the current version of the directory recorded in the secure non-volatile memory OTP / MTP of the security element. The second function consists of determining whether the version of the directory copy in the secure volatile memory is strictly higher or strictly lower than the current version of the directory recorded in the secure non-volatile memory OTP / MTP of the security element.

[0036] In some embodiments, the processing unit is configured to function in both a non-secure execution mode and a secure execution mode.

[0037] In some embodiments, the processing unit is configured to control a memory controller that controls external rewritable non-volatile memory. This controller may be on or outside the SOC.

[0038] In some embodiments, the method includes the step of verifying the latest status of an object stored in an externally rewritable non-volatile memory, and the step of verifying is

[0039] - A step of creating copies of dedicated directories and objects in the secure volatile memory of a security element,

[0040] - A step of comparing the identifier of the current version of the private directory stored in a copy of the private directory (in secure volatile memory) with the identifier of the current version of the private directory stored in the secure non-volatile memory of the security element;

[0041] - If they are identical, to verify the newness of the object, the method includes the step of comparing the identifier of the current version of the copy of the object (in secure volatile memory) with the identifier of the version of the object stored in the copy of the dedicated directory (in secure volatile memory).

[0042] In some embodiments, where there is version identity between the identifier of the current version of the private directory stored in a copy of the private directory (in secure volatile memory) and the identifier of the current version of the private directory stored in the secure non-volatile memory of the security element, but there is a difference between the object itself and the versions of the object displayed in the private directory, the method includes the step of updating the version and / or content of the object.

[0043] In some embodiments, this method is implemented during the boot-up of the security element processing unit.

[0044] In some embodiments, the processing unit further includes the step of writing data to be used to update an object in a "rollforward" type area within external rewritable non-volatile memory.

[0045] In some embodiments, the processing unit performs a first comparison function and a second comparison function to determine whether a version identifier corresponds to a current version or a previous version, the first function is composed of determining whether the values ​​are identical, and the second function is composed of determining whether the version is strictly higher or strictly lower than the current version.

[0046] For example, the first function consists of determining whether the values ​​of the version of the directory copy in the secure volatile memory are identical to those of the current version of the directory recorded in the secure non-volatile memory OTP / MTP of the security element. The second function consists of determining whether the version of the directory copy in the secure volatile memory is strictly higher or strictly lower than the current version of the directory recorded in the secure non-volatile memory OTP / MTP of the security element.

[0047] The advantages, purposes, and specific features of the methods are similar to those of the system-on-chip implementing them.

[0048] In certain embodiments, different steps of the methods mentioned above are determined by computer program instructions.

[0049] As a result, the present invention also relates to computer programs on an information medium, which can be implemented by a microprocessor, and which include instructions suitable for implementing the steps of the methods described above.

[0050] 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 a partially compiled form or any other desirable form.

[0051] The present invention also relates to an information medium that is readable by a microprocessor and includes computer program instructions as described above.

[0052] An information medium may be any entity or device capable of storing a program. For example, the medium may include a storage medium such as ROM, e.g., microcircuit ROM, or a magnetic recording medium, e.g., a hard drive or even flash memory.

[0053] Additionally, the information medium may be a transparent medium, such as an electrical or optical signal that can be transmitted via an electrical or optical cable, by radio, or by other means. A program according to the present invention may be downloaded to a storage platform, particularly of an internet-type network.

[0054] Alternatively, the information medium may be an integrated circuit into which a program is integrated, and the circuit is suitable for executing the method or for use in executing the method.

[0055] The aforementioned information media and computer programs have features and advantages similar to the methods they implement. Brief explanation of the drawing

[0056] Other specific features and advantages of the present invention will become more apparent from the following description, illustrated by the accompanying drawings showing examples of non-limiting embodiments. FIG. 1 illustrates an example of an architecture for a system-on-chip according to embodiments of the present invention. FIG. 2 illustrates, in the form of a flowchart, steps implemented by a system-on-chip to verify the currentness of an object according to embodiments of the present invention. FIG. 3, including FIG. 3a, FIG. 3b, FIG. 3c, FIG. 3d and FIG. 3e, schematically illustrates the successive states of different memories considered during the implementation of the steps of FIG. 2. FIG. 4 illustrates, in the form of a flowchart, the steps implemented by a system-on-chip during a security record according to embodiments of the present invention. FIG. 5, including FIG. 5a to FIG. 5m, schematically illustrates the successive states of different memories considered during the implementation of the steps of FIG. 4. In the following, it is used to specify the same elements when the same references appear in different drawings. Specific details for implementing the invention

[0057] FIG. 1 illustrates a possible example of an architecture for a system-on-chip (hereinafter SOC) according to some embodiments of the present invention.

[0058] According to some 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. Such a local connection is typically implemented by a bus (14).

[0059] The rewritable non-volatile memory NVM (12) is typically flash memory or any other memory having good durability. For the purposes of the present invention, this memory may constitute a medium, that is, this memory may contain a computing program containing instructions for implementing the method according to the present invention. Subsequently, the program is loaded into RAM memory (1026) when the SOC (10) is booted up.

[0060] In this example, the SOC (10) includes a first processing unit or microprocessor (101), denoted as CPU1 (Central Processing Unit), and a security element (102). The first processing unit (CPU1) (101) and the security element (102) communicate, for example, through a communication interface (103) including a Direct Memory Access (DMA) module or a mailbox (not shown).

[0061] The security element (102) includes the following elements connected by the communication bus (1020):

[0062] - A processing unit (or microprocessor) - denoted as CPU2, utilizing a secure operating system (OS) - or microprocessor - (1022). According to embodiments, this processing unit may operate only in secure mode or in some modes (secure or non-secure). According to embodiments, this processing unit (CPU2) is configured to transmit instructions to a memory controller (on or connected to the SOC) controlling NVM memory (12) or to CPU1 to operate on this memory (12);

[0063] - Non-volatile memory (1024), e.g., OTP or MTP;

[0064] - Random access memory or cache memory or volatile memory (1026), e.g., RAM (Random Access Memory), including registers suitable for storing variables and parameters created and modified during the execution of the aforementioned program; during the implementation of the present invention, program instruction codes stored in non-volatile memory (e.g., NVM) are loaded into RAM memory to be executed by a processing unit (CPU2); and

[0065] - For example, a non-volatile memory (12) that can be rewritable through CPU1 and a communication interface (103) suitable for transmitting and receiving data.

[0066] The communication bus enables communication and interoperability between various elements included in or connected to the security element. The description of the bus is not limited, and in particular, the processing unit (CPU2) may communicate instructions directly to any element of the security element or through other elements of this security element.

[0067] In this example, note that the intelligence of the present invention is located in CPU2, and CPU2 transmits its instructions to CPU1, which are then transmitted to the memory NVM (12) via the bus (14). In practice, CPU1 may be a simple memory controller.

[0068] According to one variant not shown, CPU1 can be replaced with a memory controller outside the SOC (10), and CPU2 will directly transmit instructions / directions.

[0069] Generally, the OS of CPU2 uses objects as memory containers. As is known, an object is a block of bits containing a header and data (payload). The header typically indicates the size of the data, while the data contains information used by applications running on the OS or by the OS itself. The OS can allocate objects dynamically (during execution) or statically (when the operating system image is configured). It can use these objects for its own needs or for object-oriented applications by virtual machines. The OS generally accesses objects by an address or an identifier that redirects to that address.

[0070] FIG. 2 illustrates, in the form of a flowchart, steps implemented by a system-on-chip, for example, to verify the freshness of an object when the object is read, according to embodiments of the present invention. Typically, the described steps are implemented by a processing unit (CPU2) (1022) of a security element (102).

[0071] During step E20, the processing unit (CPU2) (1022) of the security element is booted up. Note that the processing unit (CPU2) (1022) of the SOC and the security element generally have independent power supplies. However, the invention is not limited thereto, and in one embodiment, the SOC and the security element share the same power supply.

[0072] Next, in this example, the memory NVM (12) includes at least one object having a current version, as well as a dedicated directory that associates the identifier of each object with the identifier of the object's current version. The dedicated directory additionally includes its own identifier of the current version.

[0073] According to the embodiments, the version identifier may be a version number, or a signature, or a checksum that enables the version to be identified in a unique manner. For example, the signature may be calculated for the version number and data of an object. For simplification, only the version number is considered below. However, those skilled in the art will know how to transpose the following teachings into a signature or checksum.

[0074] NVM memory (12) may also include a rollforward type zone used to ensure the security and atomicity of updating the object's data. To do this, the rollforward zone contains data to be used to update a given object. That is, this zone contains the last version ("latest") of the data. For example, this zone makes it possible to restore the last version of the data within the object in the event of a power failure, thereby preventing damage to the object.

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

[0076] During step E22, the contents of the memory NVM (12), in particular at least one part of the rollforward zone existing on the same memory page as well as at least the previously mentioned directory, are copied to the RAM memory (1026) of the security element (102).

[0077] During step E24, the identifier of the current version of the private directory stored in a copy of the private directory (i.e., within RAM memory (1026)) is compared with the identifier of the current version of the private directory stored in the secure non-volatile memory (OTP / MTP (1024)) of the security element. In the preferred assumption that the rollforward zone shares the same memory page as the private directory, the version identifier also enables the validation of the contents of the rollforward zone. In practice, the integrity of the memory page is guaranteed. Consequently, the validation of the version enables testing the "latestness" of all contents of the memory page, that is, verifying whether the contents of the page correspond to what is expected. If the rollforward zone is not on the same memory page as the private directory, an embodiment based on signatures or checksums may be advantageously preferred.

[0078] In step E24, if it is determined that the current version of the copy of the directory in RAM memory (1026) is strictly lower than the current version of the directory displayed in secure non-volatile memory (OTP / MTP (1024)), this means that a rollback attack has occurred.

[0079] In step E24, if it is determined that the current version of the copy of the directory in RAM memory (1026) is strictly higher than the current version of the directory displayed in the secure non-volatile memory (OTP / MTP (1024)), this means that there was a power failure (tearing) during the update in the external non-volatile memory (12). Subsequently, the method continues to step E26, referred to as "recovery" of the secure non-volatile memory (OTP / MTP (1024)), to update the value of the version of the directory in the OTP / MTP memory to be equal to the value of the version of the copy of the directory in RAM memory (1026). Following this recovery step E26, or in step E24, if it is determined that the current version of the copy of the directory in RAM memory (1026) is the same as the current version of the directory displayed in secure non-volatile memory (OTP / MTP (1024)), the method continues to step E27, during which the reference object in the copy of the rollforward zone in RAM memory is copied in turn from NVM memory (12) to RAM memory (read of object). For the sake of simplification, in the following, a single object is referenced in the rollforward zone, but this example is not limited, and it is considered that the zone may reference several objects.

[0080] During step E28, to verify the newness of the object, 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 a copy of a dedicated directory in RAM memory.

[0081] If the versions match, it means that the data of this object is new, that is, they have the expected values.

[0082] If these versions do not match, the version of the object in RAM memory (1026) (if necessary) as well as its content are updated (step E29). The content of the object in external non-volatile memory (12) is also updated. When this update step is completed, the content of the copy of the rollforward zone in RAM memory (1026) is deleted (step E30). Preferably, the above operations are performed when CPU2 boots. Subsequently, the copy of the rollforward zone and directory will be retained in RAM memory (1026) for the entire duration of execution.

[0083] In fact, during the last read of an object, if the object is not already in RAM memory (1026), the individual object is copied from external non-volatile memory (12) to RAM memory (1026). This version of the object is compared with a version from a copy of the directory in RAM memory (1026) to verify the newness of the object, in a manner similar to steps E27 and the following steps.

[0084] FIG. 3 schematically illustrates successive states a, b, c, d, e of various related memories (RAM (1026), OTP / MTP (1024), NVM (12)) during the implementation of the steps of FIG. 2, according to one specific example provided as an example.

[0085] In this example, when CPU2 (1022) is booted up (state a, step E20), the OTP memory (1024) contains the identifier "v3" of the current version of the dedicated directory in this instance. The NVM memory (12) contains two objects: "Object 1" and "Object 2". Object 1 has version v3 and contains data W. Object 2 has version v2 and contains data Y. The NVM memory (12) also contains a directory that indicates the matching of Objects 1 and 2 and their respective versions, as well as its own version, i.e., v3, which is also stored in the OTP memory (1024). The NVM memory (12) also contains a rollforward section containing the data (W and Y) of Objects (1 and 2).

[0086] [Fig. 3a] In this state a, in response to the boot-up of CPU2, the RAM memory (1026) is empty.

[0087] [Fig. 3b] State b corresponds to the results of the implementation of step E22. Thus, after copying a portion of the contents of the NVM memory (12) to the RAM memory (1026), the RAM memory (1026) contains a copy of the aforementioned directory as well as a copy of the rollforward zone.

[0088] [Fig. 3c] State c illustrates the comparison of versions of directories in RAM memory (1026) and OTP (1024) during step E24. In this example, the versions match.

[0089] [Fig. 3d] State d illustrates a comparison of a copy of object (1) in RAM memory (1026) during step E27, followed by a copy from a directory in RAM memory (1026) and versions of object (1) in the copy of object (1) during step E28. In this example, the versions match.

[0090] [Fig. 3e] State e illustrates a comparison of a copy of object (2) in RAM memory (1026) during step E27, followed by a copy of a directory in RAM memory (1026) and versions of object (2) in the copy of object (2) during step E28. In this example, the versions match.

[0091] Therefore, the objects correspond to what is expected in terms of version (latestness).

[0092] FIG. 4 illustrates, in the form of a flowchart, the steps implemented by a system-on-chip during a security record according to embodiments of the present invention.

[0093] The method illustrated in FIG. 4 begins after verifying the freshness of data (objects, directories) already present in NVM memory (12) when CPU2 (1022) boots. Typically, this verification is performed by carrying out the steps described with reference to FIG. 2.

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

[0095] Objects are preferably processed sequentially, that is, only one object at a time is copied into RAM memory, its version is verified, and then, if applicable, updated.

[0096] If the number of objects whose recency must be verified is too large to store copies of all objects in RAM memory, at least certain objects (not currently used by the application) are deleted from RAM memory to allow verification of other objects.

[0097] During step (405), if the object to be written does not already exist in RAM memory, a copy is made in RAM memory (1026). Subsequently, it is verified that the version is actually the version corresponding to its entry in a copy of the directory in volatile memory (1026).

[0098] Then, steps E410 through E418 are implemented in RAM memory (1026). If the versions do not match, the method is assumed to involve an attack or tiering and is therefore stopped preemptively.

[0099] During step E410, the data in the copy of object (Oi) is also updated as in the rollforward section. Next, the version of object (Oi) is updated in the copy of this object (step E412), and then, in the copy of the directory (step E414).

[0100] Next, steps (E405 to E414) are repeated for each object that is to be written (E416). Once the RAM memory and / or rollforward area is full and / or all objects have been processed, changes made in the RAM memory can be reflected in the NVM memory (12) (steps E420, E422, E440, E442).

[0101] Before that, the version of the directory is updated in a copy of the directory in RAM memory (step E418).

[0102] Next, CPU2 (1022) directs an update of a directory in NVM memory (12) (step E420). This is accomplished by replacing (meaning erasing and then writing to) the directory in NVM (12) with a copy updated in RAM memory, for example, in step E418.

[0103] Next, CPU2 (1022) directs the update of the rollforward area within the NVM memory (12) (step E422). This consists of updating the rollforward area within the NVM memory (12) based on the most recent data of objects that have been continuously updated in RAM memory, for example. For completeness, it should be noted that the write steps (E420 and E422) have been described as two separate steps. However, in the context where the NVM memory is in the form of memory pages, the write is performed only once on the same NVM memory page. In this context, the write is considered to be performed (all data is written) or not performed (no data written).

[0104] CPU2 (1022) instructs the update of the version of the directory in OTP / MTP memory (step 430).

[0105] Next, CPU2 (1022) directs the updating of objects in NVM memory (12), namely the rollforward area updated in step E422, as well as their data (step E440) according to its own version (step E442).

[0106] In the example described with reference to FIG. 4, it should be noted that after some objects (Oi) are modified, the version of the directory is updated in step (E418). This group of modifications makes it possible to limit the number of records in OTP / MTP memory (step E430) and optimize their lifespan. Alternatively, the version of the directory can be updated in RAM memory with each record in the object (step E418 is incorporated into a loop), and then, in step E430, only the last version of the directory is written to OTP / MTP memory. This will also make it possible to limit the number of records in OTP / MTP memory and optimize their lifespan.

[0107] Next, in the final step (E444), CPU2 (1022) clears the contents of the rollforward area in the volatile memory (1026).

[0108] FIG. 5 schematically illustrates the successive states (a to m) of various related memories (RAM (1026), OTP / MTP (1024), NVM (12)) during the implementation of the steps of FIG. 4, according to one specific example provided as an example.

[0109] In this example, when CPU2 (1022) is booted (state a, step E400), the OTP memory (1024) contains the identifier "v3" of the current version of the dedicated directory in this instance. The NVM memory (12) contains two objects: "Object 1" and "Object 2". Object 1 has version v3 and contains data W. Object 2 has version v2 and contains data Y. The NVM memory (12) also contains a directory that indicates the matching of objects 1 and 2 and their respective versions, as well as its own version, i.e., v3, which is also stored in the OTP memory (1024). The NVM memory (12) also contains a rollforward section containing the data (W and Y) of objects (1 and 2).

[0110] [Fig. 5a] In this state a, in response to the boot-up of CPU2 (1022), the RAM memory (1026) is empty.

[0111] [Fig. 5b] State b corresponds to the result of verifying the "latestness" of data (objects, directories) already existing in NVM memory (12) when CPU2 (1022) is booted, that is, after the implementation of the steps described with reference to Fig. 2.

[0112] At this stage, the RAM memory (1026) includes copies of the aforementioned directory, copies of Object 1 and Object 2, as well as copies of the rollforward area, the contents of which were erased upon completion of the initial verification of freshness (step E30 of FIG. 2).

[0113] [Fig. 5c] State c exemplifies the recording of data X (replacing data W) in a copy of object (1) and a copy of the rollforward area in RAM memory (step E410).

[0114] [Fig. 5d] State d exemplifies an update of a version of Object 1 (v4 instead of v3) in a copy of Object 1 in RAM memory (1026) (step E412).

[0115] [Fig. 5e] State e exemplifies the update of a version of Object 1 (v4 instead of v3) in a copy of the directory in RAM memory (1026) (step E414).

[0116] [Fig. 5f] State f exemplifies the recording of data Z (replacing data Y) in a copy of object (2) and a copy of the rollforward area in RAM memory (second step E410).

[0117] [Fig. 5g] State g exemplifies an update of a version of Object 2 (v3 instead of v2) in a copy of Object 2 in RAM memory (1026) (Step 2 E412).

[0118] [Fig. 5h] State h exemplifies the update of a version of Object 2 (v3 instead of v2) in a copy of a directory in RAM memory (1026) (Step 2 E414).

[0119] [Fig. 5i] Since all objects have been processed, the version of the directory (v4 instead of v3) is updated in the copy of the directory as exemplified in state i (step E418).

[0120] If a power failure (tearing) of CPU2 (1022) occurs before step E420, it results in the wiping of the contents of RAM memory. However, since neither NVM memory nor OTP memory is updated, the versions of the objects within the directory and within the objects themselves (v3 for Object 1 and v2 for Object 2) match, and the directory versions (v3) of the directory within NVM and OTP memory also match. Therefore, it is easy to verify that no rollback attack was involved. Thus, a false positive indicating a bad version due only to a power failure, without being caused by a rollback attack, was avoided.

[0121] [Fig. 5j] State j exemplifies the update of the rollforward zone (step E422) as well as the directory (step E420) in NVM memory, according to the objects and modified copies of the directory that are continuously updated in the copy of the rollforward zone in RAM memory.

[0122] A power failure (tearing) of CPU2 (1022) occurring between steps E422 and E430 results in the wiping of the contents of RAM memory while the directory and rollforward zones in NBM (12) memory are updated. However, the contents of the rollforward zones (X and Y) differ from the contents of the objects in NVM memory (12) (W and Z), and since no update of the OTP memory has occurred, the versions of the directory in NVM (v4) and OTP memory (v3) are also different. This indicates that a power failure or a rollback attack occurred before the update of the secure memory OTP, which explains the divergence of the contents and versions. To verify that no rollback attack was involved, it can be verified whether the version of the directory in NVM is strictly higher than the version in OTP memory (see step E24).

[0123] [Fig. 5k] State k exemplifies the update of the OTP memory (v4 instead of v3) in step E430.

[0124] A power failure (tearing) of CPU2 (1022) occurring between steps E430 and E440 results in the wiping of the contents of RAM memory even if the objects in NVM memory (12) have not been updated. However, since the directory and rollforward zone have been updated in NVM memory (12) and the OTP memory has also been updated, it is possible to reliably know the versions and contents that the objects should have in NVM memory (12). In fact, the correspondence between the directory versions of the directory in NVM memory and OTP memory (v4) indicates that the versions of the objects displayed in the directory are good ("latest") and that the contents of the rollforward zone are also good. Subsequently, the objects need to be updated based solely on these elements. To do this, these elements will be copied to RAM memory (see steps E28, E29).

[0125] [Fig. 5l] State l illustrates the update of the contents of objects 1 and 2 in NVM memory (12), that is, the contents of the rollforward area updated in step E422: X and Z (step E440) instead of W and Y, and their versions (step E442).

[0126] [Fig. 5m] Finally, state m exemplifies the erasure of the contents of the rollforward area in RAM once the versions and contents of the NVM objects are updated (step E444).

[0127] In general, it should be noted that an object's version number provides information regarding the wear rate of certain regions in NVM memory. For example, a high version number indicates that the object has been modified multiple times. This information enables better memory management, in particular. Therefore, better distribution of writes within NVM memory can be achieved to avoid premature wear of specific regions.

[0128] In one embodiment, the versions of each object are not incremented relative to their previous version as described with reference to step E412; rather, the value of OTP / MTP (1024) is assigned to them and increased by 1. Advantageously, this enables the acceleration of the performance of incremental garbage collection, thereby enabling the execution of the cycle steps alternating with the execution of the application. If the color abstraction well known to those skilled in the art, introduced by Dijkstra et al. [1976, 1978], is used, the object,

[0129] - If not detected during the marking phase, white,

[0130] - If detected during the marking phase, gray,

[0131] - It is black if all references have been scanned to gray out the objects found and referenced during the marking phase.

[0132] During the resumption of marking, care will be taken to revert all black objects with version numbers higher than the maximum of the object versions during the preceding marking phase to grayscale. Thus, the record barrier of incremental garbage collection on objects during the execution of the application (mutator) will be avoided.

[0133] The preceding examples are merely non-limiting embodiments of the present invention. For example, for the sake of simplification, the description relates primarily to object-oriented systems. However, it may be applied to systems of different natures.

Claims

Claim 1 A system on a chip (10) comprising a security element (102) configured to execute a security operating system and transmit instructions to a rewritable non-volatile memory (12) located outside the system on the chip and connected to the system, wherein the security element (102) further comprises a security volatile memory (1026) as well as a security non-volatile memory (1024), and the system on the chip (10) is characterized in that the processing unit (1022) is configured to store, in the rewritable non-volatile memory (12), at least one object having a current version and a dedicated directory associating the identifier of the current version of the object with the identifier of each object, wherein the dedicated directory further comprises its own identifier of the current version; and wherein the security element is configured to store the identifier of the current version of the dedicated directory in the non-volatile memory (1024). Claim 2 In claim 1, the processing unit (1022) is configured to direct the recording of data to be used to update an object in a "rollforward" type area within the rewritable non-volatile memory (12), the system on chip (10). Claim 3 In paragraph 2, the processing unit (1022) is configured to direct the creation of at least a copy of the contents of the rewritable non-volatile memory (12) into the security volatile memory (1026) of the security element, a system on chip (10). Claim 4 In paragraph 3, the system-on-chip (10) is configured such that the processing unit (1022) directs the modification of the copy in the security volatile memory (1026) of the security element before the modification of the rewritable non-volatile memory (12). Claim 5 In paragraph 4, the processing unit (1022) is configured to direct the retrieval of modifications made on a copy of the rollforward type area and the private directory within the secure volatile memory (1026) in the rollforward type area and the private directory stored in the rewritable nonvolatile memory (12), followed by the modification of related objects or objects stored in the rewritable nonvolatile memory (12) according to the contents of the private directory and the rollforward type area, in a system on chip (10). Claim 6 In paragraph 5, the processing unit (1022) is configured to instruct the update of the identifier of the current version of the dedicated directory in the security non-volatile memory (1024) of the security element before modification of the related object or objects stored in the rewritable non-volatile memory (12) according to the contents of the dedicated directory and the rollforward type zone, in a system-on-chip (10). Claim 7 In paragraph 5, the processing unit (1022) is configured to direct the retrieval of said modifications in the rewritable non-volatile memory (12) after some copies of the objects have been modified in the security volatile memory (1026) of the security element. Claim 8 In any one of claims 1 to 7, the security non-volatile memory of the security element is a memory having a limited lifespan of the OTP or MTP type, a system-on-chip (10). Claim 9 In any one of claims 1 to 7, the identifier of the current version of the object and / or the identifier of the current version of the dedicated directory is a version number, system on chip (10). Claim 10 A system-on-chip (10) in any one of claims 1 through 7, wherein the identifier of the current version of the object and / or the identifier of the current version of the private directory is a signature or checksum that uniquely identifies its version, calculated based on the object and / or the private directory. Claim 11 In any one of claims 1 to 7, the processing unit (1022) performs a first comparison function and a second comparison function to determine whether a version identifier corresponds to a current version or a previous version, the first comparison function is configured to determine whether values ​​are identical, and the second comparison function is configured to determine whether the version is strictly higher or strictly lower than the current version, the system on chip (10). Claim 12 In any one of claims 1 to 7, the system-on-chip (10) is configured to function in both a non-secure execution mode and a secure execution mode. Claim 13 In any one of claims 1 to 7, the system-on-chip (10) is configured such that the processing unit (1022) controls a memory controller (101) that controls the rewritable non-volatile memory (12). Claim 14 A method for securely recording an object in a rewriteable non-volatile memory (12) located outside of a system-on-chip (10) and connected to the system, wherein the system-on-chip (10) includes a security element (102) comprising a processing unit (1022) configured to execute a security operating system and transmit instructions to the rewriteable non-volatile memory (12), and the security element (102) further includes a security volatile memory (1026) as well as a security non-volatile memory (1024), and the method is characterized by including: a step (E420) of instructing the recording of the identifier of the current version of the object in a private directory stored in the rewriteable non-volatile memory (12) in association with the identifier of the object; a step (E420) of instructing the update of the identifier of the current version of the private directory in the private directory stored in the rewriteable non-volatile memory (12); and a step (E430) of instructing the recording of the identifier of the current version of the private directory in the security non-volatile memory (1024) of the security element. method. Claim 15 A method according to claim 14, comprising a step of verifying the currentness of an object stored in the rewritable non-volatile memory (12), wherein the verifying step comprises: - a step of creating a copy of the private directory and the object in the security volatile memory (1026) of the security element (E22); - a step of comparing the identifier of the current version of the private directory stored in the copy of the private directory with the identifier of the current version of the private directory stored in the security non-volatile memory (1024) of the security element (E24); and - a step of comparing the identifier of the current version of the copy of the object with the identifier of the version of the object stored in the copy of the private directory (E28) to verify the currentness of the object if identity exists. Claim 16 A method implemented in claim 14 or 15 at the time of boot-up (E20) of the processing unit (1022) of the security element (102). Claim 17 A method according to claim 14 or 15, wherein the identifier of the current version of the object and / or the identifier of the current version of the dedicated directory is a version number. Claim 18 A method according to claim 14 or 15, wherein the identifier of the current version of the object and / or the identifier of the current version of the private directory is a signature or checksum that uniquely identifies its version, calculated based on the object and / or the private directory. Claim 19 A method according to claim 14 or 15, further comprising a step of writing data to be used to update an object in a “rollforward” type zone within the rewriteable non-volatile memory (12). Claim 20 A method according to claim 14 or 15, wherein a first comparison function and a second comparison function are implemented to determine whether a version identifier corresponds to a current version or to a previous version, wherein the first comparison function is configured to determine whether values ​​are identical, and the second comparison function is configured to determine whether the version is strictly higher or strictly lower than the current version. Claim 21 A method according to claim 15, comprising the step (E26) of updating the version and / or content of the object when a difference is detected during the comparison step (E28) between the identifier of the current version of the copy of the object and the identifier of the version of the object stored in the copy of the dedicated directory.

Images