METHOD FOR LOCKING A ZONE OF A REWRITERABLE NON-VOIDANT MEMORY AND ELECTRONIC DEVICE FOR EXECUTING THE METHOD

Description

TECHNICAL FIELD

[0001] At least one embodiment relates to a method for locking a non-volatile rewritable memory of an electronic device. At least one other embodiment relates to an electronic device implementing said method. STATE OF PRIOR ART

[0002] Many electronic devices (e.g., smartphones, computers, connected objects, etc.) include software. The software in these devices is often divided into two parts: startup software and application software.

[0003] In modern electronic devices, it is common practice to store boot and application software in external non-volatile rewritable memory (hereafter referred to as MNVR), such as EEPROM (Electronically Erasable Programmable ROM). NAND flash memory is a specific example of EEPROM. Unlike volatile RAM (Random Access Memory), such memory does not require a power supply to retain data, e.g., DDR (Double Data Rate) memory. Therefore, the data is not erased when the power supply to the memory is disconnected.

[0004] When an electronic device is powered on, the boot software stored in the MNVR memory is loaded by a bootloader into the device's RAM for execution by the device's processor. A bootloader is a specialized software program whose role is to transfer the device's startup data, stored, for example, in the MNVR, into RAM. For simplicity, we will use the English term "bootloader" in the following text.

[0005] Thus, the bootloader usually starts immediately after the electronic device is powered on or restarted.

[0006] Such electronic devices are particularly vulnerable to attacks such as erasure or reprogramming, especially when the MNVR memory is used as a boot device. To protect the software stored in the MNVR memory from erasure or reprogramming, write-protecting certain memory areas is a common practice. For example, one-time programmable (OTP) memory is used in some memory areas. An OTP memory area can therefore only be programmed once, preventing any modification of the software stored in that area. Other areas of the MNVR memory can be protected against modification using passwords. Such protections prevent unauthorized third parties from modifying the software stored in the MNVR memory.

[0007] Furthermore, it is also known to secure the startup phase of the electronic device in order to detect any potential modification. For this purpose, a startup process using a trust chain is known. Such a startup process operates in stages, with a signature verification mechanism at each stage.

[0008] However, such protections (i.e., OTP, password protection, etc.) hinder software updates and hardware maintenance of the MNVR memory. On the one hand, the software, particularly the application software, needs to be updated regularly. It must therefore be replaceable with newer versions. Modifying access to the MNVR memory is thus necessary during the update process. On the other hand, hardware maintenance of the MNVR memory is also required. In the specific case of Flash memory, this maintenance uses, for example, a UBI (Unsorted Block Images) file management system. The associated maintenance mechanisms ensure, among other things, the management of defective areas and wear leveling.However, to perform this maintenance, the file management system used needs write access to the MNVR memory during maintenance phases, for example to reallocate a defective memory area by rewriting it to another memory area.

[0009] Document WO 2017 / 188976 A1 describes a method for disabling the hardware write lock of a region in non-volatile memory in response to a reset of an electronic device, and for hardware write locking of the region when there is no update code for a portion of boot code.

[0010] Document EP 3 511 826 A1 describes a non-volatile memory configured with a block comprising a first and a second part, and a method for updating one selected of the first and second parts with the updated information.

[0011] It is desirable to overcome the aforementioned drawbacks of the state of the art.

[0012] In particular, it is desirable to propose a process that protects the MNVR memory against attacks and in particular attempts to modify or erase the software, especially the application software, while facilitating its updating and, where necessary, its hardware maintenance. DESCRIPTION OF THE INVENTION

[0013] The invention relates to a method for locking a rewritable, non-volatile memory in an electronic device. The method comprises: perform a first initialization step of the electronic device; select a memory area of ​​said non-volatile rewritable memory from a set of N memory areas of said non-volatile rewritable memory, each of said N memory areas containing content, N being an integer ≥ 2, the selected memory area containing the most recent version of said content and in the case where M memory areas contain said most recent version of said content, M being an integer belonging to [2; N], then select from said M memory areas, the memory area whose previous selection is the oldest; lock said selected memory area by a lock called volatile locking, said locking being deactivated only by a power-off of the memory; and perform a second initialization step of the electronic device using content stored in said selected memory area.

