The present invention relates to the field of secure elements.
The object of the invention is methods for saving and restoring data in a secure element.
A secure element (SE) is a tamperproof hardware platform capable of containing data in accordance with rules and safety requirements set by confident authorities.
A secure element comprises a non-volatile memory and a processor executing an operating system. Additional applications, for which the execution is controlled by the operating system, may be installed according to the goodwill of a user of the secure element.
Now, the writing of additional data in the non-volatile memory (for example an additional application) may compromise proper operation of the secure element.
Moreover, as the user of the secure element is the owner of its data, he/she wishes to be able to suppress them in a secure way before reselling his/her secure element.
To overcome this problem, it is known how to proceed with saving of data contained in the non-volatile memory of the secure element to a trustworthy server (“TSM” server). The saved data may be subsequently restored in the non-volatile memory of the secure element by uploading these data from the trustworthy server. Restoration gives the possibility of reconfiguring the non-volatile memory of the secure element in the condition in which it was found at the moment when the saving was carried out; any modification carried out in a non-volatile memory between the saving and the restoration is deleted, for example data compromising proper operation of the secure element.
However, the method for saving and restoring data has the major drawback of having confidential data emerge outside the secure element, which represents a significant safety risk since a third party may intercept these confidential data.
An object of the invention is to propose a method for saving and a method for restoring data in a secure element, giving the possibility of reducing the aforementioned safety risks.
According to a first aspect of the invention, a method for saving data stored in a non-volatile memory of a secure element is accordingly proposed, the method comprising the steps of:
As the saved image is written in the non-volatile memory from which originate the data to be saved, the saving is applied locally to the secure element. No datum to be saved leaves the secure element during this saving operation.
The saving process may further comprise the following features taken alone or as a combination when this is technically possible.
The generation of the saved image may comprise compressing at least one portion of the data, which gives the possibility of reducing the space occupied by the saved image in the non-volatile memory.
The compression may be applied on data localized 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. In this way, the backup image is of a minimum size and consumes little space in the non-volatile memory of the secure element.
The backup method may comprise steps for:
Before de-fragmentation, the data to be saved are dispersed in the relevant area. The fact of applying de-fragmentation before the compression gives the possibility of concentrating the data to be saved in a region of reduced size (the occupied region), and therefore of improving the applied compression level.
The relevant area (and therefore the occupied region after its de-fragmentation) may contain objects intended to be handled by a program coded in an object language, and the objects to be compressed by a dictionary. Such a compression by a dictionary provides particularly high compression levels when it is applied to data comprising recurrent schemes or units and of small sizes, which is the case of such objects.
The compression dictionary may be generated from objects to be compressed. In this way, the storing in memory of a preformed dictionary in the non-volatile memory of the secure element, consumer of memory space, may be avoided.
The method may further comprise compressing the contents of the free region by means of a different compression algorithm from the one used for compressing the portion of the data contained in the occupied region.
The compression of the contents of the free region comprises a coding by ranges of these contents. Such coding applied to the free region provides a very high compression level.
The data to be saved may be contained in at least one predetermined area of the non-volatile memory. In this case, the method may comprise generating and storing in the non-volatile memory metadata comprising for each area, an address of the area.
The metadata may comprise, for at least one of the areas, information on the integrity control of the area, a size of the area.
The backup method may also comprise generating and storing in the non-volatile memory information on the integrity control of the metadata.
The backup method may also comprise the generation and the memory storage in the non-volatile memory of information on the integrity control of the generated backup image.
According to a second aspect of the invention, a method for restoring data is also proposed towards a non-volatile memory of a secure element, the method comprising steps for:
The restoration may comprise a configuration of the secure element in an busy mode wherein the secure element does not process an external command for physical restarting of the secure element. Such a configuration in the busy mode gives the possibility of avoiding corruption of the contents of the non-volatile memory during the restoration.
According to a third aspect of the invention, a method for resetting a secure element comprising a non-volatile memory storing in memory data is further proposed, the method comprising steps for saving data by means of the method according to the first aspect of the invention, and a restoration of saved data by means of the method according to the second aspect of the invention.
The non-volatile memory of the secure element may be integrated permanently into the secure element.
According to a fourth aspect of the invention, a computer program product is proposed, comprising program code instructions for executing steps of the methods according to the first aspect and/or the second aspect and/or the third aspect of the invention, when this program is executed by at least one processor.
According to a fifth aspect of the invention, a secure element comprising a non-volatile memory is proposed, at least one processor configured for saving data stored in memory in the non-volatile memory, the processor being further configured for:
According to a sixth aspect of the invention, a secure element is proposed comprising a non-volatile memory, at least one processor configured for restoring data towards the non-volatile memory, the processor being further configured for:
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:
On the whole of the figures, similar elements bear identical references.
With reference to
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).
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).
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.
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.
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.
The processor 4 is moreover connected to the communication interface 5.
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.
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.
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.
The terminal 6 is a user personal piece of equipment, such as a smartphone, a tablet, a telephone, etc.
Data Backup
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.
In the example illustrated in
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.
A backup area ZS is also predetermined in the non-volatile memory 2, different from the source areas.
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
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”.
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.
The object heap may be shared by several applications coded in a same object language. In the example illustrated in
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.
With reference to
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.
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.
The backup program compresses 102 the contents of each source area of the OS.
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.
The compression step 102 uses a compression algorithm by a dictionary.
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.
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.
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.
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.
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.
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.
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.
The compression step 102 is applied each of the source areas of the OS Z1 and Z2. With reference to
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.
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.
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.
The areas Z3 and Z4 illustrated in
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.
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.
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.
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.
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.
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.
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
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.
Very advantageously, a coding by ranges (“run-length encoding” or RLE) is used for the compression 108.
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.
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.
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.
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.
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.
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.
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:
The MZi area descriptor associated with each source area Zi comprises:
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.
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.
The restoration directive D comprises:
The backup program sends back to the terminal 6, and this via the communication interface 5, a status indicating that the backup is finished.
The contents written into the backup area ZS is illustrated in
Data Restoration
With reference to
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.
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.
The restoration program checks 202 the existence of a backup image IS in the backup area ZS.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Otherwise, the restoration program decompresses 210 each compressed block contained in the backup image IS.
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.
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.
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.
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.
The decompression buffer is coupled with an output buffer with the size of a page of the non-volatile memory 2.
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.
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.
The OS sends back a successful status to the terminal 6 in order to inform it on the course of the operation.
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.
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.
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.
If the restoration program considers that all the rewritten source areas Z1 to Z4 have intact contents, then these areas have been restored successfully.
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.
The restoration program sends back 216 to the terminal 6 a status indicating that the restoration took place successfully.
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.
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.
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.
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.
Secure Element Factory Reset
Generally, three different actors intervene on a secure element 1:
The backup and restoration methods, described earlier advantageously find application for factory resetting a secure element 1.
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.
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.
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.
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.
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.
The secure element 1 is then factory reset.
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.
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.
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.
Number | Date | Country | Kind |
---|---|---|---|
1653999 | May 2016 | FR | national |