Application identification

Abstract

Application Identification This description relates to a system (200) comprising at least one first application (202) and a shared software platform (201), in which each application (202) is identified by said software platform (201) by a first random number, said first random number being stored in encrypted form in an execution code of said first application (202), and a second number representing said first random number being stored in a first part of memory accessible only to said platform (201). Figure for the abbreviation: Fig. 2

Description

Title of the invention: Identification of an application technical field

[0001] This description relates generally to electronic systems and devices, and the security of such electronic systems and devices. This description relates more specifically to the protection of data, or digital resources, used by an application implemented by an electronic system or device. Previous technique

[0002] It is common nowadays to use electronic devices and systems adapted to perform several different functions, themselves implemented by software applications.

[0003] It would be desirable to be able to improve, at least in part, certain aspects of software systems and architectures. More specifically, it would be desirable to be able to improve, at least in part, certain aspects of software application security. Summary of the invention

[0004] There is a need for electronic devices and systems adapted to implement several software applications in a secure manner.

[0005] An embodiment overcomes all or part of the disadvantages of known electronic systems adapted to implement one or more software applications.

[0006] An embodiment overcomes all or part of the drawbacks of the storage and retrieval processes for the digital resources of a software application.

[0007] One embodiment provides for an electronic system in which applications are reliably identified from a shared software platform.

[0008] One embodiment provides a method for initializing such a system.

[0009] One embodiment provides methods for storing and recovering digital resources stored in a system's memory.

[0010] One embodiment provides for a system comprising at least a first application and a shared software platform, in which each application is identified by said software platform by a first random number, said first random number being stored in encrypted form in an execution code of said first application, and a second number representing said first random number being stored in a first part of a memory accessible only to said platform.

[0011] According to one embodiment, said second number representing said first A random number is generated by the said software platform.

[0012] According to one embodiment, said first random number is generated by a first original equipment manufacturer of said first application.

[0013] According to one embodiment, said first random number is modified during an update of said first application.

[0014] According to one embodiment, said execution code of said first application is stored in a second part of a memory which is not accessible to a second original equipment manufacturer of a second application implemented by said platform.

[0015] According to one embodiment, the system is a secure operating system embedded in a secure element.

[0016] Another embodiment provides for a method of initializing a system described above comprising the following successive steps: - send, via the said first application, the said encrypted execution code to the said platform; - extract, by the said platform, the said first random number; - generate, via said platform, said second number; and - store said second number.

[0017] According to one embodiment, the process further comprises the following successive steps: - to decrypt, using said platform, said execution code encrypted with a first decryption key; and - store said decrypted execution code.

[0018] According to one embodiment, said decrypted execution code is stored in said second part of memory.

[0019] According to one embodiment, said key is not known to said second original equipment manufacturer.

[0020] Another embodiment provides for a method of storing at least one first digital resource of said first application of the system described above, in which said platform stores said at least one digital resource and associates it with said second number.

[0021] According to one embodiment, the platform uses said second number to sign and / or encrypt said at least one first digital resource.

[0022] According to one embodiment, said at least a first digital resource is stored in a third part of a memory.

[0023] Another embodiment provides for a method of retrieving at least a second digital resource associated with a third number by a third application identified by a fourth random number, implemented by the system described previously, in which said platform verifies the concordance of said third and fourth numbers.

[0024] According to one embodiment, if the concordance is verified, said at least a second resource is transmitted to said third application by said platform.

[0025] According to one embodiment, if the concordance is not verified, an error is transmitted to said third application by said platform. Brief description of the drawings

[0026] These features and advantages, as well as others, will be described in detail in the following description of particular embodiments, given by way of non-limiting example, in relation to the accompanying figures, among which:

[0027] [Fig.1] represents, very schematically and in block form, an example of an electronic device to which the embodiments of figures 2 to 4 can be applied;

[0028] [Fig.2] represents, very schematically and in block form, an embodiment of an electronic system;

