智能卡如何区分 Case 2 和 Case 3 APDU headers 在 T0 中形成彼此？

Question

我正在尝试了解

T0

协议在智能卡中的工作方式。基于相应的标准（ISO/IEC 7816/3），该协议中的通信由读卡器向卡发送一个5字节的命令头（CLA-INS-P1-P2-P3）发起；在这个标头之后，读卡器将等待来自卡的程序字节。 prodecure byte 可以是以下值之一：

1. 60

   => 为NULL(!)，敬请期待

   procedure byte

2. 6X

   (!60) or

   9X

   => 值为SW1，读者需等待SW2

3. INS

   或

   INS^FF

   => 这是一个 ACK。读者应发送剩余的字节

让我们假设读者发送

AA BB CC DD EE

到卡。问题是卡如何确定接收到的标头中的 EE 值是针对 case 2 (Le)、3(Lc) 还是 4 (Lc) APDU 命令？

而且我也不明白为什么使用

6X

和

9X

作为 INS 值是无效的。实际上，阻止开发人员对 SW1 使用

60

是有意义的（因为那样读者无法区分 SW1 和 NULL 程序字节），但阻止他对 INS 值使用

6X

和

9X

是没有意义的.有什么线索吗？

我已经检查了整个文档以找出有关此问题的任何信息，但是我阅读的内容越多，我就越困惑。 APDU 和 TPDU 之间的关系也无法区分。

Answer 1

正如您已经指出的那样，T=0 协议在分离层方面做得很糟糕。你问的问题表明，这不仅是数据链路层和传输层之间的情况，也是传输层和应用层之间的情况。

简单的事实是，当查看标头的 4 个字节时，卡知道正在发送哪个命令。它只是知道如何通过查看其他值来解释 P3。这也是为什么您找不到任何根据 P3 或任何 C_DATA（命令数据）中的信息切换大小写的命令的原因。

在Java Card中可以看到

setIncomingAndReceive

的备注如下：

• 在 T=0 ( Case 3&4 ) 协议中，P3 参数假定为 Lc.

所以传输缓冲区最初只包含 5 字节的标头，然后您应该只在检查标头后检索数据。当然，由于发生了一些缓冲，卡可能已经接收到其他数据 - 特别是对于 T=1 和 T=CL，但你绝对不应该提前假设这样的事情。

请注意，安全消息传递（通常是情况 4，因为您还想保护标头和状态字）是使用第一个 CLA 字节检测到的，因此仅查看 INS 是不够的。