CODEWITHSUNDEEP
smartcardisoapdu
Berbus
Berbus

Reputation: 179

Is there any indicative of the size of the data field within a smart card's response to an APDU?

I understand that when an APDU is issued through a smart card reader the result has a format like this:

    [ [data], SW1, SW2 ]

I know that when you're issuing the APDU you can specify the size of the expected answer by using Le field but I'm wondering if there is any byte (or anything) within the data field that indicates its actual size.


For example, say that I want to read the master file:

First, I issue a SELECT FILE apdu:

    00 A4 00 00

which would return 61 1b for example, where 1b is number of bytes to read using GET RESPONSE. Then I send the GET RESPONSE apdu using Le for the expected size of the answer:

    00 C0 00 00 1B

And this returns [ [00, 01, 02, ...], 90, 00 ].

What I would like to know is: Is there a way of figuring out the size of the data field?

Upvotes: 0

Views: 745

Answers (2)

hsg
hsg

Reputation: 656

The straight answer is NO because the protocol for response(output) data is defined (T=0, in your example) as

Response Data (X) + Status Word (2 Bytes)

So, Total response length (-) 2 is the length of response data. I have always calculated the length of response data by this way.

Upvotes: 1

Paul Bastian
Paul Bastian

Reputation: 2647

The message exchange format you are referring to is called the T=0 protocol. This protocol is very old and not very rare now a days, almost every card is talking T=1 protocol, which returns the data field and status word immediately, without an additional APDU to request the data.

Answering your question in general, no, but indirectly and on the lower protocol level kind of, yes.

APDU messages are specified in ISO 7816-4, on a lower level (that is ISO7816-3 or ISO14443-4) these APDUs are transmitted as a chain of I-blocks, which contain a header byte that has a bit flag indicating that more blocks/frames are following. So you receive as long as more blocks are indicated until the last block is received and you concatenate all data without header and trailer bytes to form an APDU command/response that is handed over to the higher protocol layer (7816-4). So on the lower layer you know the length implicilty by the length of all received data, but it is never explicitly declared. So on the APDU layer, you will receive the data as a byte[] buffer(e.g. Java) or the function will return the length/write it to a target buffer(WinScard.dll), depending on what framework you will use.

Moreover, it is very common in the smartcard world to return ASN.1/TLV-encoded data, e.g. for example in files or cryptographic data, that includes the length behind a tag, e.g. the files begins with 0x30 0x10 which means a SEQUENCE with 16 bytes follows, so you know the file contains 18 bytes in total.

Upvotes: 1

Related Questions