METHOD FOR BACKING UP AND RESTORING DATA OF A SECURE ELEMENT

Abstract

The present invention notably relates to a method for saving data stored in memory in a non-volatile memory (2) of a secure element (1), the method being characterized by steps for generating a backup image (IS) containing the data stored in memory in the non-volatile memory (2) and for writing the backup image (IS) into the non-volatile memory (2) of the secure element (1).

The present invention also relates to a method for restoring saved data.

Claims

1. A method for backup of data stored in memory in a non-volatile memory of a secure element, the method being characterized by steps of: defragmenting an area of the non-volatile memory containing at least one portion of the data to be saved so as to form, in the area, an occupied region containing said portion of the data and a free region, compressing the portion of the data contained in the occupied region, after de fragmentation, compressing the contents of the free region by means of a compression algorithm different from the one used for compressing the portion of the data contained in the occupied region, generating a backup image containing the compressed data, writing the backup image into the non-volatile memory of the secure element.

2. The method according to claim 1, wherein the compressing is applied on localized data in several predetermined areas of the non-volatile memory, so as to produce several compressed blocks, the generation of the backup image comprising a concatenation of the compressed blocks.

3. The method according to claim 2, wherein the area contains objects intended to be handled by a program coded in an object language, and wherein the objects are compressed by a dictionary.

4. The method according to claim 3, comprising generating a compression dictionary from the objects to be compressed, wherein compressing the objects is carried out by means of the generated dictionary.

5. The method according to claim 1, wherein compressing the contents of the free region comprises applying a run-length coding of these contents.

6. The method according to claim 1, wherein the data to be saved are contained in at least one predetermined area of the non-volatile memory, and wherein the method comprises generating and storing in the non-volatile memory metadata comprising, for each area, an address of the area.

7. The method according to claim 6, wherein the metadata comprise, for at least one of the areas, integrity control data of the area, or a size of the area.

8. The method according to claim 7, comprising generating and storing in the non-volatile memory integrity control data of the metadata.

9. The method according to claim 8, comprising generating and storing in the non-volatile memory integrity control data of the generated backup image.

10. A method for resetting a secure element comprising a non-volatile memory storing in memory data, the method comprising the steps of: saving data by means of the method according to claim 1, restoring the saved data.

11. A computer program product comprising code instructions of a program for executing steps of the method according claim 1, when this program is executed by at least one processor.

12. A secure element comprising: a non-volatile memory, at least one processor configured for saving data stored in memory in the non-volatile memory, the secure element wherein the processor is configured for: defragmenting an area of the non-volatile memory containing at least one portion of the data to be saved so as to form, in the area an occupied region containing said portion of the data and a free region, compressing the portion of the data contained in the occupied region, after de fragmentation, compressing the contents of the free region by means of a compression algorithm different from the one used for compressing the portion of the data contained in the occupied region, generating a backup image containing the compressed data, writing into the non-volatile memory the backup image.

Description

DESCRIPTION OF THE FIGURES

[0042] Other features, objects and advantages of the invention will become apparent from the following description, which is purely illustrative and non-limiting and which should be read with reference to the appended drawings wherein:

[0043] FIG. 1 schematically illustrates a secure element.

[0044] FIG. 2 schematically illustrates the contents of a non-volatile memory of a secure element.

[0045] FIG. 3 is a flow chart of steps of a method for saving data stored in memory in a secure element, according to an embodiment of the invention.

[0046] FIG. 4 is a flow chart of steps of a method for restoring data towards a secure element, according to an embodiment of the invention.

[0047] FIG. 5 illustrates the contents of a backup image IS generated by the backup method for which the steps are shown in FIG. 3.

[0048] On the whole of the figures, similar elements bear identical references.

DETAILED DESCRIPTION OF THE INVENTION

[0049] With reference to FIG. 1, a secure element 1 comprises a non-volatile memory 2, a volatile memory 3, at least one processor 4 and a communication interface 5 with a terminal 6.

[0050] The non-volatile memory 2 comprises one or several memory element(s). A memory element may be any type capable of storing in memory data persistently: flash, EEPROM, etc. Preferably, the non-volatile memory 2 is permanently integrated into the secure element 1 (in the sense that it is not removable).

