2

Consider a situation in which personalization is done on card and amount of new data are stored in javacard, If we have a small change in aplet and wants to update applet version on javacard, what would happend to previousely stored data on card, as each applet has its own security domain(SD), I think all data are stored in the current applet's SD, so new installation yields to deletion of previous applet, Then what happend to store data?

Regards

Hana Bzh
  • 2,212
  • 3
  • 18
  • 38

2 Answers2

2

Found the answer googling the web : check this link

In the link, safarmer said:

Unfortunately you can only delete and the install again. From my understanding this is due to the limited resources on the card. You would need to have two copies of the applet on the card to do an atomic update and then delete the original. I don't think this is a very feasible approach.

The key to doing this is having it done in a controlled environment so you have complete control and can rerun in case of card tear etc. i.e. not update online across the internet.

Also:

You define an applet that stores data and a SIO that you can use to access this applet. The business logic goes into another applet and calls the methods on the interface to get or set data in the other applet. Your business logic can be deleted and reinstalled without affecting data. This is the simplified one paragraph version.

Hana Bzh
  • 2,212
  • 3
  • 18
  • 38
  • Hi Hana, if you haven't already, please read the FAQ. Answers containing only links to offsite resources are not accepted on Stackoverflow (it tries to collect all information itself, and links may disappear - links to Oracle resources doubly so). Could you put the gist of the post on Oracle in your answer? Happy to upvote if you do, and you can accept your own answer after a while. – Maarten Bodewes Nov 10 '13 at 10:33
  • Of course my Question is not yet answered, is there any implemented sample for this situation? I'm totally confused – Hana Bzh Nov 11 '13 at 15:25
  • Maybe not, but it would not be that hard tom implement, just create two packages, create an instance of both, call one package from the package containing the applet, then delete/reinstall the applet. I would be very surprised if there aren't any examples that share data through the firewall... – Maarten Bodewes Nov 11 '13 at 18:55
2

This is the result of my searching about SIO :

Shareable interfaces are a feature in the Java Card API to enable applet interaction.To the owning context, the SIO is a normal object whose fields and methods can be accessed. To any other context, the SIO is an instance of the shareable interface, and only the methods defined in the shareable interface are accessible. All other fields and methods of the SIO are protected by the firewall. Shareable interfaces provide a secure mechanism for inter-applet communication, as follows:

Server applet A builds a Shareable Interface Object

  1. To make an object available for sharing with another applet in a different context, applet A first defines a shareable interface, SI. A shareable interface extends the interface javacard.framework.Shareable. The methods defined in the shareable interface, SI, represent the services that applet A makes accessible to other applets.

  2. Applet A then defines a class C that implements the shareable interface SI. C implements the methods defined in SI. C may also define other methods and fields, but these are protected by the applet firewall. Only the methods defined in SI are accessible to other applets.

  3. Applet A creates an object instance O of class C. O belongs to applet A, and the firewall allows A to access any of the fields and methods of O.

Client applet B obtains the Shareable Interface Object

  1. Applet B can request service from applet A by invoking one of the shareable interface methods of SIO. During the invocation the Java Card VM performs a context switch. The original currently active context (B) is saved on a stack and the context of the owner (A) of the actual object (O) becomes the new currently active context. A’s implementation of the shareable interface method (SI method) executes in A’s context.

  2. The SI method can find out the AID of its client (B) via the JCSystem.getPreviousContextAID method. The method determines whether or not it will perform the service for applet B.

  3. Because of the context switch, the firewall allows the SI method to access all the fields and methods of object O and any other object in the context of A. At the same time, the firewall prevents the method from accessing non-shared objects in the context of B.

  4. The SI method can access the parameters passed by B and can provide a return value to B.

  5. During the return, the Java Card VM performs a restoring context switch. The original currently active context (B) is popped from the stack, and again becomes the currently active context.

  6. Because of the context switch, the firewall again allows B to access any of its objects and prevents B from accessing non-shared objects in the context of A.

Hana Bzh
  • 2,212
  • 3
  • 18
  • 38
  • you can check this link : (http://pfa12.free.fr/doc_java/javacard_specifications/specs/jcre/html/JCRESpec06firewall.html) Also you can find a sample code in here : (http://stackoverflow.com/questions/12394579/javacard-shareable-interface-lookupaid-returns-aid-but-getappletshareableinterf) – Hana Bzh Nov 18 '13 at 16:55