[0029] [Fig. 3] represents a block diagram illustrating one way of implementing a system initialization method of [Fig. 2]; and

[0030] [Fig.4] represents a first block diagram illustrating a method of implementing a process for storing a digital resource, and a second block diagram illustrating a method of implementing a process for retrieving a digital resource. Description of the implementation methods

[0031] The same elements have been designated by the same reference numerals in the different figures. In particular, the structural and / or functional elements common to the different embodiments may have the same reference numerals and may have identical structural, dimensional and material properties.

[0032] For the sake of clarity, only the steps and elements useful for understanding the described embodiments have been represented and are detailed.

[0033] Unless otherwise specified, when referring to two elements connected together, this means directly connected without intermediate elements other than conductors, and when referring to two elements connected (in English "coupled") together, this means that these two elements can be connected or linked through one or more other elements.

[0034] In the following description, when referring to absolute positional qualifiers, such as the terms "front", "back", "top", "bottom", "left", "right", etc., or relative positional qualifiers, such as the terms "above", "below", "superior", "inferior", etc., or to orientational qualifiers, such as the terms "horizontal", "vertical", etc., it is made Reference to the orientation of the figures unless otherwise specified.

[0035] Unless otherwise specified, the expressions "approximately", "roughly", and "in the order of" mean within 10%, preferably within 5%.

[0036] The embodiments described below relate to securing software applications, and more particularly to securing the digital resources of such software applications. More specifically, they aim to prevent a software application from accessing digital resources not intended for it, such as the digital resources of another software application, or the digital resources of an older version of the same software application. The embodiments described below make it possible, in particular, to mitigate an application substitution attack, in which a malicious application takes the place of an already installed application by impersonating it during an update, with the aim of gaining access to the application's digital resources.

[0037] The embodiments described below relate, more particularly, to a system comprising a software platform adapted to implement one or more software applications. Each software application is identified to the platform by means of a random number, which it stores in encrypted form, for example, in its execution code or in a separate element of its execution code to facilitate its protection and use.

[0038] Fig. 1 is a block diagram representing, very schematically, an architecture of an example of an electronic device 100 adapted to implement the embodiments described in relation to Figures 2 to 4.

[0039] The electronic device 100 includes a processor 101 (CPU) adapted to implement various processing of data stored in memories and / or supplied by other circuits of the device 100. The processor 101 can, in addition, be adapted to implement a software architecture of the type of the software architecture described in relation to [Fig.2].

[0040] The electronic device 100 further comprises various types of memory 102 (MEM), including, for example, non-volatile memory, volatile memory, and / or read-only memory. Each memory 102 can be adapted to store different types of data and may include access rules. In particular, the memory 102 or 102 may include parts that are accessible only to one or more circuits of the electronic device and / or only to one or more software programs implemented by the device 100.

[0041] The electronic device 100 further comprises, for example, a secure element 103 (SE) adapted to handle sensitive and / or secret data. The secure element 103 may include its own processor(s), its own memory(ies), etc. The secure element 103 may, moreover, be adapted to implement an architecture software of the type of software architecture described in relation to [Fig.2].

[0042] In the following description, sensitive data and secret data are data whose content is not intended to be public, and, therefore, whose access is restricted to certain persons and / or particular circuits.

[0043] The electronic device 100 may further include interface circuits 104 (IN / OUT) adapted to send and / or receive data from outside the device 100. The interface circuits 104 may further be adapted to implement a data display system, for example, a screen.

[0044] The electronic device 100 further comprises various circuits 105 (FCT1) and 106 (FCT2) adapted to perform different functions. By way of example, the circuits 105 may include measurement circuits, data conversion circuits, electronic or electromechanical equipment control circuits, etc.

[0045] The electronic device 100 further includes one or more data buses 107 adapted to transfer data between its different components.

[0046] Fig. 2 represents, very schematically and in block form, an embodiment of a software architecture, or software system 200.

