Method for generating unlinked program code to be transferred from a source device to a target device

Abstract

The present invention proposes a method for generating unlinked program code to be transferred from a source device to a target device, the source device containing program code to be linked to the device, called linked program code, the method comprising: - detecting bytes in the program code to be linked, which bytes belong to the program to be transferred from the source device to the target device; - generating a component, called a reverse link component, containing bytes of unlinked program code that must be modified by the target device by creating linked program code, the bytes being concatenated in the reverse link component in the order in which they are to be linked in the program code; regenerating unlinked program code transferred from the source device to the target device by using a reverse link component, the reverse link component comprising: Using a reference location component in the Cap file, the reference location component points to the bytes in the method component that are to be linked, and the bytes are ordered to be linked in the method component, or It is created by parsing the method component of the Cap file and finding the instruction in the method component Java card that precedes the bytes to be linked.

Description

[Technical Field]

[0001] The field of the invention is telecommunications.

[0002] More precisely, the invention relates to a method and a system implemented in a device that cooperates with a terminal and allows the transfer of code to another terminal (peer-to-peer transfer).

[0003] This transfer may for example consist in transferring an MNO's subscription profile from a source device to a target device, each device consisting of a terminal (fixed or mobile) cooperating with a secure element such as a SIM card, a UICC, a USIM, an eUICC (embedded UICC) or an iUICC (integrated UICC).

[0004] This may also involve transferring a banking application, or an identification application, or another application from the source device to the target device.

[0005] The following description focuses on the transfer of subscription profile codes from a source device to a target device, but applies to any transfer of codes from a source device to a target device.

[0006] To transfer a profile from one device to another, the applet code must be transferred. After downloading the code to the source device, for example via HTTP, it is executed on the source device and thereby linked to the features of the terminal and / or the secure element with which this device cooperates. Parameters are modified to a unique encoding that cannot be transferred to another device. Due to memory constraints, the unlinked code downloaded to the source device is overwritten by the linked code, and therefore the unlinked code is no longer available for transfer to the target device. This means that the original code can be saved before linking, but this code usually requires a lot of memory space. Storing this code before linking doubles the memory space used by the code.

[0007] In Java Card, the code is an applet contained in a cap file, and the cap file contains different components. Among these there is a method component which contains the applet's code. So if you want to be able to export this method component, a naive solution is to load the applet's component and duplicate the components that you know you will need to modify and export later. For example, you could duplicate the method component, have an identical version A, an identical version B, and then link version A, which means you will use the linked version for exporting and keep version B. The problem is that it doubles the memory size required for the applet's code.

[0008] The present invention aims to solve this problem, more precisely to regenerate the original code from the linked code in order to transfer the reconstructed original code from the source device to the target device.

[0009] This problem is solved in a peer-to-peer transfer, which can be done using any possible link between the source and the target device (Wifi, Bluetooth, ...), by saving and restoring only the modified parameters before exporting the original code to the target device.

[0010] Saving modified parameters also requires having a way to correctly save / restore the corresponding parameters to the correct location in the code.

[0011] The present invention achieves this object by means of a method as claimed in claim 1.

[0012] The invention will be better understood by reading the description of the following two figures. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 shows various elements used to implement the method of the present invention. [Figure 2] FIG. 10 highlights the generation of reverse link components in accordance with the present invention.

[0014] FIG. 1 represents the various elements used to implement the method of the present invention.

[0015] In this diagram, all elements included in the source device are as follows: - Non-linked method components 10, -ConstantPool component 11, -RefLocation component 12, -Linker 13, -14 linked method components, - reverse link component 15, -Reverse Link 16, - Generated non-linked method components 17.

[0016] The unlinked method component 10 comprises original program code downloaded to the source device from a dedicated server, for example by http or https.

[0017] The ConstantPool component 11 is the part of a .class file (and its in-memory representation) that contains the constants needed to run the original program code of that class.

