ISO7816 - 奇数 INS 代码？

Question

我在 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'

我知道我不能使用 6X 或 9X 作为 INS 字节（因为 T=0 兼容性？）。

但是，我不知道为什么我不能使用奇数...这是否可以用作一种错误检测机制（尽管我认为没有理由，因为它只是意味着我们应该只使用 7 个最高有效位INS 字节，所以最低有效位根本不携带任何信息）？

它真的会在实际部署中造成任何麻烦吗？您是否遇到过任何 cards/readers/tools 不能正确处理奇数 INS 字节的情况？

Answer 1

VPP已成为过去，对应的触点C6从7816-3的2006版开始发布

卡对奇数指令代码的处理通常与偶数指令代码不同，它们不是它们的简单别名，但同样有效（但是，并非所有定义的偶数指令代码都已经具有标准化的奇数指令对应项）。

部分原因是 7816-4（2005 版）要求对安全消息进行不同的处理，部分原因是对奇怪指令代码的压力来自额外的要求，例如。 G。增加寻址能力。因此，读取二进制的偶数指令代码只能处理最多 15 位的偏移量。如果这还不够，则必须使用奇数指令，其中偏移量必须在偏移量 DO 中编码。

我预计 reader 硬件或驱动程序软件不会遇到困难 - 两者都应该同样顺利地通过奇数指令代码。

Answer 2

经过一些研究，我将回答我自己的问题。正如 Guidot 在他的评论中提到的那样，我的问题是一个旧的 ISO7816-3 标准。根据当前的 ISO7816-3 和 ISO7816-4，奇 INS 代码有效。根据当前 ISO，唯一无效的 INS 值是 6X 和 9X。

一些INS码无效的原因是旧的T=0协议（现在很多金雅拓SIM卡都在使用）。所以如果你的小程序不应该在 T=0 协议的卡上工作，你可以使用你喜欢的任何 INS 代码。

在 T=0 协议中发送一个数据单元是这样的：

终端发送 header (CLA INS P1 P2 P3)
卡定期发送所谓的"procedure bytes"，对终端设备意义如下：

60 ...等待下一个程序字节

6X or 9X ... 完成，这个程序字节是状态字（SW1）的第一个字节

INS ...发送数据部分的下一个字节

INS xor 0xFF ...发送数据部分的所有剩余字节

INS+1 ...发送数据部分的下一个字节并开启附加电压（VPP）

(INS+1) xor 0xFF ...发送数据部分的所有剩余字节并开启附加电压（VPP）

这就是为什么按照旧标准，INS 代码不能是奇数的原因（终端设备将无法确定最后一个程序字节的含义）。但是，自 1990 年以来就没有使用过 VPP，这就是为什么不再使用 bold 过程字节并且在 ISO 标准的最新版本中也没有提到它们。

结论是您只能使用 6XXX 或 9XXX 状态字，并且在使用 "old" T=0 协议时不能使用 6X 或 9X INS 代码。奇数 INS 码是可以的，虽然以前不可以。如果你只使用T=1协议，你根本不用管。

ISO7816 - 奇数 INS 代码？

ISO7816 - Odd INS codes?

smartcard

javacard

apdu