[0014] By locking at least one memory area, the process protects the MNVR memory against attacks, including attempts to modify or erase content, while facilitating possible updates to said content through unlocked memory areas.

[0015] In a particular embodiment, the process further includes hardware maintenance of said N memory areas before any locking of said selected memory area.

[0016] In a particular embodiment, performing a first initialization step of the electronic device includes: Authenticate, by a secure initial boot, a first boot program stored in a first memory area of ​​said non-volatile rewritable memory; start said first boot program; authenticate, by said first boot program, a second boot program stored in a second memory area of ​​said non-volatile rewritable memory different from said first area; start said second boot program; and authenticate, by said second boot program, for each of said N memory areas, the stored content.

[0017] In a particular embodiment, locking said selected memory area by volatile locking further includes locking said second memory area by volatile locking.

[0018] In a particular embodiment, the method further includes hardware maintenance of said second memory area before any volatile locking of said second memory area.

[0019] In a particular embodiment, said rewritable non-volatile memory is a NAND Flash memory.

[0020] In a particular embodiment, said first memory area is a uniquely programmable memory.

[0021] In one particular embodiment, said content is application software and the second initialization step of the electronic device includes starting said application software.

[0022] In a particular embodiment, the method further comprises, after the step of performing a second initialization step of the electronic device using the content stored in said selected memory area: determine that an update is necessary; select from the set of N memory areas at least one unlocked memory area; load a new version of the content into said at least one selected unlocked memory area; restart said electronic device.

[0023] An electronic device comprising rewritable non-volatile memory and at least one processor is also described. The electronic device is configured to: perform a first initialization step of the electronic device; select a memory area of ​​said non-volatile rewritable memory from a set of N memory areas of said non-volatile rewritable memory, each of said N memory areas containing content, N being an integer ≥ 2, the selected memory area being a memory area containing the most recent version of said content, and in the case where M memory areas contain said most recent version of said content, M being an integer belonging to [2; N], then select, from said M memory areas, the memory area whose previous selection is the oldest; lock said selected memory area by a lock, called a volatile lock, said lock being deactivated only by a power-off of the memory; and perform a second initialization step of the electronic device using content stored in said selected memory area.

[0024] The electronic device is specifically configured to implement the process according to any one of the preceding embodiments.

[0025] A computer program product is described. It includes instructions for implementing the locking procedure according to any of the preceding embodiments, when said program is executed by a processor.

[0026] A storage medium is described. It stores a computer program comprising instructions to implement the locking process according to any of the preceding embodiments, when said program is executed by a processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The features of the invention mentioned above, as well as others, will become clearer upon reading the following description of an exemplary embodiment, said description being made in relation to the accompanying drawings, among which: [ Fig. 1 ] schematically illustrates a hardware architecture of an electronic device according to a particular embodiment; [ Fig. 2 ] schematically illustrates, according to a particular embodiment, a hardware architecture of a component of the electronic device, said component being connected to a rewritable non-volatile memory; Fig. 3 ] schematically illustrates different areas of rewritable non-volatile memory according to a particular embodiment; [ Fig. 4 ] illustrates a method for locking a non-volatile rewritable memory of an electronic device according to a particular embodiment; [ Fig. 5 ] illustrates in detail a step in the process of locking a non-volatile rewritable memory according to a particular embodiment; [ Fig. 6 ] illustrates a method for updating the content stored in rewritable non-volatile memory according to a particular embodiment; [ Fig. 7 ] is a sequence diagram illustrating the content update and locking processes according to a first embodiment; and, [ Fig. 8 ] is a sequence diagram illustrating the content update and locking processes according to a second embodiment. DETAILED DESCRIPTION OF IMPLEMENTATION METHODS

[0028] There Fig. 1 schematically illustrates a hardware architecture of a connected electronic device 1 capable of implementing the invention, comprising a system-on-a-chip (SoC) component 10 connected to an external non-volatile rewritable memory MNVR 12. On the Fig. 1 The electronic device 1 is a mobile phone. However, the electronic device can be of any other type (e.g., computer, embedded system, connected object, etc.). The electronic device 1 is connected to a server 3 via a network 2. The electronic device 1 is, for example, a smartphone. The communication network 2 is, for example, a 3G, 4G, or 5G network, or an xDSL or fiber optic network.