[0051] The volatile memory 3 comprises one or several volatile memory unit(s) 3, for example of the RAM type. The volatile memory 3 is able to store in memory data temporarily. The volatile memory 3 is permanently integrated into the secure element 1 (in the sense that it is not removable).

[0052] The non-volatile memory 2 stores in memory an operating system and at least one application coded in an object language. The operating system, or more simply the OS in the following, is configured for controlling the execution of each application of the secure element 1, when it is executed by the processor 4.

[0053] The non-volatile memory 2 moreover stores in memory a backup program, and a restoration program, the operations of which will be described further on.

[0054] The processor 4 is configured for accessing the volatile memory 3 and the non-volatile memory 2, and for executing the OS, the applications, and the backup and restoration programs.

[0055] The processor 4 is moreover connected to the communication interface 5.

[0056] The secure element 1 assumes the shape of a chip card. The secure element is for example a smart card, an eSIM or eSE. The element may be directly welded to the terminal 6.

[0057] The terminal 6 comprises a communication interface 7 for communicating with the communication interface 5 of the secure element 1. The terminal 6 comprises a suitable housing for receiving the secure element, and connections for being electrically connected to connections of the secure element.

[0058] The terminal 6 moreover comprises at least one processor 8 configured for executing at least one application, a so called “host” application, configured for communicating with the OS or an application executed by the processor of the secure element 1, via the communication interface 5. Generally, the terminal 6 comprises a plurality of host applications, for example an application controlling a biometric sensor of the terminal 6.

[0059] The terminal 6 is a user personal piece of equipment, such as a smartphone, a tablet, a telephone, etc.

[0060] Data Backup

[0061] One or several area(s) of the non-volatile memory 2, containing data to be saved, are predetermined. These areas are subsequently called “source areas”. The source areas may not be contiguous in the non-volatile memory 2.

[0062] In the example illustrated in FIG. 2, the non-volatile memory 2 comprises four source areas Zi, i ranging from 1 to 4.

[0063] The address of the beginning in the non-volatile memory 2 of each source area Zi is predetermined, as well as the size of the source area and/or its end address.

[0064] A backup area ZS is also predetermined in the non-volatile memory 2, different from the source areas.

[0065] The data to be saved comprise useful data written in the non-volatile memory 2 by the OS. A source area containing useful data of the OS, described subsequently by “source area of the OS”, is typically accessible in reading and in writing by the OS (as opposed to an accessible read only area comprising the binary of the actual operating system, and which is not a source area, i.e. an area the contents of which is to be saved). In the example illustrated in FIG. 2, the areas Z1 and Z2 are source areas of the OS.

[0066] The data to be saved moreover comprise “application” data, i.e. useful data handled by at least one application of the secure element 1. The source areas containing application data are described subsequently as “application source areas”.

[0067] At least one application source area is or contains a object heap. When an application coded in an object language is executed by the processor 4 of the secure element 1, this application may write objects in the corresponding object heap, access them later by reading, and deleting them from the object heap.

[0068] The object heap may be shared by several applications coded in a same object language. In the example illustrated in FIG. 2, the areas Z3 and Z4 are application source areas. Both of these areas, contiguous areas, in reality form a single area comprising the object heap (subsequently it will be seen that both of these areas Z3 and Z4 are processed differently during the backup).

[0069] In a particular embodiment, the operating system is Java Card and the object language is the Java language. An object heap is allocated in the non-volatile memory 2 for all the applications coded in Java Card.

[0070] With reference to FIG. 3, a backup of the data contained in the source areas Z1 to Z4 comprises the following steps.

[0071] The processor 8 of the terminal 6 generates a backup command and send it to the secure element 1 via the communication interfaces 7 and 5. The command is for example of the ADPU type.

[0072] The resetting command is received by the communication interface 5, which transmits the command to the processor 4 so that it is processed by the backup program.

[0073] The backup program compresses 102 the contents of each source area of the OS.

[0074] The compression 102 comprises the allocation, in the volatile memory 3, of a compression buffer, used for temporarily storing the input data to be compressed and the compressed output data. The buffer is of a set and predetermined size. This size is independent of the size of the data to be compressed.

[0075] The compression step 102 uses a compression algorithm by a dictionary.

