6

I noticed some very strange behaviour on my smartcards (NXP J2E145, J3A081, J3C145 with an Omnikey 5121 reader): A power loss right after calling JavaCard method

JCSystem.requestObjectDeletion()

can damage the card: after about 10% of such power cuts the ATR command is very slow (1000ms) and I get no response to any other APDUs (applet selection, card manager authentication etc.).

I know that the behavior of requestObjectDeletion() depends on the vendor specific implementation, so my question is quite wide and open...

Is garbage collecting processed "usually" in a single transaction?

Is there any "official" recommendation NOT to call requestObjectDeletion() in case of a possible power loss?

Do you have any similar experience with cards by NXP?

EDIT:

  • JCSystem.isObjectDeletionSupported() == true on all my smartcards.

  • When trying to connect to the card manager applet of a damaged card, the JCOP shell in Eclipse IDE reports this:

    ATR: 3BFB9600008131FE454F4450204D41502053414D3E

    ATR: T = 1
    jcshell: Unknown problems with terminal. Last terminal error: The request could not be performed because of an I/O device error.

vojta
  • 5,591
  • 2
  • 24
  • 64
  • did you check boolean JCSystem.isObjectDeletionSupported() ? – Paul Bastian Jan 27 '15 at 09:57
  • I did not actually, but the garbage collector normally works fine and it does not throw any exception. The card is doing something after calling requestObjectDeletion (the light on the reader is blinking) for about 5 seconds and the EEPROM is cleaned (I checked it). The only problem is when I pull the card from the reader in the middle of this process. Then the card seems to be broken, sometimes. – vojta Jan 27 '15 at 12:51
  • Dear vojta, May I have your email address? I'm working on NXP smart cards also. I am sure that you can help me a lot, But I can't my questions here, because some off them are off-topic. –  Jan 31 '15 at 08:35
  • May I ask you to share the program that you upload on the card and the program that you run in the computer, with us? –  Jan 31 '15 at 09:38
  • Sorry, my applet is very complex and it is a crucial part of a commercial security project, so I really cannot share any code with you. If you have any questions, use Stack Overflow, please. – vojta Jan 31 '15 at 13:52
  • I think you cards is fine and the problem is about the tools on the computer. may I ask you to unplug and plug the reader to another port of your computer and test if the card is broken or not? I had the same error when I did a card tearing during applet installation. But when I unplugged the reader from the computer and plugged it again, the problem solved. ---- And about the questions that I have, I want to test a card based on Common Criteria requirements and as this site is for programming questions, I can't ask them here. Thank you. I waiting for the answer of first part of my comment –  Jan 31 '15 at 15:20
  • If didn't worked, Please do a restart, and update us. Thank you, –  Jan 31 '15 at 15:36
  • This is not a problem of one card and one reader. In our company there are about 20 broken cards so far, tested on several computers and other machines (as for example cash machines) with four reader types and various software... Restart really does not help... Thanks for your ideas! – vojta Jan 31 '15 at 19:08

1 Answers1

6

I think this may be an implementation bug. In general, garbage collection is never needed nor used on smart cards.

You should avoid Garbage Collection under any circumstances by good applet design. That way you should never run into memory problems. Applets are commonly installed only once in their lifetime and should be usable for the rest of the life-cycle of the card.

Garbage Collection generally takes too long for normal use cases. Maybe that is why the programmer of the Java Card or underlying system libraries didn't expect it to happen outside a secure environment.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
Paul Bastian
  • 2,597
  • 11
  • 26
  • 1
    I call garbage collector exactly once during the whole lifecycle of my applet. It is not crucial issue for me, I could avoid it easily. On the other hand, I think all provided features should be safe and working. Smartcards are used as secure tokens above all. If there is such a bug in NXP cards, it must be described with huge red letters on the front page of all their documentation. Nobody knows, what happened to EEPROM after such an unsuccessful garbage collecting! I asked NXP and I will post their answer in the moment I have it. Thanks for your answer, Paul! – vojta Jan 28 '15 at 16:38
  • @vojta Does they really confirmed that? So we must not call `requestObjectDeletion()` in case of a possible power loss? – Ebrahim Ghasemi Mar 11 '15 at 19:44
  • 2
    @Abraham I cannot tell you any details because of NDA, sorry. However, I accepted Paul`s answer, so it is highly probable they confirmed it :-) – vojta Mar 12 '15 at 06:38
  • It even takes to long for some production environments :) That said, *if* there is a place for it then it should be after personalization. Even then, you'd better reset & boot the card before sending it out into the field... – Maarten Bodewes Jun 07 '15 at 13:03
  • @paul-bastian Do you have suggestions on books or websites to consult about Applet design which makes garbage collection unnecessary? Where can I fond out about the dos and don'ts? – Dirk Jäckel Oct 06 '17 at 11:41
  • I think there is only one decent book from Zhiqun Chen, but it's pretty old. the rest is practice and experience. – Paul Bastian Oct 07 '17 at 12:59