[0029] There Fig.2 This schematically illustrates a hardware architecture of component 10 according to a specific embodiment. Component 10 is connected to the MNVR 12, for example, as an EEPROM-based memory (Electronically Erasable Programmable ROM). In one particular embodiment, the MNVR 12 is a NAND Flash memory. In another particular embodiment, the MNVR 12 is an eMMC (embedded MultiMedia Card) type memory, which could be a NAND Flash memory coupled with a memory controller. In the case of an eMMC-type MNVR 12, volatile or non-permanent locking mechanisms dedicated to eMMC can also be used in certain embodiments. These mechanisms are, for example, based on a feature known as a Replay Protected Memory Block.The component 10 then comprises, connected by a communication bus 100: a processor or CPU (“Central Processing Unit”) 101; a RAM (“Random Access Memory”) 102, e.g. DDR memory; a ROM (“Read Only Memory”) 103; at least one communication interface 104 allowing the electronic device 1 to connect to the communication network 2 and to communicate with the server 3.

[0030] Component 10 also includes control means such as a controller 105 configured to control data exchange with the MNVR 12. Component 10 may include other control means not shown in the Fig.2 e.g., means of controlling RAM and / or ROM.

[0031] The processor 101 is capable of executing instructions loaded into RAM 102 from ROM 103, MNVR memory 12, or a communication network. In particular, when the electronic device 1 is powered on, the processor 101 is capable of reading boot instructions from RAM 102 and executing them. These boot instructions, stored in MNVR memory 12, are loaded into RAM 102 by the bootloader. These instructions form a computer program that causes the processor 101 to implement all or part of the processes described in relation to the Figs. 4 à 6 .

[0032] In general, the electronic device 1 comprises electronic circuitry configured to implement the processes described in relation to the Figs. 4 à 6 .

[0033] There Fig. 3 This schematically illustrates different areas of the MNVR 12 memory according to a specific embodiment. This memory stores boot software as well as at least one piece of content, e.g., application software. To implement a boot process using a chain of trust, the MNVR 12 memory includes a first memory area, ZM1, in which a first boot software module, FSBL (First Stage BootLoader), is stored. This module starts after the electronic device 1 starts. Generally, the FSBL is very small and performs minimal initializations of the hardware, e.g., initialization of the memory controllers. Typically, it does not include an operating system. This memory area, ZM1, is advantageously a one-time program (OTP) memory area.The MNVR 12 memory includes a second memory area ZM2 in which a second software module, SSBL (Secondary Stage BootLoader), is stored. This second software module completes the initialization of the electronic device 1 and manages all or part of the content update, such as the application software. Generally, the second SSBL software module includes a lightweight operating system to offer more functionality than the FSBL while remaining compact. The MNVR 12 memory then includes a plurality of N memory areas ZMA1 to ZMAN, each containing content LA1 to LAN, such as application firmware, where N is an integer greater than or equal to 2. In a particular embodiment, LA1 to LAN are identical or different versions of the same content, e.g., the same application software.For example, LA1 to LAk can be version "m" of the content, and LAk+1 to LAN can be a more recent version, e.g., version "m+1" of the same content, where k is an integer in the range [1; N-1] and "m" is a version identifier, e.g., "m" is a positive integer defined such that the larger "m" is, the more recent the version of the content. In one embodiment, the content is application software based on a Linux operating system (e.g., Kernel, RootFS). In other embodiments, the content comprises one or more modules of the application software. This could involve updating only a portion of the application software by receiving a new module, or it could be a module associated with a new component added to the device (e.g., mass storage such as a hard drive).In one variant, the content is low-level software such as firmware or a portion of firmware, for example, the driver for a Wi-Fi chipset. In another variant, the content is maintenance software for updating certain parameters of the electronic device that cannot be modified by the application software. Optionally, the MNVR 12 memory can include other memory areas, such as a BAL memory area storing data to be exchanged between the content stored in the ZMA1 to ZMAN memory areas and the SSBL.

[0034] To detect any unauthorized modification of the MNVR 12 memory, a chain-of-trust boot process is implemented. For this purpose, checksums are used to authenticate the different modules (FSBL, SSBL, and LAi, i∈[1:N]). In one example, the FSBL is authenticated by a secure initial boot of component 10. If authentication is successful, the FSBL boots. Next, the FSBL authenticates the SSBL. If authentication is also successful, the SSBL boots. It, in turn, authenticates the contents stored in each memory area from ZMA1 to ZMAN.