[0076] In a way known per se, a compression algorithm by a dictionary proceeds with searching for similarities between the data to be compressed and a set of strings contained in a data structure called a “dictionary”. When a similarity is found, the corresponding datum is replaced by a reference to the location of this string in the dictionary. The use of a compression algorithm by a dictionary provides excellent compression levels. Such an algorithm is therefore of particular interest for secure elements having limited storage capacity.

[0077] In particular, a compression algorithm by dictionary provides particularly high compression levels when it is applied to data comprising current schemes or patterns and small sizes. This is the case of data contained in the source areas of the OS or of the applications.

[0078] The compression 102 comprises the generation of a compression dictionary. Usually, such a dictionary is made up beforehand. In the present method, the dictionary is on the contrary made up gradually during the compression 102, and this from the data to be compressed themselves. More specifically, the compression 100 comprises a search for repetitive patterns in the data to be compressed contained in the different source areas of the OS. When a recurrent pattern is detected, it is added to the dictionary.

[0079] Preferably, a compression algorithm by a sliding dictionary is used for the compression 102. In this case, the search for recurrent patterns and the coding of the data in a compressed format are concomitant; the dictionary is dynamically built from data the data to be compressed themselves.

[0080] In order to further improve the efficiency of the compression algorithm, the source areas are virtually concatenated in the allocated buffer so that the algorithm only sees a single block of contiguous data. By virtually concatenating the areas during the compression, the dictionary is not empty at the beginning of the compression of the second source area, but stems from the contents of the first source area.

[0081] Having a dictionary generated from the actual data gives the possibility of not loading onboard an additional dictionary and potentially poorly adapted. Also, the fact of building the dictionary by means of the data to be compressed, like in the case of a sliding dictionary, has the advantage of not having to store in memory a predetermined dictionary in the non-volatile memory 2. This allows minimum consumption of the non-volatile memory 2, and an optimal compression level.

[0082] The compression step 102 produces a compressed block of compressed data, which is written in the backup area ZS defined in the non-volatile memory 2.

[0083] The compression step 102 is applied each of the source areas of the OS Z1 and Z2. With reference to FIG. 5, two corresponding compressed blocks B1 and B2 are produced.

[0084] The compressed blocks B1 and B2 are concatenated in the backup area ZS so as to minimize the space occupied by the whole of the compressed blocks in this backup area ZS.

[0085] Moreover, the backup program launches a de-fragmentation 104 of at least a source area containing data of applications to be saved. The de-fragmentation is typically applied by a de-fragmentation program of the OS.

[0086] In a way known per se, the de-fragmentation 104 displaces the data of applications contained in each source area in the non-volatile memory 2, so as to further group them together. Thus, at the end of the fragmentation 104, each source area of data of applications to be saved consists, in the non-volatile memory 2, of two contiguous regions: an occupied region containing all the data to be saved, and a free region not containing any datum.

[0087] The areas Z3 and Z4 illustrated in FIG. 2 are in reality the occupied region and the free region formed at the end of the de-fragmentation of the source area formed by the union of areas Z3 and Z4.

[0088] For each source de-fragmentated area of application data, the beginning address and the size of each of the two regions of the source area formed (occupied and free) are stored in memory in the volatile memory 3.

[0089] For each source area of data of applications, the backup program compresses 106 the useful data grouped in the occupied region Z3 of said source area.

[0090] The compression 104 is applied identically with the compression 102, for each relevant area of data of application to be saved, therefore possibly with a compression algorithm by a sliding dictionary.

[0091] Each produced compressed block at the end of the compression 106 is concatenated with the compressed block(s) produced at the end of the compression 102, in the backup area ZS of the non-volatile memory 2.

[0092] The objects contained in the occupied region Z3 of the object heap are therefore compressed 106 so as to produce the compressed block B3, which is concatenated with the blocks B1, B2.

[0093] The objects are each a small size header and which varies not very much from one object to the other. Thus, the compression of the objects by means of a compression algorithm by dictionary produces particularly high compression levels.

[0094] Moreover, for each source area of data of applications, the backup program compresses 108 the contents of the free region formed in said source area. In the example of FIG. 2, there is only one free region Z4 concerned by the compression 108.

