Do smartcards return sw=9000 when T=0, Lc>0, Le>0?

Question

Perusing ISO/IEC 7816-3:2006, section 12.2.5 specifies what happens when the reader sends a command APDU with Lc>0, Le>0 for the T=0 transmission protocol (byte stream). The initial command TPDU has no Le field, and if the card responds successfully, the application should send 0xC0 GET RESPONSE commands until Le bytes are received.

Questions: If the smart card expects to return data, is it actually valid for the card to return 0x9000 in response to the initial T=0 command (before any GET RESPONSE commands), as 7816-3 specifies? Is it valid for an application to issue a GET RESPONSE command after a 0x9000 response? In contrast, from reading the usage of doTransmit in javax.smartcardio and sc_transmit in OpenSC, it appears that these applications only try to GET RESPONSE after a sw=0x61xx response, never after a sw=0x9000 response.

Answer 1

In ISO 7816 the ISO "case" of each command should be known in advance. In other words, the commands have either:

1. no command data & no response data
2. no command data, but response data
3. command data but no response data
4. command data and response data

In general, commands do not send response data if a status word indicating an error occurs, even if the ISO case states that response data is expected.

---

Now in table 14 it is stated for SW1 SW2 9000:

Process completed normally. In cases 1, 2 and 3, no further action. In case 4, after receiving command data bytes, the card shall be ready to receive at least one GET RESPONSE command for transferring at most Ne response data bytes.

So only for ISO case 4, where you send command data and expect response data, you should send a GET RESPONSE after 9000. If however you are using an ISO case 2 and you receive a 9000 then you should not send a GET RESPONSE.

---

It seems to me that as long as you specify an Ne value for one of the ISO case 4 CommandAPDU (i.e. one that includes command data as well) that javax.smartcardio should issue a GET RESPONSE APDU upon receving a 9000 SW1/SW2. This means that either the documentation is incomplete or that the implementation is incorrect.

Answer 2

As I read 7816-3, Case 4S.2 a card could respond with 90 00, if exactly C(N) bytes are available. Since C(N) was cut off during transformation of APDU to TPDU for a case 4 command, however, and so is unknown to the card, the only sure choice for the card is to return 61xx.

For a case 2 command 9000 seems a plausible answer [to be followed by a GET REPONSE C(N)], even if this case is not listed separately in 7816-3.