[0018] These constants include literals specified by the programmer and symbolic references generated by the compiler. Symbolic references are essentially names of classes, methods, and fields referenced from your code. These references are used by the JVM to link your code to other classes it depends on.

[0019] The RefLocation component 12 represents a list of offsets into the info items of the method component to items that contain indexes into the constant_pool array of the ConstantPool component. This includes all constant pool index operands of the instruction and all non-zero catch_type_index items of the exception_handlers array. catch_type_index items with a value of 0 are not included because they ultimately represent blocks instead of specific exception classes.

[0020] Some constant pool indices are represented as 1-byte values, others as 2-byte values. The operands of the getfield_T and putfield_T instructions are 1-byte constant pool indices. Most other indices within method components are 2-byte values.

[0021] The specification for the reference location component structure is given in the document "Java Card (trademark) Platform Virtual Machine Specification, Classic Edition" as follows:

[0022]

number

[0023] The items in the reference_location_component structure are as follows: -tag

[0024] The tag item has a value of COMPONENT_ReferenceLocation. -size

[0025] The size item indicates the number of bytes in the reference_location_component structure, excluding the tag and size items. The value of the size item must be greater than zero. -byte_index_count

[0026] The byte_index_count item represents the number of elements in the offsets_to_byte_indices array. -offsets_to_byte_indices

[0027] The offset_to_byte_indices item represents an array of 1-byte jump offsets into the info item of the method component for each 1-byte constant_pool array index. Each entry represents the number of bytes (or distance) between the current index and the next index.

[0028] This will become clear hereinafter by reading the description of FIG.

[0029] The linker 13 is a function that links the original program code with the ConstantPool component 11 and the RefLocation component 13. The result of this linking is a linked method component 14. This linked method component 14 contains the program code that will be linked to the device where the unlinked method component 10 is downloaded.

[0030] As previously mentioned, the unlinked method components 10 are deleted after the linked method components 14 are created due to memory constraints.

[0031] FIG. 2 shows, among other things, how linked method components 14 are created.

[0032] A linked method component 14 is generated from an unlinked method component 10 , a ConstantPool component 11 , and a RefLocation component 12 .

[0033] The RefLocation component 12 has the purpose of helping the linker 13 generate the linked method component 14 .

[0034] The RefLocation component 12 primarily contains two index tables that indicate to the linker 13 where the values ​​of the unlinked method components 10 must be modified.

[0035] The first table shows where there is only one byte to be modified, and the second table shows where there are two bytes to be modified.

[0036] For example, as shown in Figure 2, the RefLocation component indicates that there is only one byte (value 01) to be modified, at column 04, row 00. This byte to be modified follows this indication, here at 2F (column 05, row 00). This means that the next byte (00 in column 06 and row 00), at offset 2F, must be modified to another value.

[0037] The next byte is OA (column 07, row 00), which indicated that the 10 following bytes must be changed.

[0038] For the first index (05, column 08, row 00), byte 0007 must be modified. For the next index (06, column 09, row 00), the two bytes 0001 (columns 0E and 0F, row 00) must be changed, and so on.

[0039] At the end of this linking procedure, all bytes of the method component 10 pointed to by RefLocation have been modified to take into account the device's features. The original unlinked method component 10 is then updated.

[0040] The aforementioned methods are known from the state of the art.

[0041] The invention then proposes to generate a reverse link component 15 which, in order to recreate the unlinked method component 10 (with the aim of transmitting it peer-to-peer to another device), makes it possible to obtain an unlinked method component 17 identical to the unlinked method component 10 when applied together with a method component 14 linked through a reverse link 16. This can be achieved in two different ways: with or without a Reflocation component 13.

[0042] The first method is described with respect to FIG. 2, which illustrates the generation of a reverse link component 15 according to the present invention by using a RefLocation component 12 .

[0043] The invention proposes to create this link in step 13 and at the same time back up in the reverse link component 15 all the values ​​to be linked in the order of the table.

