Patent Description:
Such method may be used in a non-limitative example within the domain of certified secure elements.

Secure elements may be used for a wide variety of products and can implement various kinds of technology features. As an example, a secure element can implement security features such as biometry, RSA (Rivest, Shamir, Adleman algorithm) and elliptic curves. An executable file comprises the code of said security features. As an example, a product can be a health card, or a driving license.

These executable file is generally stored in non volatile memory (NVM). Then, different versions of the secure element can be generated with different subsets of activated features. These different versions are usually designated as derived customer items, and the secure element from which they are derived is designated as a parent customer item. For example, a secure element that includes five different features may be used as a basis to derive several secure elements adapted to different customer requirements by removing one or several features.

For some secure elements with specific security features, it is sometimes mandatory to certify said secure element, for example using the Common Criteria for Information Technology Security Evaluation standard, ISO <NUM>. The certification process can be considered as a constraint during the production phase. It can take up to a year for a certification process to be concluded.

One problem of this prior art is that, when a given parent customer item is certified, the certification process should also be performed on the derived customer items derived from said parent customer item, which implies time and effort required to certify said derived customer items.

Document <CIT> describes a method for producing an embedded system designated as a principal customer item which comprising the following steps: generating at least one object file by compiling a source code comprising a set of at least two features organized hierarchically such that a given feature associated with a given hierarchical level has only dependencies toward other features of lower hierarchical levels; determining a list of a plurality of contiguous ranges of virtual addresses; mapping the ranges of virtual addresses of the list to a set of ranges of physical addresses in a permanent storage area of the embedded system; generating from the results provided by the linking and the mapping steps a file executable by the embedded system; loading said executable file in the permanent storage area of the embedded system.

The following summary of the invention is provided in order to provide a basic understanding of some aspects and features of the invention. This summary is not an extensive overview of the invention and as such it is not intended to particularly identify key or critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented below.

It is an object of the invention to provide a method generating an executable file derived from a parent executable file, which permits minimizing the time and effort required by testing and certifying a derived customer item, in which said executable file is embedded.

To this end, there is provided a method for generating an executable file, derived from a parent executable file, said parent executable file comprising ranges of physical addresses referencing:.

Said executable file is designated as derived executable file. As we will see in further details, as the execution file derived from the parent executable file, is only a modified parent executable file where one or a plurality of native features have been removed, the physical addresses of the first binary code of the at least one core feature and the second binary code of the remaining native features of the set of native features have not changed, and thus the first binary code and the second binary code have not been modified. Therefore, the certification of a secure element in which said parent executable file is embedded may be automatically applied to another secure element in which said derived executable file is embedded, without having another certification process to be performed for said another secure element.

According to non-limitative embodiments of the invention, the method in accordance with the invention further comprises the following characteristics.

In a non-limitative embodiment, said at least one core feature and said set of native features comprise a native code, and said set of java features comprises the java code of at least one java package.

In a non-limitative embodiment, said first binary code, said second binary code and said bytecodes are generated by compiling a source code comprising said at least one core feature, said set of native features and said set of java features.

In a non-limitative embodiment, said at least one core feature is not removable.

In a non-limitative embodiment, a plurality of native features is selected to be removed.

In a non-limitative embodiment, the bytecodes of a plurality of java features is relocated.

In a non-limitative embodiment, said method further comprises compacting the bytecodes of the java feature(s) which are not relocated.

In a non-limitative embodiment, the range(s) of physical addresses freed by the bytecodes compacting is reserved for user data.

In a non-limitative embodiment, the parent executable file is embedded in a non-volatile memory of a secure element designated as a parent customer item.

In addition, there is provided an executable file, wherein said executable file is generated according to the method characterized according to any characteristics above-mentioned.

In addition, there is provided a method for producing a secure element designated as a derived customer item, said secure element comprising a non-volatile memory, wherein said method comprises the loading of an executable file generated according to the method of any above-mentioned characteristics, in said non-volatile memory of said secure element.

In a non-limitative embodiment, said non-volatile memory is a flash memory.

In a non-limitative embodiment, said secure element is an integrated circuit card.

In addition, there is provided a secure element designated as a derived customer item, which is produced by the method above-mentioned.

To achieve those and other advantages, and in accordance with the purpose of the invention as embodied and broadly described, the invention proposes a method for generating an executable file derived from a parent executable file, said parent executable file comprising ranges of physical addresses referencing:.

