Card does not return Status Word when data to retrieve exceeds 256 bytes

2
votes

I'm working with a card in T=0 protocol:

  • I send a command to the Card that request a response with data.
  • The applet I use is expected to answer with data, potentially more than 256 bytes, so in the command Le is set to '00'
  • Card first answers with 61 XX where 'XX' is the count of bytes to read (from 1 to 256).

  • Then I retrieve the data by sending a GET RESPONSE command:

    00 C0 00 00 XX

Expectation:

Regarding ISO7816-3, I expected the Card to respond with:

Procedure byte | Data | SW1 SW2

And if SW1 == 0x61, I would send:

00 C0 00 00 SW2

And so on, until eventually I get 90 00.

Reality:

However, this is what I actually have (TPDU level):

> Command
< 61 00

> 00 C0 00 00 00
< C0 (procedure byte)
< Data (256)
No Status Word, no procedure byte (timeout)

> 00 C0 00 00 00
< C0 (procedure byte)
< Data (256)
No Status Word, no procedure byte (timeout)

[...]

> 00 C0 00 00 00
< 61 39 (status word)

I have to repeatedly send GET RESPONSE with P3=00 (256), read the 256 bytes and got no Status Word until the Card warns me that there is actually less than 256 bytes to read.

I can't found the part of the specification that allows the card to "skip" the status word, or how to deal with answers longer than 256 bytes. Any pointer ?

2
smartcardisoapdu
which card and reader you are using. – Jitendra
"If the value [of the procedure byte] is the value of INS, apart from the values '6X' and '9X', it is an ACK byte. All remaining data bytes if any bytes remain, denoted Di to Dn, shall be transferred subsequently. Then the interface device shall wait for a character conveying a procedure byte." – JimmyB
No mention of SW1/SW2 in these successive transfers... – JimmyB
@vikky Neither card and reader are "official". I have a "dev" card and I am developing the reader's firmware. – n0p
You're right in that the card probably should send as many bytes as indicated by P3. - But then, P3 cannot encode a length greater than 256, so what to do in the case of more data? I think the spec allows doing this via the ACK byte mechanism where the card should(?) continue to stream chunks of data out by itself, which yours doesn't :-\ – JimmyB

2 Answers

2
votes

I figured it out: it was a timing issue.

The card do have a Status Word to send, however my process between the read operations was too long so by the time I requested it, it was no longer available in the card.

I should have highlighted that I was developing the reader part myself.

-1
votes

In T=0 protocol it is not possible to have data more than 256 bytes.

In your case, it might be a bug (or misunderstanding) of the protocol of your app which after retrieving 256 bytes it still sends 61XX back.

Actually it is not clear in your log what is the Status Word of your GET RESPONSE command, and if it is 9000, then everything is fine and no more discussion. In this case if you repeat GET RESPONSE command you might get the latest data again!

Just to answer your specific questions:

I can't found the part of the specification that allows the card to "skip" the status word

You can simply ignore it!

I mean if the card informs that it has some data available (61 XX) and you don't send any GET RESPONSE command but another command then the data will be lost.

or how to deal with answers longer than 256 bytes. Any pointer ?

In protocol T=0 it is not possible. You better use protocols T=1 or T=15 instead.

Or you can somehow workaround it by a bit enhanced protocol and then you should rewrite the app to support it (if the app is yours) and it might be not standard anymore!