Shared contexts of applets loaded onto a data carrier

Abstract

Embodiments relating to methods and an interface for implementing a shared context between a plurality of applets and a Java Card data carrier with a Java Card runtime environment and a storage device are provided. In a server applet, a shared interface is implemented which allows a client applet to join a context of the server applet. The server applet receives a request from the client applet via the shared interface to join the context of the server applet. In response thereto, the server applet instructs the Java Card runtime environment to integrate the client applet into the context of the server applet.

Description

[0001] Shared contexts for applets loaded onto a disk

[0002] The present invention relates generally to the handling of contexts and applets for Java Card applications on smart cards, and more particularly to exemplary embodiments for implementing contexts shared by a plurality of applets loaded onto a smart card.

[0003] BACKGROUND OF THE INVENTION

[0004] Smart cards and similar data storage devices are used worldwide in a wide variety of applications. A smart card is a card-shaped data storage device with an embedded integrated circuit (IC), often referred to as a chip or microprocessor. It is used in credit and debit cards, transport cards, SIM cards, ID and identity cards, and the like. The embedded IC serves to store data, provide additional security, and provide other functionalities of the smart card.

[0005] Java Card technology (Java Card for short) was introduced to enable programs written in the Java programming language to run on chip cards and other small, resource-limited storage devices.

[0006] Due to the limited resources on smart cards, Java Card provides an operating system that includes a slimmed-down version of the usual Java virtual machine, the so-called Java Card Virtual Machine (JCVM). An implementation of the JCVM, along with Java Card API classes, is provided by the Java Card Runtime Environment (JCRE). The JCRE places additional requirements on the runtime security of storage devices that implement the JCRE. One such security requirement is the isolation of applets and the sharing of shared objects. This basic runtime security feature, enforced by the JCRE, isolates applets using what is known as an applet firewall.The applet firewall prevents objects created by one applet from being used by another applet. Essentially, these firewalls divide the JCRE object system into separate, protected object areas called contexts. This prevents unauthorized access to data and methods of class instances.

[0007] The current implementation of the Java Card runtime environment, JCRE, supports the isolation of contexts and applets. Fig. 1 shows the object system 10 of the Java Card platform with multiple contexts 12, 16 stored within the applet area and isolated from each other by the firewall 2. The applets 14, 14', 18, and 18' are stored in their respective contexts. Applets belonging to the same context are stored in the same compressed applet or the corresponding CAP file. An applet instance A1, designated by the reference numeral 14, can freely access objects belonging to the applet instance A2, 14', located in any package within the same Java Card CAP file A. However, additional mechanisms are required to access objects in a different context. The JCRE maintains its own JCRE context 11 for storing special system privileges.The context 11 of the JCRE is separated from the applet area by the firewall 4.

[0008] Applet isolation requires a mechanism that allows applets to share objects in situations where interoperability is required. The JCRE implements object sharing, or sharing between applets, through the concepts of shared interfaces and shared interface objects. A shared interface defines a set of shared methods within the interface. These interface methods can be called from one context, even if the object implementing them is owned by an applet in a different context. An object instance of a class that implements a shareable interface is called a Shareable Interface Object (SIO).

[0009] Fig. 2 illustrates the sharing of objects, i.e., making them available for shared use by different applets via a shared interface, such as that implemented in the JCRE. If context 1 is the active context and a method ml is called in an object belonging to applet A1, no context switch occurs. If method ml calls a method m2 in an object belonging to applet A2 via a method call (0), no context switch occurs and no firewall restrictions apply. However, if method m2 calls a method mO in an object belonging to applet B1, firewall restrictions apply, and if access is permitted, a context switch occurs (i). When returning to method m2 from method mO, the context of applet A2 is restored (ii). Both the context switch and the context restoration are implemented via the shared interface.Specifically, applet B1 must implement a SIO in its context 2 to make its objects available for sharing with applet A2 in context 1. When applet A2 wants to access applet B1 (i.e., when method m2 calls method mO), applet A2 calls the SIO via the established shared interface, after which the context switch is performed by the JCVM. A similar procedure is implemented for restoring the context after returning to m2.

