Method and system for the trusted association of multiple applications

Abstract

A method for the trusted association of multiple applications, comprising requesting, by a server applet, a digest of a binary code of a client applet, checking, by the server applet, the received digest against a reference digest that is deployed to the server applet, wherein if the received digest corresponds to the reference digest then the client applet is considered to be genuine.

Description

METHOD AND SYSTEM FOR THE TRUSTED ASSOCIATION OF MULTIPLE APPLICATIONSFIELD OF USE

[0001] Aspects of the present disclosure are directed toward associating multiple software applications in a trusted manner, in particular, applications running in Java Card Runtime Environments.BACKGROUND

[0002] Applications running in a Java Card (JC) Runtime Environment are isolated according to JC firewall rules but may still communicate with each other following the JC conventions of using Shareable Interface Objects (SIO). Upon request, a Server Applet may return such an SIO to a Client Applet, allowing this Client Applet to interact with the Server Applet.

[0003] Before it returns the SIO to the Client, the Server gets a chance to check a few things about the Client, so it would not provide this SIO to any applet but only to those Client Applets that may legitimately access this SIO.

[0004] Unfortunately, the standard Java Card API only provides very limited features to perform such checks. Typically, the API allows the Server Applet to check the AID of the Client Applet. But in many cases, this check does not guarantee that the Client Applet is genuine and really the one it claims to be (i.e., anyone could install an Applet instance identified by the same AID). In particular it is not enough for pairing scenarios.SUMMARY

[0005] An aspect of the disclosure is directed toward a method for the trusted association of multiple applications, comprising requesting, by a server applet, a digest of a binary code of a client applet, checking, by the server applet, the received digest against a reference digest that is deployed to the server applet, wherein if the received digest corresponds to the reference digest then the client applet is considered to be genuine.

[0006] In an aspect of the disclosure, the digest of the binary code of the client applet digest is computed and provided by a platform.

[0007] In an aspect of the disclosure, the digest is not provided by the Client Applet.

[0008] In an aspect of the disclosure, the reference digest value is not a cryptographic secret.

[0009] In an aspect of the disclosure, the digest is a Load File Data Block Hash (LFDBH).

[0010] In an aspect of the disclosure, the LFDBH is a hash computed by the platform of the data transferred when loading an Applet binary code to a secure element.

[0011] In an aspect of the disclosure, the digest is retrieved by invoking a new method of a GPRegistryEntry object representing the Applet.

[0012] An aspect of the disclosure is directed toward a system for managing a trusted association of multiple applications, the system a server and an embedded device, the server comprising a processor and memory, wherein the memory contains the steps for carrying out the following process: requesting a digest of a binary code of a client applet on the embedded device, checking the received digest against a reference digest that is deployed to the server, wherein if the received digest corresponds to the reference digest then the client applet is considered to be genuine.

[0013] In an aspect of the disclosure, the digest of the binary code of the client applet digest is computed and provided by a platform.

[0014] In an aspect of the disclosure, the digest is not provided by the Client Applet.

[0015] In an aspect of the disclosure, the reference digest value is not a cryptographic secret.

[0016] In an aspect of the disclosure, the digest is a Load File Data Block Hash (LFDBH).

[0017] In an aspect of the disclosure, the LFDBH is a hash computed by the platform of the data transferred when loading an Applet binary code to a secure element.

[0018] In an aspect of the disclosure, the digest is retrieved by invoking a new method of a GPRegistryEntry object representing the Applet.DESCRIPTION OF THE DRAWINGS

[0019] For a better understanding of the various described embodiments, reference should be made to the Description of Embodiments below, in conjunction with the following drawings in which like reference numerals refer to corresponding parts throughout the figures.

[0020] FIG. 1 demonstrates an exemplary method in accordance with aspects of the present disclosure; and

[0021] FIG. 2 demonstrates an exemplary system in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0022] In the following detailed description, reference is made to the accompanying drawings that show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments without departing from the spirit and scope of the invention. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and thescope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.

[0023] The following description includes references to various methods executed by a processor of an integrated circuit chip. As is common in the field, there may be phrases herein that indicate these methods or method steps are performed by software instructions or software modules. As a person skilled in the art knows, such descriptions should be taken to mean that a processor, in fact, executes the methods, software instructions, and software modules.

[0024] FIG. 1 demonstrates aspects of the disclosure, such as introducing the capability I a service for the Server Applet to request a digest (e.g., SHA- 256) of the binary code of the Client Applet, as in Step 101 .

[0025] The digest may be computed and provided by the platform (e.g., not the Client Applet itself), which ensures that it may be trusted, as in Step 105.

[0026] In step 108, the Server Applet may then check the retrieved digest against a reference digest proving the genuineness of the Client Applet. Such a Reference Digest Value must be deployed to the Server Applet, but since it may not be a cryptographic secret, it is thus easier to deploy.

[0027] In the context of the GlobalPlatform standard (SE specifications), this digest:-would be known as the Load File Data Block Hash (LFDBH), i.e. , a hash computed by the platform of the data transferred when loading the Applet binary code to the SE.-could be retrieved by invoking a new method of the GPRegistryEntry object representing the Applet.

[0028] A GPRegistryEntry object is a system object that represents a given Applet and allows retrieving general information about this an Applet. Each Applet is associated by the system to a distinct GPRegistryEntry object.

[0029] FIG. 2 demonstrates an aspect of the disclosure that is directed toward a system 201 for managing a trusted association of multiple applications. The system may include an embedded device 202 and a server 205.