[0035] There Fig. 4 illustrates a method for locking a rewritable non-volatile memory 12 of an electronic device 1 according to a particular embodiment. The method is described for N=2. However, the same method can be applied to N>2. The method of the Fig.4 This is described in the specific case where the memory areas ZMAi, i∈[1:N] contain application software. However, the process can be generalized and applied to other types of content, e.g., other types of internal software (firmware). The electronic device 1 starts, for example, after being powered on, or restarts, e.g., after a software update. During step S10, the processor 101 performs an initial initialization step of the electronic device 1. This step generally includes launching boot software. In a particular embodiment, the boot software implements a chain of trust.

[0036] During step S12, the processor 101 selects at least one memory area from among the memory areas containing the application software, i.e., from ZMA1 and ZMA2, to be protected by volatile locking. In one embodiment, the version of the application software stored in ZMA1 is compared to the version of the application software stored in ZMA2. The memory area containing the application software with the most recent version is selected. If both memory areas contain identical versions, the memory area with the oldest previous selection is selected. More generally, in the case of M memory areas containing the most recent version of the application software, where M is an integer in [2, N], the memory area with the oldest previous selection, e.g., following a startup or restart of the electronic device, is selected again.Thus, if both ZMA1 and ZMA2 contain a version m of the application software, then memory area ZMA2 is selected if area ZMA1 was selected the previous time, and vice versa. According to a method not part of the invention, not shown in the figure. Fig.4 The same memory area is always selected, e.g., ZMA1. In this case, it may be necessary to copy the contents of memory area ZMA2 to memory area ZMA1 before volatile locking so that the latest version of the application software can start. Optionally, parameters are also updated in the BAL memory area. For example, an identifier, e.g., an address, of the selected memory area. Generally, in the case of N memory areas, at least one memory area is selected in step S12 to be protected against any changes by volatile locking.

[0037] The process of Fig.4 This can be generalized and applied to other types of content. In this case, during step S12, the processor 101 selects at least one memory area from among the ZMAi memory areas to be protected by volatile locking. In one embodiment, the versions of the content stored in the ZMAi memory areas are compared. The memory area containing the content with the most recent version is selected. If several memory areas contain identical versions, the memory area with the oldest previous selection is selected.

[0038] During step S14, the selected memory area, referred to as the active memory area, is protected against modification by a volatile lock. To this end, the processor 101 sends commands via internal communication means to the MNVR 12 memory, which executes them to lock the selected memory area. The commands sent depend on the MNVR 12 manufacturer. Such a volatile lock can only be deactivated by powering down the said memory area. In an alternative embodiment, the ZM2 (SSBL) memory area and the selected memory area are protected by a volatile lock against modification. The other memory area, which has not been selected, referred to as the inactive memory area, is not protected, i.e., is unlocked. Therefore, this memory area is used for updating the application software, or more generally, the content, as illustrated by the Fig. 6 .

[0039] During an S16 step, the processor 101 performs a second initialization step of the electronic device using the content stored in the selected memory area. For example, it starts the application software stored in the selected memory area, i.e., the active memory area. In another embodiment, when the content includes maintenance software, the processor 101 uses this content and starts the maintenance software in order, for example, to update or modify certain parameters of the electronic device that are not accessible by the application software. In another example, the content corresponds to a software module, and the processor 101 uses this software module to complete its initialization. In yet another example, several memory areas are selected, each containing a different software module to be used in the initialization process of the electronic device. Fig. 5 illustrates in detail step S10 of the locking process according to a particular embodiment.

[0040] During an S100 step, the FSBL is authenticated by the secure initial boot software of component 10. Specifically, an integrity check of the data in memory area ZM1 is performed. This check can be carried out in various ways, such as calculating a checksum (e.g., using SHA256 hash functions) on the data written to memory area ZM1, i.e., on the FSBL. This checksum is then compared to a reference checksum stored, for example, in a header of the FSBL. This reference checksum is usually encrypted, and its decryption is performed using a public key provided by the secure initial boot software. If the authentication is successful, the FSBL starts during an S102 step. Otherwise, the electronic device 1 shuts down during an S104 step.