[0047] The architecture, or system, 200 comprises: - a shared and secure software platform 201 (Platform); - one or more secure software applications 202 (Service); - one or more 203 memory chips (MEM); and - at least one 204 secure operating system (Secure OS).

[0048] The shared software platform 201 is software used to implement the application(s) 202. More specifically, the platform 201 is adapted to communicate with the applications, and, more particularly, to receive and transmit data to them. In one embodiment, the platform 201 is adapted to manage the storage of data used by the software application(s) 202. In one example, the software platform 201 is designed by an original equipment manufacturer (OEM), or manufacturer, other than the electronic device, such as the processor or the secure element, that implements it.

[0049] The original equipment manufacturer, or simply manufacturer, is the original designer of an element, such as a circuit, a device or software.

[0050] The secure software application(s) 202 (Service) are secure software adapted to implement one or more functionalities. A 202 application may also be called a software service, or simply a service. In one embodiment, a 202 application is implemented from its execution code and may use digital resources (Assets).

[0051] Here, the execution code refers to the set of data and instructions forming the or The programs implemented by an application. When an application is updated, its execution code is modified. Without execution code, a 202 application cannot function.

[0052] Furthermore, a digital resource is defined here as one or more data items used during and by an application for its operation. This data may be collected, generated, and / or processed by said application. A digital resource may be data stored temporarily by the application, or stored more permanently by the application. An application does not necessarily need a digital resource to function. When an application is updated, the digital resources are not modified. A digital resource is generally considered sensitive and / or confidential data.

[0053] According to one embodiment, each software application 202 can be designed by a manufacturer different from the manufacturer of the software platform 201 and the manufacturer of the electronic device, such as the processor or the secure element implementing them. Similarly, different applications can have different manufacturers.

[0054] Each application 202 is adapted to communicate with the platform 201, and, more generally, is adapted to be implemented or executed by the platform 201.

[0055] The memory 203(s) represent access to the various memory(ies) of the device implementing the system 200. Among these memories, there is at least a portion of a memory whose access is strictly reserved for the platform 201, and at least a portion of a memory used for storing the digital resources of the applications 202. The platform 201 is adapted to manage memory access. The applications 202 do not have direct access to the memories 203.

[0056] The secure operating system 204 is, for example, the operating system of the electronic device, such as a processor or a secure element, implementing the system 200. The operating system 204 is adapted to communicate with the platform 201, but also, according to an example not shown, with the memories 203 and the applications 202.

[0057] According to one embodiment, each application 202 is adapted to be identified to the platform 201 by means of a random number Rand. This random number Rand is stored in encrypted form in, for example, the execution code of each application, or in a separate element of its execution code to facilitate its protection and use. In one example, this random number Rand is generated by the manufacturer of the application 202. The use of this random number is described in relation to the implementation methods described in relation to Figures 3 and 4.

[0058] Figure 3 is a block diagram illustrating an implementation method for initializing an electronic device of the type of electronic device 100. described in relation to [Fig.1] implementing a system, or architecture, of the type of system 200 described in relation to [Fig.2].

[0059] The initialization process 300, or boot process, is the process for starting the device and the system. This process must necessarily be implemented before any system application is run.

[0060] At step 301 (BOOT START), the device and the system start. Each application presents its execution code to the shared software platform. According to one embodiment, the execution code of each application is encrypted. Step 301 is followed by two steps 302 (E(rand)->rand) and 303 (Image Payload Decryption).

[0061] In step 302, the random number Rand, which allows for the identification of the application, is extracted from the application's execution code by the platform. In one embodiment, the random number Rand is encrypted like the application's execution code. The platform is adapted to decrypt the random number.

[0062] At a step 304 (rand -> rand2), following step 302, the platform can, for example, apply a derivation function to the random number Rand obtained in step 303. For example, the derivation function is a function adapted to provide new secret data from initial secret data, such as a new random number from an initial random number. For example, the derivation function is a pseudo-random function. The platform thus provides a derived random number Rand2 from the previously deciphered random number Rand. In practice, each electronic device implementing the initialization process 300 includes a derivation function adapted to provide a random number different from the random numbers provided by derivation functions of other devices.Thus, according to one example, the derivative function is a physically unclonable function (PUF).