[0010] Although context switching via shared interfaces provides a secure mechanism for communication between applets, it has several vulnerabilities. A shared interface is a permanent bridge between two contexts and must be used whenever an interaction is implemented between applets within different contexts. Accessing objects via a shared interface therefore has significant performance and memory footprint implications.

[0011] Providing modular extensions at runtime, such as extending the UICC file system, requires access to existing objects. Therefore, the extension must be located in the same context. For applets from different CAP files, which therefore belong to different contexts, modular code extension at runtime is therefore difficult to implement.

[0012] When personalizing smart cards, the usual solution involves loading the target code into a first context of the smart card via a first package, while the personalization code is loaded via a second package and installed in a second context. Some applets require a significant amount of space in the one-time personalization code. To release the personalization code after personalization, it could be stored in additional CAP files and then deleted. The personalization code must then be located in the same context as the target code.

[0013] Furthermore, so-called "patching" requires a certain amount of time to adapt the data and / or structure of existing objects. Therefore, patching code could be made easier if the patching code belongs to the same context as the objects to be changed.

[0014] It is therefore the object of the present invention to propose a solution to the aforementioned disadvantages.

[0015] SUMMARY OF THE INVENTION

[0016] The present invention solves the above-mentioned problem by the subject matter specified in the independent claims. Preferred embodiments of the invention are defined in the dependent claims.

[0017] According to a first aspect of the present invention, a method is provided for implementing a shared context between a plurality of applets in a Java Card storage medium, the Java Card storage medium comprising a Java Card Runtime Environment (JCRE) and a memory, wherein at least a first, or server, applet of the plurality of applets is installed in a first context in the memory. The method is performed with respect to the first, or server, applet. In a first step, the server applet implements a shared interface to allow a second, or client, applet to join the server applet's context. In a further step, the server applet receives a request from the client applet to join the server applet's context via the shared interface. The server applet then instructs the JCRE to integrate the client applet into the server applet's context.

[0018] By implementing the context sharing method, an applet or Java code is permanently integrated into the context of another applet or Java code, i.e., it is installed or transferred there. All applet objects within the context are thus fully accessible to every applet in that context. This overcomes the restriction that access to objects of different applets could previously only be achieved via dedicated, shared interfaces. According to the invention, the shared contexts enable efficient implementation of applet extensions at runtime as well as the deletion of applets. Furthermore, inter-applet communication, i.e., communication between applets, is improved while reducing memory requirements.

[0019] According to some embodiments of the present invention, the shared interface is implemented as a public interface that defines a set of methods shared between the contexts. In particular, a context join method is defined through which other applets from the plurality of applets can request to join the server applet's context.

[0020] Preferably, the server applet receives the request to join the context of the server applet by calling the method parameterized with an applet object of the client applet.

[0021] An efficient way to implement a context switch is provided by the public interface defined by the server applet.

[0022] According to some embodiments of the present invention, the method according to the first aspect comprises performing a security check on the server applet to verify the admissibility of the context join request. Preferably, the security check checks whether a client applet identifier corresponding to the applet object received by calling the context join method is contained in a list of expected or permissible applet identifiers, the AIDs.

[0023] For example, the list of expected or allowed AIDs can identify those applets that have been selected to participate in inter-applet communication. An applet that is not allowed to participate in inter-applet communication is not allowed to join the context.

[0024] Security can be increased by additional checks, such as verifying the requesting applet against other applets that already exist in the context to be joined.

[0025] In some embodiments of the present invention, the server applet instructs the JCRE to integrate the client applet into its own context by sending a context sharing notification to the JCRE. This context sharing notification initiates context sharing by the JCRE.

[0026] Preferably, the context split notification is implemented as a system API method that receives the client applet as input and returns "TRUE" or a comparable value or value with comparable meaning if the context join request is valid. Otherwise, "FALSE" or a comparable value or value with comparable meaning is returned. According to some embodiments of the present invention, an instance of the split interface through which the server applet received the context join request from the client applet is deleted after the client applet is integrated into the server applet's context.

