Reputation: 1617
I'm doing some testing against a few unknown smart cards that I know to be ISO7816-4 compliant. The cards I have collected are all from the same operator and all of them can work interchangeably.
I have been sending APDU commands to the card via the Java SmartCardIO library and an ACR122U reader and also using a Android phone via the ISODEP library.
On my android device, I have sent the following apdu and everything works fine,
tag.transceive(new byte[] {(byte)0x80, (byte)0x30, (byte)0x03, (byte)0x00, (byte)0x00, (byte)0x00 })
All 10 out of 10 cards work find.
On my desktop I have the following code:
answer = channel.transmit(new CommandAPDU( new byte[] { (byte)0x80, (byte)0x30, (byte)0x03, (byte)0x00, (byte)0x00 } ));
this code works fine with 3 out of 10 cards, the other 7 I get a 6700 length incorrect error. For the remaining 7 I have to use this code,
answer = channel.transmit(new CommandAPDU( new byte[] { (byte)0x90, (byte)0x32, (byte)0x03, (byte)0x00, (byte)0x00,(byte)0x00, (byte)0x00 } ));
I also cannot use this code for the above 3 cards, I get a length incorrect error.
I can't figure out what is the issue, why will adding an extra 2 null bytes make it work? I'm not facing this issue on my android device, all cards work with just one string.
Upvotes: 0
Views: 877
Reputation: 5333
Since all these instructions are of the proprietary range, I'm not too confident about meaning and cases (DECREASE?), but assume, that they are case 4 allowing command data and response.
All your APDUs are clearly malformed. If you have no command data, LC=0 must not be specified. The zeroes also can't be LE, since this is either encoded in one byte (short) or 3 bytes (extended length) in absence of LC. That appending two zero bytes works, means, that you are switching to extended length somewhat successfully,
I recommend to refer to ISO 7816-4, chapter command response pairs.
Upvotes: 2