wherein during the generation of the derived executable file:.

In a various method of the present invention, the ranges of physical addresses of said parent executable file reference a first binary code of at least one core feature which is not removable from the parent executable file, and wherein said at least one core feature is not removable from the derived executable file and wherein the first binary code is stored in the derived executable file in the same range of physical addresses than in the parent executable file.

In a various method of the present invention, the relocating process is performed according to the size of the bytecodes to be relocated and the size of the defined range of the physical addresses.

In a various method of the present invention, the bytecodes of the java feature(s) which are not relocated is compacted.

In a various method of the present invention, the range(s) of physical addresses freed by the compacted bytecodes (<NUM>) is reserved for user data.

In a various method of the present invention, the parent executable file is loaded in a non-volatile memory.

In a various method of the present invention, the generated derived executable file is loaded in a non-volatile memory of a secure element designated as a derived customer item.

In a various method of the present invention, the non-volatile memory is a flash memory.

In a various method of the present invention, a native feature F is selected to be removed when there is no dependency between said native feature and another native feature.

In a various method of the present invention, a java feature is selected for relocation when its bytecodes can be shifted in memory in any range of physical addresses without considering the other bytecodes of the other java features.

In a various method of the present invention, the native feature to be removed is overwritten by the relocation of the bytecodes or deleted before the relocation process.

Some embodiments of methods and/or apparatus in accordance with embodiments of the present invention are now described, by way of example only, and with reference to the accompanying drawings, in which:.

Throughout the figures, the same reference numerals and characters, unless otherwise stated, are used to denote like features, elements, components or portions of the illustrated embodiments.

In the following description, numerous specific details are set forth.

However, it is understood that well-known circuits, structures, techniques functions or constructions by the man skilled in the art are not described in detail since they would obscure the invention in unnecessary detail.

The present invention relates to a method P1 for generating an executable file <NUM> derived from a parent executable file <NUM>.

In a non-limitative embodiment, the parent executable file <NUM> is in the HEX format. As will be described in the following, one or several portions of the parent execution file <NUM> corresponding to some native feature(s) F to be removed are replaced by bytecodes <NUM> of java features Pkg.

As illustrated in <FIG>, the parent executable file <NUM> comprises ranges <NUM> of physical addresses referencing:.

In the following, a set of native features or a native feature will be referenced F. In the following, a set of java features or a java feature will be referenced Pkg.

In a non-limitative embodiment, the set of native features F comprises one or a plurality of native features. In the non-limitative illustrated example in <FIG>, the parent executable file <NUM> comprises the second binary code <NUM>-<NUM> to <NUM>-<NUM> of five native features F1 to F5.

In a non-limitative embodiment, the set of java features Pkg comprises one or a plurality of java features Pkg. In the non-limitative illustrated example in <FIG>, the parent executable file <NUM> comprises the bytecodes <NUM>-<NUM> to <NUM>-<NUM> of eight java features Pkg-<NUM> to Pkg-<NUM>.

The parent executable file <NUM> is obtained by:.

It is to be noted that the ranges <NUM> of physical addresses are those of the non-volatile memory NVM described in the following, where the parent executable file <NUM> is loaded. It is further to be noted that the first range <NUM>-<NUM> of physical addresses depends on the location where the parent executable file <NUM> is loaded in the non-volatile memory NVM.

In this description, a distinction is made between core features CR which are mandatory components for the source code <NUM>, and non-core features which are optional components that may be removed from the parent executable file <NUM> to obtain a derived executable file <NUM> described in the following. Unless explicitly mentioned, a native feature refers to a non-core feature.

The core features CR are implementing the minimum functionalities to be embedded in a secure element <NUM> which is a parent secure element, also designated as a parent customer item or in a secure element <NUM> which is derived from said parent customer item and designated as a derived secure element or as a derived customer item.

In a non-limitative embodiment, said at least one core feature CR and the set of native features F comprise a native code, and the set of java features Pkg comprises the java code of at least one java package. A java package Pkg is a library.

Native code refers to programming code that is configured to run on a specific processor. In a non-limitative example, the native code is in C code or assembly code.

Bytecodes of the java code are interpreted by a Java Virtual Machine into code that will run on computer hardware.

