CODEWITHSUNDEEP
smartcardjavacardapdu
vojta
vojta

Reputation: 5661

ISO7816 - Odd INS codes?

I found these mysterious lines in ISO 7816, (http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx#chap5_4):

5.4.2 Instruction byte

The instruction byte INS of a command shall be coded to allow transmission with any of the protocols defined in part 3 of ISO/IEC 7816. Table 10 shows the INS codes that are consequently invalid.

Table 10 - Invalid INS codes

b8 b7 b6 b5 b4 b3 b2 b1   Meaning
x  x  x  x  x  x  x  1    Odd values
0  1  1  0  x  x  x  x    '6X'
1  0  0  1  x  x  x  x    '9X'

I understand that I cannot use 6X or 9X as INS byte (because of T=0 compatibility?).

However, I have no idea why I cannot use odd values... Should this work as a kind of an error detection mechanism (although I see no reason, because it just means we should use only 7 most significant bits of INS byte, so the least significant bit carries no information at all)?

Could it really cause any troubles in real world deployment? Have you ever met any cards/readers/tools which were not working correctly with odd INS bytes?

Upvotes: 1

Views: 1504

Answers (2)

vojta
vojta

Reputation: 5661

I am going to answer my own question after some research. My problem was an old ISO7816-3 standard as Guidot mentioned in his comment. According to current ISO7816-3 and ISO7816-4 odd INS codes are valid. The only invalid INS values according to current ISO are 6X and 9X.

The reason why some INS codes are invalid is the old T=0 protocol (used by a lot of todays Gemalto SIM cards). So if your applet is not supposed to work on cards with T=0 protocol, you can use whatever INS code you like.

Sending one data unit in T=0 protocol works this way:

  1. Terminal sends the header (CLA INS P1 P2 P3)
  2. Card periodically sends so called "procedure bytes" with following meaning for the terminal device:

60 ... wait for the next procedure byte

6X or 9X ... finish, this procedure byte is the first byte of status word (SW1)

INS ... send the next byte of the data part

INS xor 0xFF ... send all the remaining bytes of the data part

INS+1 ... send the next byte of the data part and turn on the additional voltage (VPP)

(INS+1) xor 0xFF ... send all the remaining bytes of the data part and turn on the additional voltage (VPP)

This is why INS codes must not have been odd according to the old standard (terminal device would not be able to decide what the last procedure byte means). However, VPP has not been used since 1990, that is why bold procedure bytes are not used anymore and they are not mentioned it the last version of the ISO standard.

The conclusion is you can use only 6XXX or 9XXX status words and you cannot use 6X or 9X INS codes when working with "old" T=0 protocol. Odd INS codes are OK, although they were not OK in the past. If you use T=1 protocol only, you do not have to take care at all.

Upvotes: 5

guidot
guidot

Reputation: 5333

VPP is a thing of the past, the corresponding contact C6 was released since the 2006 version of 7816-3.

Odd instruction codes are typically handled differently from the even ones by the card, they are no simple aliases for these, but equally valid (not all defined even instruction codes already have a standardized odd instruction counterpart, however).

Partly this is caused by 7816-4 (2005 version) requiring a different handling of secure messaging, and partially the pressure towards odd instruction codes came from additional requirements, e. g. increased addressing capabilities. So the even instruction code of read binary can handle only offsets up to 15 bits. If this is insufficient, the odd instruction has to be used, where the offset has to be coded in an offset DO.

I would not expect difficulties from reader hardware or driver software - both should pass odd instruction codes equally well.

Upvotes: 0

Related Questions