[0063] In step 305 (Storage), following step 304, the platform stores the derived random number Rand2 in a portion of the device's memory accessible only to the platform. This derived random number Rand2 is used to verify the match between a random number extracted from the execution code of a first application and that of a second application already received by the platform. One advantage of using a random number is that it constitutes data with a virtually unique value and is difficult to retrieve using cryptographic means.

[0064] The random number Rand is known only by the device implementing process 300, and is never stored decrypted during the implementation of steps 301 to 304. The derived random number Rand2 can, however, be shared with other devices, for example directly or in encrypted form.

[0065] In step 303, following step 301, the encrypted execution code of the application is decrypted and / or authenticated. In one embodiment, the execution code is The decryption is decrypted by the platform using a decryption key known only to the manufacturers of the application and the platform, or the device implementing the platform. Specifically, the decryption key is not known to other application manufacturers.

[0066] At step 306 (Storage), the decrypted execution code of the application is stored by the platform in a portion of memory that is accessible only to the manufacturers of the application and the platform, or the device implementing the platform. In particular, this portion of memory is not known to other application manufacturers.

[0067] Steps 302 to 306 are implemented for each application included in the system.

[0068] Figure 4 includes two block diagrams (A) and (B) illustrating implementation methods for a digital resource storage method 400 and a digital resource retrieval method 450. These methods are adapted to be implemented by an electronic device of the type of the electronic device 100 described in relation to Figure 1, implementing a system of the type of the system 200 described in relation to Figure 2.

[0069] Methods 400 and 450 are necessarily implemented after the implementation of method 300 described in relation to [Fig. 3]. Thus, the random identification numbers for each application in the system have already been derived and stored by the shared software platform. In other words, the derived random number Rand2 from [Fig. 3] has already been stored by the shared software platform, for example in volatile memory by a step of the type of step 305 described in relation to [Fig. 3]. According to an alternative embodiment, the derived random number Rand2 from [Fig. 3] can be stored in non-volatile memory; this has the advantage of saving time at each startup and avoiding a decryption operation that can be time-consuming.

[0070] At a step 401 (Asset), an application of the type of one of the applications 202 described in relation to [Fig. 2] wishes to store digital resources in memory. According to one example, the digital resources concerned are sensitive and / or secret data provided to the application by external means, or sensitive and / or secret data generated by the application.

[0071] In a 402 (Send) step, following the 401 step, the application sends the digital resources to be stored to the platform. According to one example, the platform can encrypt the digital resources using the derived random number associated with the application as the encryption key. According to another example, the platform can sign the digital resources using the derived random number.

[0072] At a step 403 (Store), successive to step 402, the platform stores the digital resources in a part of a memory associated with the derived random number, that is, the random number Rand2 from [Fig. 3]. In one example, this memory portion is accessible only to the shared software platform. In another variant, this memory portion is accessible only to the shared software platform and the manufacturer of the application.

[0073] At a step 451 (Want Access), an application of the type of one of the applications 202 described in relation to [Fig.2] wishes to have access to digital resources stored in memory, for example in order to be able to implement some of its functionalities.

[0074] At a step 452 (Req), subsequent to step 451, the application sends a request to the shared software platform, indicating that it wishes to retrieve the digital resources associated with its random number.