The parent executable file <NUM> is a computer program product which is embedded in a secure element <NUM> designated as parent customer item. The parent executable file <NUM> generated for the parent customer item <NUM> can be used as a basis to produce executable files, designated as derived executable files, for derived customer items <NUM>.

In a non-limitative element, said secure element <NUM> is an integrated circuit card ICC also designated as ICC card in the following. The ICC card may be contact or contactless.

In non-limitative embodiments, the ICC card is a smart device, a soldered element, a M2M module, an eSE (embedded secure element), a micro-SD etc..

In non-limitative examples, the ICC card is a banking card, such as an EMV card, an Electronic Identity Card, a health card, a driving license, a passport, a privacy card, a financial service card, an access card etc..

It is to be noted that secure elements are able to control the access to the data they contain and to authorize or not the use of data by other machines. Secure elements may also provide computation services based on cryptographic components. In general, secure elements have limited computing resources and are intended to be connected to a host machine. Secure elements may be removable or fixed to a host device.

<FIG> is a non-limitative embodiment of an architecture of said secure element <NUM>. It comprises:.

In a non-limitative embodiment illustrated in <FIG>, the non-volatile memory NVM is a FLASH memory.

In a non-limitative embodiment, the parent executable file <NUM>, is embedded in the secure element <NUM>, designated as parent customer item, and is stored in the non-volatile memory NVM. In a non-variant of embodiment, it is stored in the FLASH memory. In other non-variant of embodiment, it is stored in other types of non-volatile memory.

A non-limitative example of the non-volatile memory NVM where the parent executable file <NUM> is loaded is illustrated in <FIG>. As illustrated, it comprises the parent executable file <NUM> within the ranges <NUM>-<NUM> to <NUM>-<NUM> and a memory space for the user data UD in the range <NUM>-<NUM> of physical addresses.

In a non-limitative embodiment, the non-volatile memory NVM comprises the Java Virtual Machine JVM.

During operation, the CPU <NUM> executes the instructions of the different codes (first binary code <NUM>, second binary code <NUM>) stored in the stored in the non-volatile memory NVM, and the Java Virtual Machine JVM interprets the bytecodes <NUM> stored in the non-volatile memory NVM.

The executable file <NUM>, designated as derived executable file, which is derived from the parent executable file <NUM>, comprises:.

Such an executable file <NUM> is illustrated in <FIG>, in a non-limitative embodiment. It results from a modification of the parent executable file <NUM> where at least one native feature F has been removed, that is to say where the corresponding second binary code <NUM> has been replaced.

The method P1 for generating such an executable file <NUM> derived from the parent executable file <NUM> is illustrated in <FIG>. It comprises the following steps:
In step E11), illustrated SELCT(F), at least one native feature F from the set of native features is selected to be removed.

In the non-limitative embodiment, a plurality of native features F is selected to be removed. In the non-limitative example illustrated in <FIG>, the native features F2 and F4 are selected. In <FIG> the native features F2 and F4 are circled to show their selection.

It is to be noted that the core features CR are not removable. Therefore, the first binary code <NUM> will be stored in the derived executable file <NUM> in the same range <NUM> of physical addresses than in the parent executable file <NUM>.

It is to be noted that if there is a dependency between a native feature F and another native feature F, it can't be selected to be removed. The word "dependency" should be understood as a functional link between two native features F. These functional links are introduced by instructions in the source code <NUM>, for example "call" or "jump" instructions.

In step E12), illustrated DEF(<NUM>, <NUM>(F)), the range <NUM> of physical addresses where the second binary code <NUM> of said at least one selected native feature F is stored, is defined.

In the non-limitative example illustrated in <FIG>, the second binary codes <NUM>-<NUM> and <NUM>-<NUM> of the native features F2 and F4 are stored within the ranges <NUM>-<NUM> and <NUM>-<NUM> of physical addresses. It is to be reminded that the storage in said ranges <NUM>-<NUM> and <NUM>-<NUM> has been defined from the linking process.

In step E13), illustrated SELCT(<NUM>, Pkg)), at least one java feature Pkg from the set of java features to be relocated is selected.

In a non-limitative embodiment, the bytecodes <NUM> of a plurality of java features Pkg is selected to be relocated. In a non-limitative example, the java features Pkg-<NUM>, Pkg-<NUM>, Pkg-<NUM>, and Pkg-<NUM> are selected.