[0095] The compression algorithm used for the compression 108 of the contents of the free region Z4 is different from the one used for the compression 106 of the data contained in the occupied region Z3.

[0096] Very advantageously, a coding by ranges (“run-length encoding” or RLE) is used for the compression 108.

[0097] Generally, a particular pattern is written in memory in order to notify that a memory unit is free, i.e. not occupied by data (for example, a free region only contains the pattern 0xFF in each of its bytes). Run-length coding is therefore highly efficient for compressing the free region Z4: indeed it is sufficient to indicate the value of the “free” particular pattern and the number of times it is repeated in the free region Z4.

[0098] De-fragmentation 104 gives the possibility of improving the accumulated compression level of the compression steps 106 and 108, since at the end of the de fragmentation, the size of the occupied region Z3 is reduced and the size of the free region Z4 is enlarged.

[0099] The compressed block or the run-length coding B4 produced at the end of the compression 108 is concatenated with the compressed blocks B1, B2, B3 in the backup area ZS of the non-volatile memory 2.

[0100] The different compressed blocks B1 to B4 resulting from the compressions 102, 106 and 108 and concatenated in the backup area ZS of the non-volatile memory 2 form together a backup image IS.

[0101] Further, the backup program calculates 110 information on the integrity control relatively to at least one portion of the data. A piece of control information is for example a cyclic redundancy code (CRC) relating to a portion of the data.

[0102] Integrity control data CRCZ is calculated for each source area Zi. Each piece of integrity control information CRCZ is calculated on the contents of each area Zi before their compression.

[0103] In addition to the backup image IS, are also stored in memory 112 in the backup area ZS of the non-volatile memory 2 metadata M relative to the source areas Zi for which the contents were saved in the backup image IS. The metadata M comprise: [0104] the number N of source areas Zi of the non-volatile memory 2 having been subject to a backup (4 in the example of FIG. 3), [0105] for each source area Zi of index i ranging from 1 to N, a source area descriptor MZi associated, [0106] the size T of the backup image IS generated in the backup area ZS, [0107] integrity control data CRCM relatively to the metadata M, calculated according to the preceding description of step 110.

[0108] The MZi area descriptor associated with each source area Zi comprises: [0109] the address of the source area AZ, [0110] the size TZ of the source area (before compression), [0111] at least one compression parameter CZ used for compressing the data contained in the source area Zi, for example, a field indicating the type of compression algorithm used for compressing the source area Zi (run-length coding for the free region Z4 of the object heap, compression by dictionary for the other areas Z1, Z2, Z3, in the embodiment of FIG. 2). [0112] the piece of integrity control information CRCZ relatively to the source area (before compression); calculated during step 110.

[0113] Each area MZi descriptor therefore relates to a compressed block Bi contained in the backup image IS. For example, the order of the MZi descriptors in the metadata M corresponds to the order of the compressed blocks Bi concatenated in the backup image IS.

[0114] Further, the backup program generates and stores in memory 114 in the backup area ZS a restoration D directive. The restoration directive D is encoded so as to be integrated in a directive interpreter, not necessarily limited to a restoration operation.

[0115] The restoration directive D comprises: [0116] a single restoration identifier ID specific to the directive; this identifier is intended to be read by an interpreter. [0117] the metadata M or the address of the metadata M, [0118] the backup image IS or the address of the backup image IS, [0119] integrity control data CRCD relatively to the restoration directive D, calculated according to the preceding description of step 110.

[0120] The backup program sends back to the terminal 6, and this via the communication interface 5, a status indicating that the backup is finished.

[0121] The contents written into the backup area ZS is illustrated in FIG. 5.

[0122] Data Restoration

[0123] With reference to FIG. 4, the saved data are restored in the non-volatile memory 2 by means of the following steps.

[0124] The processor 8 of the terminal 6 generates a restoration command and sends it to the secure element 1 via the communication interfaces 7 and 5. The command is for example of the ADPU type.

[0125] The restoration command is received 200 by the communication interface 5, which transmits the command to the processor 4 so that it is processed by a restoration program. The restoration program comprises or resorts to an interpreter capable of reading the contents of the restoration directive D.

[0126] The restoration program checks 202 the existence of a backup image IS in the backup area ZS.

