Forum Stats

  • 3,839,693 Users
  • 2,262,529 Discussions
  • 7,901,042 Comments

Discussions

"patch" in java card?!

Bluefairy
Bluefairy Member Posts: 49
edited Jan 6, 2011 3:40PM in Java Card
Hi there,
I wanted to ask if someone has any information about "patch" concept in the java card technology? I'm not sure if "patch" is a proper word to describe it or not, I mean in the situations that you notice your applet needs an update because of some bug found in it or just because you want to add a capability into your applet how this will be handeled?
Will you just delete your applet and install a new one? As you know this operation(deleting the old applet) will remove all the eeprom and the user data will be lost. If the user data is important to be saved during this update process is there a proper way to save it and just install a new applet into the card?

-Thanks in advance
Tagged:

Best Answer

  • safarmer
    safarmer Member Posts: 2,829 Bronze Trophy
    Answer ✓
    Hi,

    You are correct in your assumption that you have to remove the old applet and then load a new one.

    If the data is important, you could have two applets on the card. One would be a data container and the other would have the application logic. You would access the data through Shareable Object Interfaces (SOI). You need to secure this though as it could mean that if your card is compromised, there is a means for any applet to access your data. In a single applet solution you do not have this problem as the firewall protects the data.

    Cheers,
    Shane

Answers

  • safarmer
    safarmer Member Posts: 2,829 Bronze Trophy
    Answer ✓
    Hi,

    You are correct in your assumption that you have to remove the old applet and then load a new one.

    If the data is important, you could have two applets on the card. One would be a data container and the other would have the application logic. You would access the data through Shareable Object Interfaces (SOI). You need to secure this though as it could mean that if your card is compromised, there is a means for any applet to access your data. In a single applet solution you do not have this problem as the firewall protects the data.

    Cheers,
    Shane
  • Bluefairy
    Bluefairy Member Posts: 49
    edited Dec 23, 2010 6:59AM
    Thanks Safarmer!

    I just wanted to know if the applet developer companies prefer to consume more time on testing their single applet instead of writing two applets with debugging capability?
    I think using one applet as a data container will cause speed problems. Comparing java card with the native cards it's slow enough and if we use another applet in order to store user data will enormously slow down the applet. Is it a common practice among applet developers to use two applet and SOI in their products?

    -Thanks as always

    Edited by: Bluefairy on Dec 23, 2010 3:58 AM
  • safarmer
    safarmer Member Posts: 2,829 Bronze Trophy
    Hi,

    I don't think it is a common practice, but we had no choice with our applet. We needed the ability to be able to update the application on the card without loosing any data. There were several private keys that only exist on the card so we could not reload the data when reinstalling. Also given the amount of data to load, it wasn't really practical to reload it all.

    The second applet (data container) that I mention has very little functionality. It literally takes the data you pass to it and places it where you specify. Then when you read from it, you say I want these bytes from this location. Two slow points with any smart card aplicaiton is cryptography (no additional crypto added here) and EEPROM writes (no additional writes added since the data needs to be written somewhere).

    You should remember that a poorly implemented applet in any language (native, Java, DotNet, MULTOS C/Java) will be slow. There are a few things that can be done to speed things up. Also, you may get added security at the expense of speed (applet firewall etc).

    Cheers,
    Shane
    safarmer
  • safarmer
    safarmer Member Posts: 2,829 Bronze Trophy
    safarmer wrote:
    I don't think it is a common practice
    Also, it is an interesting alternative considering the issues involved in reloading code with data. You may save a lot of time and money on redeploying updates in this way (I now we will have).

    Cheers,
    Shane
  • Jean-Damien LEBUI
    Jean-Damien LEBUI Member Posts: 95
    edited Jan 6, 2011 3:40PM
    This topic is very interesting to me.

    In fact, I spent nearly one year studying it and unfortunately, from a point of view of a "researcher", I think that at the moment, for monolithic application, there's no way "patching" Javacard-based application. The only solution is replacing it with the new version.

    However, I found this topic interesting and it could be helpful to some of you reading this article: http://portal.acm.org/citation.cfm?id=1828747
    (or: http://www.msi.unilim.fr/~noubissi/wiki/uploads/Publications/noubissi4.pdf)

    I spent a little more time working on javacard 3.0 connected edition with improved features hoping to implement an OSGi-cored middleware supporting dynamic update but unfortunately, my research was abandoned some months ago.

    I hope that this information would be helpful to you.

    Best regards,
    Hai-Binh LE
    Jean-Damien LEBUI
This discussion has been closed.