T=1 smart card protocol

2
votes

I have question related to T= 1 Smart Card communication protocol. Let's say terminal sends I-block with expected Ne data to be returned from the card (so called case 2S) and card has less data to send. Does it mean that terminal should wait until timeout and then inspect whatever received for last two bytes (which should be SW1 and SW2 statuses) ? Or is there some other scenario related to that issue ? With T= 0 protocol that issue is addressed by procedure byte, however in T= 1 I only see the above way.

Thanks

1
smartcard
I suppose that card should put in prologue's LEN field, what is the amount of data it returns, but question is if that LEN field is received correctly (check bytes does come later during reply). However not so sure. – Djole
While I'm no protocol expert, this seems to be a misunderstanding. Le indicates only the maximum number of bytes accepted by the terminal. It may well be less. (This is different from the LEN field of the protocol blocks, which of course have to match exactly, and the reponse APDU is completely decoupled from the command you are sending.) That LRC byte follows later is irrelevant, since we are talking about a block oriented protocol. – guidot
What probably misled me in ISO7816-3 was: "Ne denotes the maximum number of bytes expected in the response data field". To me it looked like as something what is expected but could be more. No matter, question is related more to possibility of receiving corrupted LEN field, which I intend to use as indicator of how many bytes are yet to come. So if it (LEN) is corrupted and say greater than the amount of bytes coming, is it my only option to catch the timeout ? Of wrong LEN I could only learn from check byte(s), which come later, but I may not locate it in message (having bad LEN). – Djole
In case of actual data exceeding LEN the discrepancy can be immediately detected. If less data are provided, you have to wait for timeout of Character Waiting Time. – guidot

1 Answers

1
votes

guidot maybe claims that he's not an expert, but I would not believe him.

The Ne value (encoded using Le) indeed only indicates a maximum number of bytes to be returned. You might just have a buffer size of a particular maximum or have overhead (secure messaging) that prohibits using higher values. You may however have APDU commands where Ne is used to indicate the amount of bytes that should be sent if available, such as READ BINARY.

The size of the (response) APDU is determined by the underlying datalink layer (the chaining bit and LEN bytes used in the blocks within the frames). T=1 is not a byte oriented protocol such as T=0. For T=1 and indeed T=CL the datalink layer determines the size of the command and response APDU, not the application layer with the Nc and Ne bytes.