[0075] In a step 453 (Verification), following step 452, the platform verifies the agreement between the random number derived from the application that formulated the request and the derived random numbers it has stored in a memory area. For this purpose, the platform uses the derived random number from said application, of the type of the random number rand2 shown in [Fig. 3]. According to a first example, the derived random number can simply be compared to all the derived random numbers stored by the platform. According to a second example, the received derived random number can be compared to the random number associated with the digital resources and / or the memory area storing the digital resources to which the application requests access.According to a third example, if the derived random number is used to sign or encrypt digital resources, then the received random number is used to verify that it is indeed the one that was used to sign or encrypt the digital resources. Two or all three of the examples mentioned above can be implemented successively or simultaneously in step 453. If step 453 results in success (step 453 output Y), a step 454 (Access) is implemented; otherwise (step 454 output N) is implemented.

[0076] At step 454, the platform found digital resources associated with the random number of said application. The platform provides these resources to the application.

[0077] At step 455, the platform did not find a numerical resource associated with the random number of said application. Therefore, the platform does not provide a resource to the application. For example, the platform may provide error data to the application.

[0078] As an example, an application can change its random number during an update of its execution code. This allows the platform to avoid providing a digital resource stored by a previous version of an application to a newer version of that application. As a specific example, this allows the platform to thwart an application substitution attack.

[0079] Furthermore, by way of example, if a platform detects that an application associated with a first random number has changed its random number to a second random number, the possibility of deleting the stored digital resources can be considered. Similarly, by way of example, if a platform detects that an application associated with a first random number has changed its random number to a second random number, the new version of the application can be uninstalled and an older, more secure version can be reinstalled.

[0080] Various embodiments and variations have been described. A person skilled in the art will understand that certain features of these various embodiments and variations could be combined, and other variations will become apparent to a person skilled in the art.

[0081] Finally, the practical implementation of the embodiments and variants described is within the reach of a person skilled in the art, based on the functional indications given above.

Claims

Demands

1. System (200) comprising at least a first application (202) and a shared software platform (201), wherein each application (202) is identified by said software platform (201) by a first random number, said first random number being stored in encrypted form in an execution code of said first application (202), and a second number representing said first random number being stored in a first part of a memory accessible only to said platform (201).

2. System according to claim 1, wherein said second representative number of said first random number is generated by said software platform (201).

3. System according to claim 1 or 2, wherein said first random number is generated by a first original equipment manufacturer of said first application (202).

4. System according to any one of claims 1 to 3, wherein said first random number is modified during an update of said first application (202).

5. System according to any one of claims 1 to 4, wherein said execution code of said first application (202) is stored in a second part of memory that is not accessible to a second original equipment manufacturer of a second application (202) implemented by said platform (201).

6. System according to any one of claims 1 to 5, being a secure operating system embedded in a secure element.

7. Method for initializing (300) a system according to any one of claims 1 to 6, comprising the following successive steps: - sending, by said first application (202), said encrypted execution code to said platform (201); - extracting, by said platform (201), said first random number; - generating, by said platform (201), said second number; and - storing said second number.

8. A method according to claim 7, further comprising the following successive steps: - decrypting, by said platform (201), said execution code encrypted with a first decryption key; and - storing said decrypted execution code.

9. A method according to claim 8 as related to claim 5, wherein said decrypted execution code is stored in said second memory part.

10. A method according to claim 8 or 9 in its connection with claim 5, wherein said key is not known to said second original equipment manufacturer.

11. A method for storing (400) at least one first digital resource of said first application (202) of the system according to any one of claims 1 to 6, wherein said platform (201) stores said at least one digital resource and associates it with said second number.

12. A method according to claim 11, wherein the platform (201) uses said second number to sign and / or encrypt said at least one first digital resource.

13. A method according to claim 11 or 12, wherein said at least a first digital resource is stored in a third part of a memory.

14. Method of retrieving (450) at least a second digital resource associated with a third number by a third application (202) identified by a fourth random number, implemented by the system according to any one of claims 1 to 6, wherein said platform (201) verifies the concordance of said third and fourth numbers.

15. Method according to claim 14, wherein if the match is verified, said at least one second resource is transmitted to said third application (202) by said platform (201).

16. Method according to claim 14 or 15, wherein if the concordance is not verified, an error is transmitted to said third application (202) by said platform (201).

Images