[0027] Since the instance of the shared interface is only needed to maintain the client applet's object reference, it can be removed after integration into the server applet's context, thereby reducing the server applet's memory footprint.

[0028] According to a second aspect of the present invention, a method is provided for implementing a shared context between a plurality of applets in a Java Card storage medium, the Java Card storage medium comprising a Java Card Runtime Environment (JCRE) and a memory, wherein at least a first or server applet of the plurality of applets is installed in a first context in the memory. The method is performed with respect to a client applet and comprises, in a first step, establishing communication with the server applet via a shared interface provided by the server applet. In a subsequent step, a context join request is sent to the server applet to join the context of the server applet.

[0029] According to some embodiments of the present invention, the establishment of communication with the server applet is implemented by the client applet by sending a context join notification to the JCRE, which specifies the server applet whose context the client applet should join. This context join notification communicates or confirms to the JCRE the client applet's desire or willingness to join the server applet's context. Preferably, the context join notification is implemented as a call to the method JCSystem.getAppletShareablelnterf aceObj ect(AID serverAID) by the client applet, where the parameter serverAID identifies the server applet.

[0030] Preferably, upon or after receiving the shared interface, i.e., the SIO of the server applet, the client applet sends the request to join the context of the server applet by calling a method provided by the server applet via the shared interface.

[0031] According to a third aspect, a method is provided for implementing a context shared between a plurality of applets in a Java Card storage medium, the Java Card storage medium comprising a Java Card Runtime Environment (JCRE) and a memory, wherein at least a first or server applet of the plurality of applets is installed in a context in the memory. The method is performed with respect to the JCRE. In a first step, a context joining notification is received from a second or client applet, indicating an applet identifier, AID, of a first applet installed in a first context. In further steps, a context sharing notification is received from the first or server applet, and the second or client applet is installed in the first context if the context sharing notification has the value "TRUE" or a comparable value.has a value of comparable significance.

[0032] According to some embodiments according to the third aspect of the present invention, the JCRE installs the second applet in its own context, or the second applet remains in its own context, if the received context sharing notification has the value "FALSE" or a comparable value or a value with comparable meaning.

[0033] According to some embodiments, the context joining may occur during installation of the second applet or later at execution time.

[0034] According to another aspect, a shared interface is provided that defines a set of shared methods that are made available by a server applet to a client applet of a plurality of applets loaded in a Java Card storage medium to implement inter-applet communication. The shared interface defines a method to be called by the client applet, which method is parameterized with an Applet object of the client applet.

[0035] This interface enables the implementation of contexts that are or can be shared between the applets of a Java Card disk after loading.

[0036] According to a further aspect, a computer program product is provided comprising a set of instructions for performing the following steps: loading a first package onto a Java Card storage medium comprising a first applet, the Java Card storage medium comprising a Java Card Runtime Environment (JCRE) and a memory; installing the first applet in a first context in the memory of the Java Card storage medium; loading a second package onto the Java Card storage medium comprising a second applet; performing the steps according to any embodiment of the first aspect of the present invention relating to the first or server applet; performing the steps according to any embodiment of the second aspect of the present invention relating to the second or client applet; and performing the steps according to any embodiment of the third aspect of the present invention relating to the JCRE.

[0037] Further aspects, features and advantages of the present invention will become apparent to those skilled in the art upon studying the following detailed description of preferred embodiments and variants of the present invention in conjunction with the accompanying figures.

[0038] BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Reference is now made to the attached figures, which show:

[0040] Fig. 1 is a schematic representation of contexts within the object system of a Java Card platform;

[0041] Fig. 2 is a schematic representation of a context switch and an object access as conventionally implemented in the object system of the Java Card platform according to Fig. 1;

[0042] Fig. 3 is a schematic representation of shared contexts implemented on the object system of the Java Card platform according to an embodiment of the invention;