[0127] If no backup image IS is found in the backup area ZS, an error message is returned to the terminal 6 via the communication interface 5, and the restoration finishes.

[0128] Otherwise, the restoration program checks 204 the integrity of the backup image IS. To do this, it checks that the value of the integrity control information CRCIS of the backup image IS is in adequacy with the contents of the backup image IS.

[0129] If the restoration program considers that the backup image IS is not intact, an error message is returned to the terminal 6 via the communication interface 5, and the restoration finishes.

[0130] Otherwise, the restoration program checks 206 the integrity of the restoration directive D. To do this, it checks that the value of the integrity control information CRCD of the restoration directive D is in adequacy with the contents of the restoration directive D.

[0131] If the restoration program considers that the restoration directive D is not intact, an error message is returned to the terminal 6 via the communication interface 5, and the restoration finishes. This may occur notably after an external attack having corrupted the contents of the restoration directive D.

[0132] Otherwise, the restoration program reconfigures 208 the secure element 1 in an busy mode. In the busy mode, the OS does not process all or part of the external commands from the terminal 6 which are received by the secure element 1 via the communication interface 5.

[0133] For example, in the busy mode, the OS is configured so as to not process an application external command of the secure element 1. In this case, the OS is limited to sending back to the terminal 6 a message indicating the reconfiguration in the busy mode.

[0134] Moreover, the restoration program checks the integrity of the metadata M. To do this, it checks that the value of the integrity control information CRCM of the metadata M is in adequacy with the contents of the metadata M.

[0135] If the restoration program considers that the metadata M are not intact, an error message is returned to the terminal 6 via the communication interface 5, and the restoration finishes. This may occur notably after an external attack having corrupted the contents of the metadata M.

[0136] Otherwise, the restoration program decompresses 210 each compressed block contained in the backup image IS.

[0137] For each compressed block Bi, i ranging from 1 to N, the restoration program reads the area descriptor MZi associated with this compressed block Bi. The decompression algorithm used for decompressing the compressed block is inferred from the compression parameter CZ contained in the descriptor MZi associated with the block Bi.

[0138] The contents of the block Bi is written, after decompression, into the non-volatile memory 2 at the address AZ indicated in the area descriptor MZi.

[0139] Preferably, the compression algorithm used during the backup is of the asymmetrical type: in this case, the compression is performing in terms of yield but relatively slow, while the decompression is fast.

[0140] In a similar way to the compression, the decompression 210 comprises the allocation of a decompression buffer in the volatile memory 3. The decompression buffer represents the context required for applying the decompression algorithm. It is in the volatile memory 3 for promoting the rapidity of the decompression operation.

[0141] The decompression buffer is coupled with an output buffer with the size of a page of the non-volatile memory 2.

[0142] During decompression 210, the restoration program reads the data contained in the backup image IS and copies them into the decompression buffer. The result of the decompression of each compressed block is temporarily stored in memory in the allocated output buffer. Once the output buffer is full, its contents are copied into a page of the non-volatile memory 2. The use of this additional buffer gives the possibility of not stressing the non-volatile memory 2 during the writing of the decompressed data. It provides better endurance of the product in the case of a frequent restoration operation.

[0143] In order to decompress a block which was compressed by means of a coding per range, a writing into non-volatile memory 2 may be directly made. The restoration program reads, in the relevant block of the backup image IS, the value of the recurrent pattern which was found in the free region, as well as the number of its occurrences in the free region in order to proceed with the writing of the pattern.

[0144] The OS sends back a successful status to the terminal 6 in order to inform it on the course of the operation.

[0145] At the end of the decompression step, the same source areas Z1 to Z4 are assume to have the same contents as before the compressions applied during the backup. Any modification of the contents of a source area, between the end of the backup and the beginning of the restoration has been deleted.

[0146] The restoration program checks 212 the integrity of each source area thereby restored. To do this, it checks that the value of the integrity control information CRCZ contained in the descriptor Zi of a given area and associated with the compressed block Bi corresponds to the contents which was rewritten into the non-volatile memory 2 at the address AZ indicated in the first descriptor Zi.

