0

I wish to read some basic info from a bunch of smartcard from different vendors, different usage, different APDUs. For example : national identification smartcard, EMV (payment), cellphone SIM, javacard, etc ...

I wrote a Java application. Let me call the SC families A B C D E and with the same names the 5 subroutines, each one with the correct APDUs to read the basic info for one specific family of SC.

Unfortunately the order I issue the routines biases the successful results.

Example : with the subroutine order A B C D E, I can read SC of type A B C D, not E.

If I change the execution order to E A B C D, I can read E but now I fail with SC of type C.

I understand : some SC discard foreign APDUs ... other SC "hangs".

Is there a basic command to clean the state of smartcard ( and reader ) ?

So the order of execution of the subroutines doesn't change the output ?

A reset B reset C reset D reset etc...

Is it ATR ? Is it mandatory on each kind of SC ?

Massimo
  • 3,171
  • 3
  • 28
  • 41
  • That should not happen. What card reader are you using? Did you observe same behaviour with a different card reader? – arminb May 30 '17 at 10:27
  • Yes, two different card readers. Disregarding the specific tests : which is the universal way to reset the reader and the card state ? – Massimo May 31 '17 at 22:52

2 Answers2

1

The behaviour you described sounds really strange since a smartcard reader should not keep states between different smart cards.

However, I don't know any universal command to reboot smart card readers. For example HID OMNIKEY readers, you can reboot with proprietary APDU FF 70 07 6B 08 A2 06 A1 04 A9 02 83 00 00 (see here [7.6.3], though this guide says it is for OMNIKEY 5022 readers, it works for many more OMNIKEY readers). So for your reader you will have to research the internet for similar proprietary APDU.

Keep in mind that a reader reboot also most likely will cause the USB reader to re-enumerate.

arminb
  • 2,036
  • 3
  • 24
  • 43
1

You can use the Card.disconnect() method to reset card (beware of this).

But (IMHO) the best way is to use card ATR (as given by Card.getATR()) for guessing the correct card family (if possible). This way is also much faster. I used this approach for a demo handling several distinct contactless card products and it worked very well.

Some additional (random) notes:

  • Study the documentation for all families -- definitely there must be a reason for such behavior. Try to skip some subroutines and/or their APDU commands to pin it down.

  • In addition some APDUs might cause problems when sent accidentally (e.g. locked secret codes or locked authentication attempts). You should know what you are doing.

  • Most of product families have some way to be reliably detected -- see the documentation if you have it.

  • If any previously called subroutine uses SELECT to change selected application/file and succeeds it stays selected. Consider using explicit SELECT at the beginning of each of your subroutine (e.g. select expected AID or master file).

  • DESFire cards leave native mode and enter wrapped mode upon receiving non-native command APDU (which probably is not your case as you usually ISO wrap commands when using javax.smartcardio).

Good luck!

vlp
  • 7,811
  • 2
  • 23
  • 51