[0043] Fig. 4 is a flow and signal diagram illustrating function calls for implementing context sharing according to one embodiment of the invention; Fig. 5 is a flow diagram for the method of Fig. 4 as implemented with respect to a server applet according to one embodiment of the invention;

[0044] Fig. 6 is a flowchart for the method of Fig. 4 as implemented with respect to a client applet according to an embodiment of the invention; and

[0045] Fig. 7 is a flowchart for the method of Fig. 4 as implemented with respect to the Java Card runtime environment according to an embodiment of the invention.

[0046] DETAILED DESCRIPTION

[0047] The present invention will now be explained in detail with reference to the accompanying drawings. These drawings illustrate specific embodiments of the present invention. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It should be understood that the various embodiments of the present invention are not mutually exclusive, although they are fundamentally different. For example, a particular feature, structure, or characteristic described in connection with one embodiment may be implemented in other embodiments without departing from the scope of the present invention.Furthermore, it is also to be understood that the position or arrangement of individual elements within each disclosed embodiment may be modified without departing from the scope of the present invention. The following detailed description is therefore not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, which are to be construed taking into account all equivalents arising from them and the present description. In the drawings, like reference numerals refer to the same or similar functionalities throughout the different views.

[0048] In particular, the present invention and the embodiments and alternative embodiments described below can be implemented in the form of software on the Java Card platform or within a Java Card data carrier. The embodiment of the methods and subject matter of the present invention as installable and / or executable software is thus part of the scope of application or protection of the present invention.

[0049] Referring to Fig. 2, Fig. 3 shows the object system 10 of the Java Card platform implementing the methods according to embodiments of the present invention. In particular, two views of the system are shown: Fig. 3(a), which shows the state of the object system 10 of the Java Card platform before context sharing, and Fig. 3(b), which shows the state of the object system 10 of the Java Card platform after implementation of context sharing according to embodiments of the present invention.

[0050] With reference to Fig. 3(a), the applet area is divided into two contexts, namely Context 1, denoted by reference numeral 12, and Context 2, denoted by reference numeral 16. An applet A 14 is stored in Context 1, while an applet B 18 is stored in Context 2. The method ml belongs to an object belonging to applet A. The method m2 belongs to an object belonging to applet B. Furthermore, a shared interface 20 between applet A and applet B is shown. In the embodiment of Fig. 3, the shared interface is implemented by applet A, while applet B requests to join the context of applet A via the shared interface 20. To do so, applet B invokes certain methods provided via the shared interface 20, as described below with reference to Figs. 4 and 5.

[0051] As shown in Fig. 3(b), during or after the implementation of the context part, applet A shares its context with applet B. 18 That is, applet B is integrated into context 1 and thus no longer belongs to its original context, context 2 in Fig. 3(a). All objects of both applets A and B are thus shared and fully accessible to each applet.

[0052] Fig. 3(b) shows the state of the Java Card platform's object system 10 after context sharing has been implemented. The original context 2 of applet B has been deleted and removed from the applet space, freeing up memory space. Furthermore, the shared interface 20 can also be deleted, as it is only needed for the initial acquisition of the object reference of the SIO provided by applet A. Therefore, there is no need to maintain the shared interface permanently, as is required in conventional solutions.

[0053] Embodiments of the proposed method for implementing context sharing of loaded applets are described below with reference to Figures 4 to 7.

[0054] The general idea of ​​the present invention is to implement so-called post-load sharing, i.e., the ability to transfer an existing context created in the past by a first CAP file to a second CAP file that is loaded / installed later. Figure 4 shows a flow and signal diagram illustrating function calls for implementing this post-load sharing of contexts.

[0055] In a first step S1, the Java core 8 (JavaCore; part of the JCRE) receives a function or method call from a content management unit 6, which instructs the loading of a package or CAP file containing an applet A. In step S2, a function or method call instructs the Java core 8 to install the applet A.