[0044] For example, with respect to FIG. 2, byte 00 of column 02, row 30 of linked method component 14 is stored in column 00, row 00 of reverse link component 15, the next bytes 00 and 07 are stored in columns 01 and 02, respectively, of reverse link component 15, row 00, the next bytes 00 and 01 are stored in columns 03 and 04, respectively, of reverse link component 15, and so on.

[0045] Thus, the present invention involves storing all linked values ​​in the order in which they appear in the linked method component 14, and the generated reverse link component 15 includes bytes of unlinked program code (contained in the linked method component 14) that must be modified by the target device by creating the linked program code, with the bytes concatenated in the reverse link component 15 in the order in which they are linked in the program code.

[0046] To generate an unlinked method component 17, the reverse link 16 uses the same table. Looking at the RefLocation component 12, the first byte to be considered is 2F, which references the first byte of the reverse link component 15, i.e., 00. The second value is the next byte in the reverse link component 15, bytes 00 and 0A, and so on. The bytes of the reverse link component 15 are then substituted for the bytes indicated in the RefLocation component 12 of the linked method component 14. It is therefore possible to regenerate an unlinked method component 17 identical to the unlinked method component 10.

[0047] In a preferred embodiment applied to Java code, the backward link component 15 is created by using a reference location component 12 of the Cap file, which includes a first table indicating where one byte of linked program code contained in a method component must be modified, and a second table indicating where two bytes of linked program code also contained in a method component must be modified based on a relative offset with respect to the modified preceding byte.

[0048] In essence, the backward linking component is created by parsing the method component of the Cap file and finding the instruction in the method component Java card that precedes the byte to be linked.

[0049] The present invention also proposes a second way of regenerating unlinked method components 10. This second solution does not require the use of a Reflocation component 13, but consists in parsing the bytecode of the linked method component (or more generally of the linked program code).

[0050] So, for example, as shown in Figure 2, we have byte 8C in column 07, line 00, and it is known that in Java, after 8C, there is always a two-byte linking parameter (0007). After that, we have byte code 8F (column 0D, line 00), which references two linked byte codes (00 and 01). It is therefore possible to remove the RefLocation component 12, and in this case the bytes to be considered are kept in the order in which they appear in the byte codes, in a different order than described for the first way to solve the problem.

[0051] However, for practical reasons (to comply with standards), it is better to retain the RefLocation component 12 in order to send it to the target device.

[0052] However, it is also possible to regenerate the RefLocation component 12, for example, on the fly. This is a third solution, since it is possible to completely regenerate the RefLocation component 12 when it is known which bytecodes must be linked. This is what off-card does. It can simply be a matter of parsing the bytecodes and recognizing the bytecodes with parameters to link.

[0053] The solution therefore consists in creating a backward link component by parsing the method component of the Cap file and finding in this method component's Java card the instruction that precedes the byte to be linked.

[0054] The proposed invention reduces the amount of memory space required to export code in an "unlinked" state context. In telecommunications applications, this allows peer-to-peer transfer of the code (without data) of a profile from one device to another. When code linked to one device is transferred to another, the result of this linking is always something proprietary, which may differ from one secure element to another, even for the same product, depending on the order in which applets were loaded and on different events. Therefore, in order to transfer code, it is necessary to unlink it, i.e., to revoke this link.

Claims

[Claim 1] 1. A method for generating unlinked program code to be transferred from a source device to a target device, the source device including program code to be linked to the device, called linked program code, the method comprising: - detecting bytes in the linked program code, said bytes belonging to a program to be transferred from the source device to the target device; - generating a component, called a reverse link component, containing bytes of the unlinked program code that must be modified by the target device by creating linked program code, said bytes being concatenated in the reverse link component in the order in which they are linked in the program code; regenerating the unlinked program code transferred from the source device to the target device by using the reverse link component; the reverse link component: using a reference location component of a Cap file, said reference location component pointing to the bytes of the method component to be linked, said bytes being ordered as they are to be linked in said method component, or A method created by parsing a method component of a Cap file and finding the instruction in said method component Java card that precedes the byte to be linked.

Images