[0030] Instead of being constituted by a physical device, a software component, such as a library, or a hardware component included within or connected to the device 202 carries out the functions that are described previously and that are performed by the system 201 .

[0031] The embedded device 202 includes one or several Central Processing llnit(s) (or CPU), (micro)processor(s) and / or (micro)controller(s) (not represented), as data processing means, one or several memories (not represented), as data storing means, and one or several Input / Output (or I / O) interfaces (not represented).

[0032] The (or each) processor processes data originating from and / or intended to any internal component and data originating from and / or intended to any external device through one or several I / O interfaces.

[0033] The memories may include one or several EEPROMs (acronym for “Electrically Erasable Programmable Read-Only Memory”), one or several ROMs (acronym for “Read Only Memory”), one or several Flash memories and / or any other memories of different types, like e.g., one or several RAMs (acronym for “Random Access Memory”).

[0034] The PC I / O interface(s) may include e.g., an antenna (not represented), allowing to transmit data, through e.g., a wireless link, via one (communication) network(s), such as Intranet and / or Internet, to the server 205.

[0035] The embedded device 202 is connected, through the link, be it wire or wireless, to the server 205.

[0036] The channel using the link may be secure or unsecure. The channel may be related to a HyperText Transfer Protocol (or HTTP) (registered trademark) type channel, an HTTP Secure (or HTTPS) type channel, a RESTful API communication or any other data communication channel.

[0037] Instead of being constituted by a physical server, it may be constituted by a software component, such as a library, or a hardware component included in (or connected to) the device carries out the functions that are described infra and that are performed by the server 205.

[0038] The server 205 is remote and accessible through possibly one, two or more communication networks, such as an Intranet network and / or an Internet network, that allow to define or form a corresponding communication channel.

[0039] According to an alternative embodiment (not represented), the server 205 or a software component is local. For example, the server is embedded within a device (not represented), such as a secure element that is connected or communicatively coupled to the embedded device.

[0040] The server 205 is preferably accessed through an associated Application Provider Interface (or API) or a Service Provider Interface (or SPI).

[0041] The server 205 includes one or several CPll(s), (micro)processor(s) and / or (micro)controller(s), as data processing means (not represented), one or several memories, as data storing means (not represented), and one or several I / O interfaces (not represented) that are internally together connected.

[0042] The (or each) server 205 processor processes data originating from and / or intended to any internal component and data originating from and / or intended to any external device through one or several server I / O interfaces.

[0043] The server 205 I / O interface(s) is(are) used for communicating with an external device(s), such as the system, so as to provide, through the system 201 , an adapted response that replaces a response to a data access request.

[0044] The server 205 memory(ies) store(s) preferably, besides an OS, one or several applications to be executed, so that the server 205 provides one or several corresponding services. For instance, an application stored by the server 205 and / or the embedded device 202 is an application to carry out the method described previously.

[0045] The disclosure proposes a simple yet effective method for the Server Applet to check that the Client Applet requesting the SIO is indeed the genuine applet it claims to be and not an Applet with a totally different binary code. The reference digest is not a secret data, hence managing it does not lead to the same burden as managing cryptographic secrets.

[0046] The proposed solution offers the following advantages:- People often think about more complex cryptographic solutions for pairing / association because the runtime environment where applications are running is not necessarily trusted. In this case, the SE is a trusted platform that offers reliable / trusted services.- More generally speaking, people tend to think about pairing methods that do not rely on platform services. In our case, the GlobalPlatform compliant environment offers an interoperable space where applications may leverage interoperable services to achieve pairing.

[0047] Although specific aspects of the disclosure have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts so described and illustrated. The invention is limited only by the claims.

Claims

CLAIMS1 . A method for the trusted association of multiple applications, comprising requesting, by a server applet, a digest of a binary code of a client applet, checking, by the server applet, the received digest against a reference digest that is deployed to the server applet, wherein if the received digest corresponds to the reference digest then the client applet is considered to be genuine.

2. The method according to claim 1 , wherein the digest of the binary code of the client applet digest is computed and provided by a platform.

3. The method according to claim 2, wherein the digest is not provided by the Client Applet.

4. The method according to claim 1 , wherein the reference digest value is not a cryptographic secret.

5. The method according to claim 1 , wherein the digest is a Load File Data Block Hash (LFDBH).

6. The method according to claim 5, wherein the LFDBH is a hash computed by the platform of the data transferred when loading an Applet binary code to a secure element.

7. The method according to claim 1 , wherein the digest is retrieved by invoking a new method of a GPRegistryEntry object representing the Applet.

8. A system for managing a trusted association of multiple applications, the system a server and an embedded device, the server comprising a processor and memory, wherein the memory contains the steps for carrying out the following process: requesting a digest of a binary code of a client applet on the embedded device, checking the received digest against a reference digest that is deployed to the server, wherein if the received digest corresponds to the reference digest then the client applet is considered to be genuine.

9. The system according to claim 8, wherein the digest of the binary code of the client applet digest is computed and provided by a platform.

10. The system according to claim 9, wherein the digest is not provided by the Client Applet.

11. The system according to claim 8, wherein the reference digest value is not a cryptographic secret.

12. The system according to claim 8, wherein the digest is a Load File Data Block Hash (LFDBH).

13. The system according to claim 12, wherein the LFDBH is a hash computed by the platform of the data transferred when loading an Applet binary code to a secure element.

14. The method according to claim 8, wherein the digest is retrieved by invoking a new method of a GPRegistryEntry object representing the Applet.

Images