It is to be noted that a java feature Pkg which can be relocated has no dependency with other java feature Pkg. The word "dependency" should be understood as a functional link between two java features Pkg. These functional links are introduced by calling in the source code <NUM>, the name of the java feature Pkg.

Hence, when there are a plurality of java features Pkg, the java features Pkg which are relocatable are independent from each other, which means that their bytecodes <NUM> can be shifted in memory in any range <NUM> of physical addresses without considering the other bytecodes <NUM> of the other java features Pkg.

In step E14), illustrated RELOCT(<NUM>(Pkg), <NUM>), the bytecodes <NUM> of said at least one selected java feature Pkg are relocated in said defined range <NUM> of physical addresses.

In a non-limitative embodiment, the bytecodes <NUM> of a plurality of java features Pkg are relocated. In the non-limitative example illustrated in <FIG>, the bytecodes <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> respectively of the java features pkg3, pkg4, pgk6 and Pkg8 are relocated.

In a non-limitative embodiment, the relocating is performed according to the bytecodes' size of said at least one selected java feature Pkg and the defined range <NUM> of physical addresses' size.

In a non-limitative embodiment, the relocating is performed according to the Best Fit algorithm well-known by the man skilled in the art. It permits to optimize the relocating.

Hence, in the non-limitative example illustrated in <FIG>, according to the size of the range <NUM>-<NUM> of physical addresses and the range <NUM>-<NUM> of physical addresses, and to the size of the bytecodes <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM>, the bytecodes <NUM>-<NUM>, <NUM>-<NUM> fit in the range <NUM>-<NUM> of physical addresses and therefore are relocated in said range <NUM>-<NUM>, and the bytecodes <NUM>-<NUM>, and <NUM>-<NUM> fit in the range <NUM>-<NUM> of physical addresses and therefore are relocated in said range <NUM>-<NUM>.

It is to be noted that after the relocating, there may be some part of the second binary code <NUM> of the native feature(s) F (which has been selected to be removed), which has not been overwritten by the relocation of the bytecodes <NUM> and which is left in the defined range <NUM> of physical addresses. This part of second binary code <NUM> is a dead code because it won't be called anymore.

In a non-limitative embodiment, before the relocating, the second binary code <NUM> of said at least one selected native feature F may be deleted from said parent executable file <NUM>. In another non-limitative embodiment, after the relocating, the part of the second binary code <NUM> which is left may be deleted from said parent executable file <NUM>, part which has not been overwritten by the relocating of the bytecodes <NUM>. The deleting may be performed by filling with bits <NUM> or <NUM> the range <NUM> of physical addresses corresponding to said part left.