[0056] The corresponding context, created by a first CAP file (package A), is now extended by a second package B, which the Java kernel 8 receives from the content management unit 6 in step S3, which is loaded into the JCRE in step S4, and installed in step S6. Preferably, applet B is installed in its own context.

[0057] Applet B is the client applet 18 and wishes to join the context of the server applet A 14. To do this, the client applet B must establish communication with the server applet A to obtain its SIO. This is done via the shared interface 20 (see Fig. 3(a)), which is implemented by applet A. Details of the implementation procedure for applet A are explained below with reference to Fig. 5.

[0058] To communicate with the server applet 16, the client applet 18 can call the method getAppletShareableInterfaceObject (AID A) in step S7. This is a method contained in the JCSystem class of the JCRE or the Java core, which is called by a client applet to communicate with a server applet. The method is called with the applet identifier AID of the server applet and returns the server applet's SIO.

[0059] In step S8, the client applet 18 calls a method j oinContext (Applet applet ) that specifies the applet object the client applet wishes to join. In the exemplary embodiment of Fig. 4, the applet 18 may call the method j oinContext (A). The method may be executed by Applet A 14, after which Applet B 18 is added to the context of Applet A in step S9 by a method call shareContext (Applet B ).

[0060] An embodiment of the above-described method for implementing a shared context, as implemented by the server applet, is described below with reference to Fig. 5.

[0061] If the server applet shares or wants to share its context for sharing, it must implement a shared or shareable interface, e.g., the shared interface 20 shown in Fig. 3. This is done in step S11 of Fig. 5.

[0062] A preferred implementation of the shared interface according to one embodiment is as follows:

[0063] I * *

[0064] * Example of an interface from applets to

[0065] * implement that defines its context with a

[0066] * want to share with another applet .

[0067] * / public interface SharedContext extends Shareable {

[0068] / * *

[0069] * Called by the client to join the context of this * applet.

[0070] *

[0071] * @param applet Applet

[0072] * Object that wants to join the context.

[0073] * / void oinContext (Applet applet );

[0074] }

[0075] Preferably, the shared interface is implemented as a public interface that defines a set of methods shared between contexts. In particular, a joinContext method is defined through which other applets from the plurality of applets can request to join the context of the server applet.

[0076] Preferably, other applets send context join requests to the server applet through instances of the shared interface.

[0077] Preferably, the server applet implements the method getShareableln-terfaceOb ect ( clientAID, byte ). This method can be called by the JCRE to mediate between the client applet requesting use of another applet's object and the server applet making its object available for shared use.

[0078] In step S12, the server applet 14 receives a request to join the server applet's context from the client applet 18 via the joinContext (Applet B) method call. The server applet retrieves the corresponding applet entry using the passed AID and, in step S14, calls a context sharing notification, preferably via the shareContext system API method provided in the AppletEntry class, to instruct the JCRE to integrate the client applet into the server context. I * *

[0079] * Shares the context with the specified applet .

[0080] *

[0081] * @param applet applet object of the applet,

[0082] * who wants to join

[0083] * @return true if the release was successful,

[0084] * otherwise false

[0085] * / public native boolean shareContext (Applet applet );

[0086] A preferred implementation of the server applet can look like this: void j oinContext (Applet applet ) {

[0087] / / Carry out safety checks to see if the

[0088] / / sharing the context for the applet / / is allowed

[0089] AppletEntry entry = (AppletEntry) JCSystem. getAID ( ) ; entry . shareContext(applet);

[0090] }

[0091] Referring to Fig. 5, in step S13, the server applet 14 may implement a security check to verify whether the context join request is permissible. A preferred implementation of the security check consists in checking whether a client applet identifier (clientAID) corresponding to the applet object received by the joinContext method call is included in a list of expected applet identifiers, the AIDs.

[0092] Optionally, in step S15, the server applet may delete the instance of the shared interface 20 through which the server applet received the context join request from the client applet, since the instance of the shared interface is only needed to obtain object references from applets and not for permanent use.