[0147] If the restoration program considers that a rewritten area Zi in the non-volatile memory 2 is not intact, an error message is returned to the terminal 6 via the communication interface 5, and the restoration finishes. This may notably occur after an external attack having corrupted the contents of the backup image IS.

[0148] If the restoration program considers that all the rewritten source areas Z1 to Z4 have intact contents, then these areas have been restored successfully.

[0149] The restoration program reconfigures the secure element 1 in an “available” (not busy) mode in which the external commands received by the secure element 1 may be processed by the OS.

[0150] The restoration program sends back 216 to the terminal 6 a status indicating that the restoration took place successfully.

[0151] The reconfiguration in the “available” mode for example comprises a complete restarting 214 of the OS (hardware reset). In this case, the sending of the status is carried out with this complete restarting.

[0152] The restoration operation endangers the data of the OS and the application data. The applications are themselves in an unstable state during the restoration. The configuration of the secure element 1 in the busy mode during restoration gives the possibility of protecting the secure element 1 against corruption of the non-volatile memory 2 generated by the execution of an external command during restoration.

[0153] However, it may happen that the secure element 1 is accidentally cut off during the restoration. An independent mechanism of the OS of the “roll forward” type is used for guaranteeing the atomicity and the security of the restoration. A begun restoration will resume even after a cut off of the current. There will be no corruption in the case of a loss of power supply.

[0154] In the case of a current loss which occurs after switching the OS into the busy mode, the OS will restart in the same dedicated state, and will resume the restoration of the image from the start. This mechanism will therefore guarantee the atomicity of the restoration.

[0155] Secure Element Factory Reset

[0156] Generally, three different actors intervene on a secure element 1: [0157] The supplier, which manufactures the secure element 1. [0158] The transmitter, which defines a minimal set of data allowing proper operation of the secure element 1. The minimum set of data thus comprises the binary of the OS, and optionally at least one application approved by the transmitter. When the non-volatile memory 2 only contains this minimum set of data, conventionally it is stated that the secure element 1 is in an “ex-works” state. [0159] From among the third parties which access in reading and/or writing to the non-volatile memory 2, the third parties may comprise: [0160] a final user, which uses the functionalities provided by the secure element 1, and/or [0161] other actors, triggering remote installations of applications in the non-volatile memory 2 (for example by OTA).

[0162] The backup and restoration methods, described earlier advantageously find application for factory resetting a secure element 1.

[0163] The backup is thus for example applied once by the transmitter, while the secure element 1 is in its ex-works state. Preferably, the backup function is not made accessible to the final user.

[0164] Later on, the final user uses the secure element 1 (for example his/her personal terminal 6), which has the effect of writing additional data into the non-volatile memory 2.

[0165] The restoration function is made accessible to the final user of the secure element 1, i.e. the terminal 6 of the user is configured so as to allow this user to trigger the sending of the restoration command to the secure element 1.

[0166] The user may trigger such a restoration in the case of an abnormal behavior of the secure element 1, and this without assistance from the supplier, or else when he/she decides to transfer his/her secure element 1 to a third party (all of his/her personal data are deleted from the restoration in the ex-works state.

[0167] If additional un-approved applications have been installed after the backup in one of the source areas of the non-volatile memory 2 of the secure element 1, then the restoration deletes the contents of the source areas, which deletes any additional un-approved application contained in one of these source areas.

[0168] The secure element 1 is then factory reset.

[0169] The use of an asymmetrical compression algorithm is advantageous, since the intended backup is only to be applied by the transmitter, while the restoration may be applied multiple times. The high compression yield of such an algorithm gives the possibility of defining a relatively reduced backup area ZS, and the final user does not have to undergo the inconveniences of a long restoration, the decompression being fast.

[0170] The backup/restoration of the secure element 1 does not require any modification of the OS, or any input datum. This gives the possibility to the supplier of the secure element 1 of being autonomous in order to define a backup image IS with his/her minimum set of applications. This gives him the possibility of handling alone the deployment of his/her product in the field. The autonomy to which we refer here is relatively to the provider of the OS.

[0171] The restoration may be carried out in a hostile medium without any risk of compromising the security of the product. In particular, no datum to be saved enters or emerges from the secure element 1 during the backup or the restoration, which are applied locally to the secure element 1, which is a guarantee of security.