[0041] During an optional step S106, hardware maintenance of the memory area ZM2, in which the SSBL is stored, is performed before SSBL authentication, for example, using a UBI file system. This hardware maintenance includes, for example, error detection and, if necessary, correction of detected errors, notably using error-correcting codes. However, if such correction using error-correcting codes is no longer possible, e.g., because the number of errors is too high, then the contents of the faulty memory area can be copied by overwriting them to another memory area before the entire contents of the faulty memory area are lost.

[0042] During step S108, the SSBL is authenticated by the FSBL. More specifically, an integrity check of the data in memory area ZM2 is performed. This check can be carried out in various ways, such as calculating a checksum (e.g., using SHA256 hash functions) on the data written to memory area ZM2, i.e., to the SSBL. This checksum is then compared to a reference checksum stored, for example, in the SSBL header. This reference checksum is usually encrypted, and its decryption is performed using a public key provided by the FSBL. If the two checksums are equal, the SSBL is authenticated. If the authentication is successful, the SSBL starts during step S110. Otherwise, electronic device 1 stops during step S104.

[0043] In an optional step S112, hardware maintenance of the memory areas ZMA1 and ZMA2, where application software is stored, is performed before authentication, for example, using the UBI file management system. The same mechanisms (error detection, error correction, copying, etc.) implemented in step S106 can be used in step S112.

[0044] During an S114 step, the content stored in ZMA1 and ZMA2 is authenticated by the SSBL. More specifically, an integrity check of the data present in memory areas ZMA1 and ZMA2 is performed. This check can be carried out in various ways, such as calculating a checksum (e.g., using SHA256-type hash functions) on the data written to each of the memory areas ZMA1 and ZMA2. The checksum calculated on the data written to ZMA1 is then compared to a first reference checksum stored in a header of LA1, and the checksum calculated on the data written to ZMA2 is then compared to a second reference checksum stored in a header of LA2. These first and second reference checksums are generally encrypted, and their decryption is performed using public keys provided by the SSBL.

[0045] If neither ZMA1 nor ZMA2 contains content authenticated by the SSBL (case S114-1), a fallback procedure is implemented during step S116. For example, basic content such as simplified application software stored in a third, permanently protected memory area ZMA3 (e.g., protected by an OTP) can be used by the fallback procedure. If both memory areas ZMA1 and ZMA2 contain content LA1 (or LA2, respectively) that has been authenticated by the SSBL (case S114-2), the process continues at step S12. If only one of the two memory areas ZMA1 or ZMA2 contains content that has been authenticated by the SSBL (case S114-2), the SSBL-authenticated content is copied during step S118 to the memory area where the unauthenticated content is stored.For example, if content LA1 stored in ZMA1 is authenticated by the SSBL while content LA2 stored in ZMA2 is not, the contents of memory area ZMA1 are copied to ZMA2, and vice versa if content LA1 stored in ZMA1 is not authenticated by the SSBL while content LA2 stored in ZMA2 is. Once the copying is complete, the process continues to step S12.

[0046] There Fig. 6 illustrates a method for updating content, e.g., application software, stored in the ZMAi areas of MNVR 12 memory according to a particular embodiment. The method of Fig. 6 This process is described for application software but can be applied to other types of content requiring updates, including other types of software (such as firmware). This process typically occurs in the background while the application software is running.

[0047] If an update is required (step S200), at least one idle, i.e., unlocked, memory area is selected by processor 101 during step S202. If N=2, the memory area not selected in step S12 is the idle memory area selected in step S202. If there are multiple idle memory areas, at least one idle, i.e., unlocked, memory area is selected. In one variant, all idle areas are selected. Processor 101 can be notified by a server that a new version of the application software is available. In another embodiment, processor 101 can periodically query the server to determine if a new version is available. In both cases, processor 101 retrieves this new version from the server.

[0048] In step S204, processor 101 loads the new version of the application software into the inactive memory area(s) selected in step S202, which are therefore not protected by volatile locking. This new application software is loaded by processor 101, for example, from RAM 102 via internal communication means or directly, i.e., without going through RAM.