[0093] FIG. 6 shows a flowchart for the method of FIG. 4, as implemented in a client applet. In a first step S21, the client applet establishes communication with the server applet by sending a context join notification to obtain the server applet's Shareable Interface Object (SIO). Preferably, this is implemented by the client applet by calling a method JCSystem . getAppletShareablelnterf aceObj ect (AID serverAID), where the parameter serverAID identifies the server applet (for example, as implemented in step S7 of FIG. 4).

[0094] After the client applet receives the SIO, it sends a context join request to the server applet in step S22 to join its context. A preferred implementation of this request is for the client applet to call the joinContext method, which the server applet provides via the SIO.

[0095] Fig. 7 shows a flowchart of the method of Fig. 4 as implemented in the JCRE according to another embodiment of the invention.

[0096] In step S31, the JCRE receives the Join Context Notification (JCN) sent by the client applet in step S22 (Fig. 6). In step S32, the JCRE receives the Join Context Notification (JCN) sent by the server applet in step S14 (Fig.

[0097] 5) Sent Share Context Notification (SCN). As already mentioned in connection with Fig. 5, the Share Context Notification returns the value "TRUE" or a comparable value or a value with comparable meaning if shared context is permitted, i.e., if the server applet allows the client applet to join its context. Otherwise, it returns "FALSE" or a comparable value or a value with comparable meaning. Therefore, in step S33, the JCRE can check the value of the Share Context Notification, i.e., the value returned when the joinContext method is called. If this value is "TRUE" or comparable, the JCRE installs client applet B in the context of server applet A. If the value is "FALSE" or comparable, the client applet B can be installed in its own context in step S36.Preferably, in step S35, the original context of the client applet B is deleted after the client applet B has been installed in the context of the server applet A.

[0098] After installing client applet B in the context of server applet A, the objects of both applets are fully accessible to both applets A and B, without requiring further interaction via the shared interface or context switching, as is the case with conventional solutions. Both the shared interface implemented by the server applet and the original context of the client applet can be deleted, allowing for efficient memory management for the Java Card disk.

[0099] The aspects and embodiments described here thus eliminate the disadvantages and limitations associated with maintaining a shared interface and the otherwise required context switching for communication between applets, and offer several advantages, including: For smart card applications, the personalization code added to the context of the target code can be easily deleted after personalization. This means that the personalization specification (CPS) package and all code related to personalization can be removed once all personalization steps are complete. This reduces the storage space required on the resource-poor disk.

[0100] The functionality of applets can be easily extended by installing new functions for a specific applet within the existing context.

[0101] Updating the code while preserving existing data is possible without serializing and deserializing objects.

[0102] The shared context provides an optimized way for multiple applets to share their access. Access is checked only once before joining the context, and all subsequent accesses run in the same context with optimized firewall checks.

[0103] An access check can be flexibly implemented in the j oinContext ( ) method according to security requirements by reusing the shared interface.

[0104] In the foregoing description, the invention was described with reference to specific embodiments, preferably within the context of software solutions. It has become clear that various modifications and changes can be made without departing from the scope of the invention. The method sequences described above are described, for example, with reference to a specific sequence of method steps. However, the sequence of many of these method steps can be changed without affecting the scope or functionality of the invention. The description and the figures are therefore to be understood as illustrative rather than restrictive.

Claims

Patent claims 1. Method for implementing a context shared between a plurality of applets in a Java Card storage medium, wherein the Java Card storage medium comprises a Java Card runtime environment, JCRE, and a memory, wherein at least one first or server applet (14) of the plurality of applets in a first context (12) is installed in the memory, wherein the method relating to the server applet (14) comprises: Implement (Sil) a shared interface (20) to allow a second or client applet (18) to join the context (12) of the server applet (14); Receiving (S12) a request to join the context of the server applet (14) from the client applet (18) via the shared interface (20); and instructing (S14) the JCRE to integrate the client applet (18) into the first context (12) of the server applet (14).