In step E15) illustrated COMPACT(<NUM>(Pkg), when the bytecodes <NUM> of the selected java feature(s) Pkg have been relocated, in a non-limitative embodiment, the method P1 further comprises compacting the bytecodes <NUM> of the java features Pkg which are not relocated. As this step is non mandatory, it is illustrated in dotted line in <FIG>.

In a non-limitative embodiment, the range(s) <NUM> of physical addresses freed by the bytecodes <NUM> compacting is reserved for user data UD in the non-volatile memory NVM where the derived executable file <NUM> is loaded, that is to say data which are specific to the user of the derived customer item <NUM>. In non-limitative examples, user data UD comprise a picture, a signature, the name, address, age of the user etc..

In a non-limitative example illustrated in <FIG>, when the bytecodes <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> of the java features Pkg3, Pkg4, Pkg6, and Pkg8 have been relocated, it has made:.

<FIG> illustrated the result of the compacting step which produces the derived executable file <NUM> which is loaded in a secure element for producing a derived customer item. As illustrated, the derived executable file <NUM> is smaller than the parent executable file <NUM> due to the compacting.

It is to be noted that if the method P1 comprises no compacting step, the derived executable file <NUM> generated is the one illustrated in <FIG>, that is to say it results from the step E14.

By compacting the bytecodes <NUM> of the remaining java features Pkg, it increases the memory space available for the user data UD in the non-volatile memory NVM in which the derived executable file <NUM> is loaded.

A non-limitative example of the non-volatile memory NVM where the derived executable file <NUM> is loaded is illustrated in <FIG>. As illustrated, it comprises the derived executable file <NUM>, some user data UD, and some added memory space BPU where more user data UD can be added.

This memory space brings an added value to the derived customer item <NUM> and this can be monetized. For a predetermined size of non-volatile memory NVM, removing unnecessary native features F allows to maximize the size of the user data memory by adding unused memory to it and therefore increase the revenue generated while selling the derived customer item <NUM>.

A method P2 for producing a secure element <NUM>, designated as derived customer item, said secure element <NUM> comprising a non-volatile memory NVM, is illustrated in <FIG>. Said method P2 comprises the loading (step E21 illustrated LD(<NUM>, NVM)) of said executable file <NUM> in said non-volatile memory NVM of said secure element <NUM>. Thus, a derived customer item <NUM> is produced from the parent customer item <NUM> in which the parent executable file <NUM> is embedded.

The description made for the secure element <NUM> is applied for the secure element <NUM>.

In a non-limitative embodiment, as the same manner than the secure element <NUM>, the secure element <NUM> is an integrated circuit card ICC.

<FIG> is a non-limitative embodiment of architecture of said secure element <NUM>. It comprises:.

In a non-limitative embodiment, the derived executable file <NUM>, is embedded in the secure element <NUM> and is stored in the non-volatile memory NVM. In a non-variant of embodiment, it is stored in the FLASH memory. In other non-variant of embodiments, it is stored other types of non-volatile memory.

Hence, with the derived executable file <NUM>, a secure element <NUM>, designated as derived customer item, is derived from the parent customer item <NUM>.

Hence, a plurality of derived customer items <NUM> comprising different combinations of native features F can be produced in this manner.

Hence, thank to the generation of the derived executable file <NUM> described, the compilation of the source code <NUM> and the linking of the object file. obj and the. jca file is performed only one time and for all the customer items, whether it is a parent customer item <NUM> or a derived customer item <NUM>.

If the parent customer item <NUM> embedding this parent executable file <NUM> is tested and certified, all derived customer items <NUM> derived from this parent customer item <NUM> will be considered as already tested and certified.

During the certification process, only the features (java, native and core) of the derived customer item <NUM> are checked and compared to the features (native and core) of the parent customer item <NUM>. Therefore, if some native features F of the parent customer item <NUM> are removed from the derived customer item <NUM>, there is no consequence for the certification process.

For the certification process, the native code (of the core feature(s) CR and of the native feature(s) F) checked must be the same, and its related ranges <NUM> of physical addresses must be the same. It is to be noted that even if only one related range <NUM> of physical addresses is changed, it implies that the native code is modified, as the call from one native feature F for example will be modified when it calls another native feature F which related range <NUM> of physical addresses (where its second binary code <NUM> is positioned) has been modified.

For the certification process, the java code (of the java feature(s) Pkg) checked must also be the same. But, if it is relocated, there is no consequence regarding the java code. It is not modified, as the dependency between different java features Pkg is implemented according to the calling of the name of the java feature Pkg. The Java Virtual Machine JVM interprets the dependency according to a table of the ranges <NUM> of physical addresses which are related to the different java features Pkg. When a java feature Pkg is relocated, this table is updated with the new corresponding ranges <NUM> of physical addresses.

It is to be understood that the present invention is not limited to the aforementioned embodiments.

Claim 1:
A method (P1) for generating an executable file (<NUM>) to be loaded in a non-volatile memory (<NUM>) of a secure element (<NUM>), said executable file (<NUM>) being derived from a parent executable file (<NUM>), said parent executable file (<NUM>) comprising ranges (<NUM>) of physical addresses referencing:
- a second binary code (<NUM>) of at least a native feature (F) which is removable from the parent executable file;
- bytecodes (<NUM>) of at least a java feature (Pkg);
wherein during the generation of the derived executable file:
- selecting (E11) at least one native feature (F) from said set of native features (F) to be removed;
- defining (E12) the range (<NUM>) of physical addresses where the second binary code (<NUM>) of said at least one selected native feature (F) is stored in the parent executable file;
- selecting (E13) at least one java feature (Pkg) from said set of java features to be relocated;
- in the generated derived executable file, relocating (E14) the bytecodes (<NUM>) of said at least one selected java feature (Pkg) in said defined range (<NUM>) of physical addresses according to a predefined optimization relocation algorithm, wherein the relocating process is performed according to the size of the bytecodes to be relocated and the size of the defined range (<NUM>) of the physical addresses.