[0049] In step S206, processor 101 performs a check to verify that the loading of the new application software version into the selected idle memory area(s) was successful. Specifically, an integrity check of the data in the selected idle memory area is performed. This check can be carried out in various ways, such as calculating a checksum on the data written to the idle memory area. This checksum is then compared to a reference checksum calculated on the data corresponding to the new application software as obtained by processor 101. Alternatively, the check is performed by a complete reread and comparison of the raw data in the selected idle memory area with the data stored locally in RAM 102 that corresponds to the new application software as obtained by processor 101.If the new version was not loaded correctly, the process restarts at step S204. If the new version was successfully loaded, the process continues at step S208. At step S208, the update process ends, for example, by restarting electronic device 1 to use the new version of the application software.

[0050] In an alternative embodiment not shown on the Fig. 6 The processor 101 detects the availability of a new version of content, such as application software, stored on a server and informs the second software module, SSBL, on a network. Alternatively, the processor is informed by the server of the availability of a new version of content and informs the second software module, SSBL. For this purpose, the BAL memory area is advantageously used to inform the SSBL of the availability of a new version of content. The address of the server from which to retrieve this new version can be specified in the BAL. The SSBL is adapted to retrieve the server address from the BAL during a reboot, connect to said server, receive this new version of the content, and process it to complete the reboot process.

[0051] The behavior of the electronic device 1, and more specifically of the MNVR memory 12, during an update phase will now be described. With reference to the sequence diagrams of the Figs 7 And 8 The description relates to a scenario where initially the ZMA1 memory area is active and therefore protected against all modifications by volatile locking, while the ZMA2 area is inactive and therefore not protected against all modifications. On the Figs 7 And 8 ZMA1 and ZMA2 initially include the same version m of the content, in this case, the application software. However, ZMA2 could include an older version, e.g., version (m-1). In the example of the Fig. 7 The two memory areas can be protected alternately by volatile locking, whereas in the Fig. 8 Only the ZMA1 memory area can be protected by volatile locking.

[0052] With reference to the Fig. 7 At time t0, an update is performed, e.g., because a version (m+1) of the application software is available. Following this update, and therefore the loading of the new version (m+1) of the application software into the inactive memory area, i.e., ZMA2, at step S204, the ZMA2 memory area, which is still unlocked, contains the new version m+1 of the software. The ZMA1 memory area, on the other hand, has not been modified by the update process.

[0053] At time t1, an S10 restart of the electronic device 1 is performed following the update. The restart notably removes the volatile lock from the memory area ZMA1 and, if applicable, ZM2. The restart includes the implementation of the locking procedure described with reference to the Fig. 5 Assuming that everything goes smoothly, i.e. that the software stored in the different memory areas of MNVR 12 is authenticated, the FSBL starts at time t2, then the SSBL starts at time t3.

[0054] Memory areas ZMA1 and ZMA2 are analyzed. Memory area ZMA2, which contains a newer version of the application software, is selected (S12) at time t4 and becomes the new active memory area. ZMA2, and if necessary ZM2, are then protected (S14) by volatile locking (S14) at time t5. The new version of the application software stored in ZMA2 starts (S16) at time t6.

[0055] During a future update, the new version of the application software will be loaded into the unlocked memory area, namely ZMA1. Thus, memory areas ZMA1 and ZMA2 are alternately protected by volatile locking. This alternation is advantageous because it allows for more even wear across the memory areas.

[0056] In the event of a malicious attack, the memory area containing the application software cannot be modified or erased. However, an unlocked memory area remains available for updating to a new software version. This memory area can be modified or erased by a malicious third party. In this case, it will not be authenticated during step S114, and any installed software will fail to start.

[0057] With reference to the Fig. 8 At time t0, an update is performed, e.g., because a version (m+1) of the application software is available. Following this update, and therefore the loading of the new version (m+1) of the application software into the inactive memory area, i.e., ZMA2, at step S204, the ZMA2 memory area, which is still unlocked, contains the new version m+1 of the software. The ZMA1 memory area, on the other hand, has not been modified by the update process.

[0058] At time t1, an S10 restart of the electronic device 1 is performed following the update. The restart notably removes the volatile lock from the memory area ZMA1 and, if applicable, ZM2. The restart includes the implementation of the locking procedure described with reference to the Fig. 5Assuming that everything goes smoothly, i.e. that the software stored in the different memory areas of MNVR 12 is authenticated, the FSBL starts at time t2, then the SSBL starts at time t3.