2. The method of claim 1, wherein the shared interface (20) is implemented as a public interface that defines a set of methods shared between contexts, and in particular defines a context joining method by which other applets of the plurality of applets can request to join the context of the server applet (14), wherein the request to join the context (12) of the server applet (14) is received by calling the context joining method, which is parameterized with an applet object of the client applet (18).

3. Method according to claim 1 or 2, further comprising, with respect to the server applet (14), implementing (S13) a security check to verify whether the request to join the context (12) is permissible.

4. Method according to claim 3, wherein the security check comprises a check to see if a client applet identifier corresponding to the applet object received by calling the method to join the context is included in a list of valid applet identifiers, AIDs.

5. Method according to any one of claims 1 to 4, wherein the server applet (14) sends a notification about the context split to the JCRE (8) to instruct the integration of the client applet (18) into the server applet context (12).

6. The method of claim 5, wherein the context sharing notification is implemented as a system API method which receives the client applet as input and returns “TRUE” or a value of comparable meaning if the request to join the context is permissible, and otherwise returns “FALSE” or a value of comparable meaning.

7. Method according to one of the preceding claims, further comprising deleting an instance of the shared interface (20) after integrating the client applet (18) into the context (12) of the server applet (14).

8. Method for implementing a context shared between a plurality of applets in a Java Card storage medium, wherein the Java Card storage medium comprises a Java Card runtime environment, JCRE, and memory, wherein at least one first or server applet (14) of the plurality of applets is installed in a first context (12) in the memory, and wherein the method relating to a second or client applet (18) of the plurality of applets comprises: Establishing communication with the server applet (14) via a shared interface (20) provided by the server applet (14); and Sending a request to join the first context (12) of the server applet (14) to the server applet (14).

9. Method according to claim 8, wherein establishing communication with the server applet (14) is implemented by sending a notification about the context joining to the JCRE (8), which specifies the server applet (14) to whose context (12) the client applet (18) joins, wherein the notification about the context joining is preferably a call to a Java Card System method JCSystem . getAppletShareablelnterf aceObj ect (AID serverAID) is implemented.

10. Method according to claim 8 or 9, wherein the client applet sends the request to join the context (12) of the server applet (14) by calling a method provided by the server applet (14) via the shared interface (20).

11. Method for implementing a context shared between a plurality of applets in a Java Card storage medium, wherein the Java Card storage medium comprises a Java Card runtime environment, JCRE, and a memory, wherein at least one first or server applet (14) of the plurality of applets in a first context (12) is installed in the memory, wherein the method relating to the JCRE comprises: Receiving a notification about the context joining from a second or client applet (18), which specifies an applet identifier, AID, of the server applet (14); Receiving a context-sharing notification from the server applet (14), wherein the context-sharing notification specifies an AID of the client applet (18); and Install the client applet (18) within the first context (12) if the context sharing notification is “TRUE” or a value of comparable meaning.

12. Method according to claim 11, further comprising, if the received notification about the context sharing is “FALSE” or a value of comparable meaning, installing the client applet (18) in its own context.

13. Method according to claim 11 or 12, wherein the notification of the context joining of the second applet is received during the installation of the second applet or later at execution time.

14. Shared interface (20) comprising a set of shared interface methods that are made accessible by a server applet (14) to a client applet (18) to a plurality of applets loaded in a Java Card data carrier to implement communication between applets, wherein the shared interface defines a method to be called by the client applet (18), wherein the method is parameterized with an applet object of the client applet (18).

15. Computer program product comprising a set of instructions for performing the following steps: Loading (Sl) a first package comprising a first applet (14) onto a Java Card disk, wherein the Java Card disk comprises a Java Card runtime environment, JCRE, (8) and a memory; Installing (S2, S5) the first applet (14) in a first context (12) in the memory of the Java Card disk; Loading (S3) a second package comprising a second applet (18) onto the Java card disk; Performing the steps according to any one of claims 1 to 7 relating to the first applet (14); Performing the steps according to one of claims 8 to 10 relating to the second applet (18); and - performing the steps according to one of claims 11 to 13 relating to the JCRE (8).

Images