时间戳

首页 > 解决方案 > 无论协议如何，Le 是否可以作为案例 4 命令传递给 PCSC SCardTransmit 的数据的一部分？

pcsc - 无论协议如何，Le 是否可以作为案例 4 命令传递给 PCSC SCardTransmit 的数据的一部分？

问题描述

ISO/IEC 7816-3:2006 (12.1.2) 定义了发送数据的智能卡命令的字节串，预计会产生一些超出状态字的信息：

情况 4 的命令 APDU 由标题、LC字段、数据字段和 L E字段组成。

ISO/IEC 7816-4:2020 (5.2) 类似。我限制在短情况下（4S），其中

在这种情况下 4S， LE 是否可以成为传递给 PCSC 的数据的一部分，而SCardTransmit不管协议如何？

换句话说，当将这样的命令传递给 PCSC 时SCardTransmit，我们可以设置cbSendLength为 N C +6 而不管协议吗？

我问是因为我有一个可重现的问题，即在命令中包含 L E（例如00 A4 09 00 02 20 03 42，cbSendLength = 8在卡实际返回状态字6A 82且没有数据的上下文中）会导致SCardTransmit失败。L E字节的值无关紧要。那是来自不同制造商和应用程序的 T=0 卡，不同型号的几个读卡器，但都具有相同的制造商推荐的 Windows 驱动程序（2016-08-08 的 GemPcCCID 4.1.4.0 签署于 2018-07-26，那里）。使用 Microsoft 的默认 CCID WUDF 驱动程序，或者如果我设置cbSendLength为少一个（因此删除 L E），问题就会消失。到目前为止，我还没有发现其他读取器/驱动程序配置会触发它问题，所以我倾向于说这是一个驱动程序问题（或者至少是该驱动程序和它应该使用的 PCSC 服务的组合问题）。

我想要一些规范来说明将 L E字节包含到 是否合法SCardTransmit，而且我更喜欢非 Windows 特定的东西。

我知道如果应用程序知道使用了协议 T=0 ，很容易从初始 省略 L E字节SCardTransmit，并且我看到当卡发送 61xx 状态字时如何处理L E 。然而，一些非接触式智能卡读卡器在真正使用 ISO/IEC 14443-4 协议时会伪装成 T=0，然后 L E字节在某些情况下很有用，因此我不想使用该选项。

另外：ScardTransmit的规格有：

对于 T=0，在没有数据发送到卡并且没有预期返回的数据的特殊情况下，这个长度（传递给 ScardTransmit 的数据）必须反映bP3成员没有被发送；长度应该是sizeof(CmdBytes) - sizeof(BYTE)（即4C-APDU的长度）。

因此，在T=0下，在情况1、2S、3S中，传递给ScardTransmit的是C-APDU，而情况1则与C-TPDU不同。我在问是否有关于命令的参考解决方案，特别是在 T=0 下的 4S 的情况下，在将其传递给 ScardTransmit 之前从 C-APDU 中剥离 L E（使其成为 C-TPDU），类似于上面在 T=0 下的情况 1（ScardTransmit、驱动程序或读取器将执行）下，不进行从 C-APDU 到 C-TPDU 的这种转换的处方。

标签： pcsc

解决方案

根据 ISO/IEC 7816-3:2006(E) 命令，T=0 协议由 CLA-INS-P1-P2-P3-Data 组成，即数据后面没有任何字段。

条款 12.2.5 案例 4S 与命令-响应对传输相关，T=0。它说：命令 APDU 通过切断 Le 字段映射到命令 TPDU。

因此，在情况 4S 中，命令末尾不允许有 Le 字节。

推荐阅读