[0059] Since the ZMA1 memory area can be protected by volatile locking, the ZMA1 memory area is necessarily selected S12 and the application software updated in ZMA2 is copied at a time t4 into ZMA1 prior to its locking.

[0060] ZMA1 and, if applicable, ZM2 are then protected S14 by volatile locking at time t5. The new version of application software stored in ZMA1 starts S16 at time t6.

Claims

1. A method for locking a rewritable non-volatile memory (12) of an electronic device, said method comprising: - performing (S10) a first initialisation step of the electronic device; - selecting (S12) a memory area of said rewritable non-volatile memory from a set of N memory areas of said rewritable non-volatile memory, each of said N memory areas comprising a content, N being an integer ≥ 2, the selected memory area comprising a most recent version of said content; the method being characterised in that it comprises, in the case where M memory areas comprise said most recent version of said content, M being an integer belonging to [2; N], then selecting from said M memory areas, the memory area whose previous selection is the oldest; - locking (S14) said selected memory area by a lock called volatile lock, said lock being deactivated only by a power-off of the memory; and - performing a second initialisation step of the electronic device by using (S16) a content stored in said selected memory area.

2. The method according to claim 1, further comprising a hardware maintenance of said N memory areas before any locking of said selected memory area, the hardware maintenance comprising an error detection and, where appropriate, a correction of the detected errors.

3. The method according to one of claims 1 and 2, wherein performing (S10) a first initialisation step of the electronic device comprises: - Authenticating, by a secure initial boot, a first boot software stored in a first memory area (ZM1) of said rewritable non-volatile memory, said first memory area (ZM1) being different from the N memory areas of said rewritable non-volatile memory; - booting said first boot software; - authenticating, by said first boot software, a second boot software stored in a second memory area (ZM2) of said rewritable non-volatile memory different from said first memory area (ZM1), said second memory area (ZM2) being different from the N memory areas of said rewritable non-volatile memory; - booting said second boot software; and - authenticating, by said second boot software, for each of said N memory areas, the content stored in each of said N memory areas.

4. The method according to claim 3, wherein locking (S14) said selected memory area by volatile lock further comprises locking (S14) said second memory area (ZM2) by volatile lock.

5. The method according to claim 4, further comprising a hardware maintenance of said second memory area (ZM2) before any volatile locking of said second memory area (ZM2), the hardware maintenance comprising an error detection and, where appropriate, a correction of the detected errors.

6. The method according to one of claims 1 to 5, wherein said rewritable non-volatile memory is a NAND Flash memory and / or an eMMC memory.

7. The method according to one of claims 3 to 6, wherein said first memory area (ZM1) is a one-time programmable memory.

8. The method according to any one of the preceding claims, wherein said content is an application software and the second initialisation step of the electronic device comprises booting said application software.

9. The method according to one of claims 1 to 8, further comprising after the step of performing (S16) a second initialisation step of the electronic device by using the content stored in said selected memory area: - determining that an update is necessary; - selecting from the set of N memory areas at least one non-locked memory area; - loading a new version of the content into said at least one selected non-locked memory area; - rebooting said electronic device.

10. An electronic device comprising a rewritable non-volatile memory (12) and at least one processor configured to: - perform (S10) a first initialisation step of the electronic device; - select (S12) a memory area of said rewritable non-volatile memory from a set of N memory areas of said rewritable non-volatile memory, each of said N memory areas comprising a content, N being an integer ≥ 2, the selected memory area being a memory area comprising a most recent version of said content; said device being characterised in that the processor is further configured to, in the case where M memory areas comprise said most recent version of said content, M being an integer belonging to [2; N], then select from said M memory areas, the memory area whose previous selection is the oldest; - lock (S14) said selected memory area by a lock, called volatile lock, said lock being deactivated only by a power-off of the memory; and - perform (S16) a second initialisation step of the electronic device by using a content stored in said selected memory area.

11. The electronic device according to claim 10, characterised in that it is configured to implement the method according to any one of claims 1 to 9.

12. A computer program product characterised in that it comprises instructions to implement the locking method according to any one of claims 1 to 9, when said program is executed by a processor.

13. A storage medium characterised in that it stores a computer program comprising instructions to implement the locking method according to any one of claims 1 to 9, when said program is executed by a processor.