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

Posted 2023-02-22

【中文标题】无论协议如何，Le 是不是可以作为案例 4 命令传递给 PCSC SCardTransmit 的数据的一部分？

【英文标题】：Can Le be part of the data passed to PCSC SCardTransmit for a Case 4 command regardless of protocol?无论协议如何，Le 是否可以作为案例 4 命令传递给 PCSC SCardTransmit 的数据的一部分？

【发布时间】：2021-09-17 15:01:29

【问题描述】：

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

情况4的命令APDU由头、L_C字段、数据字段和L_E字段组成。

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

L_C是01中的一个字节_H…FF_H直接编码整数N_C（数字数据字段中的字节数，因此忽略了 4 字节标头） L_E是01中的一个字节_H…FF_H直接编码整数N_E（数字未发生错误时卡响应的字节数，折扣状态字），或 00_H 表示 最大（或等效为 N_E= 256）。

在这种情况下 4S，L_E 是否可以成为传递给 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 年 8 月 8 日的 GemPcCCID 4.1.4.0 签署 2018 年 7 月 26 日，there）有关。使用 Microsoft 的默认 CCID WUDF 驱动程序，或者如果我将 cbSendLength 设置为少一（从而删除 L_E），问题就会消失。到目前为止，我还没有发现其他读取器/驱动程序配置触发 那个 问题，所以我倾向于说这是一个驱动程序问题（或者至少是该驱动程序和它的 PCSC 服务组合的问题应该使用）。

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

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

---

补充：spec of ScardTransmit 有：

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

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

【参考方案1】：

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

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

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

【讨论】：

我知道在协议T=0的4S情况下卡不应该接收Le。但问题是是否可以将其传递给 SCardTransmit。毕竟，我们在使用协议 T=1 时应该传递 Le。

T0 和 T1 协议的基本原理是不同的，尽管从 SCardTransmit 的角度来看它们非常相似。没有办法使用 T=0 逐卡接受 Le 字节。过不了就好了。

【参考方案2】：

如other answer 中所述，在 T=0 协议下，将带有 Le 的 Case 4 命令 APDU 传递给 SCardTransmit 是不安全的。该问题还询问记录在哪里。

目前Microsoft's spec 的SCardTansmit 和pscsclite spec 均未说明此类限制。然而，SCardTransmit 历来被开发为由PC/SC in Part 3, paragraph 4.3.2.1 指定的IFD_Transmit_to_ICC 的实现（具有不同的参数传递但类似的功能）（注意：可能加载缓慢）并指出：

SCARD_PROTOCOL_T0 通信的规定 CommandData 需要按照 ISO/IEC 7816-4 中的描述格式化为 APDU。支持以下情况：

案例 1：没有传入或传出数据字节的命令：CLAINSP1P2 案例 2：带有输出数据字节的命令：CLAINSP1P2Le 案例 3：带有传入数据字节的命令：CLAINSP1P2Lc[Data bytes]

具体说明：

仅支持 Lc 和 Le 的短格式，即一个字节长。 没有数据字节 « CLA INS P1 P2 » 的传入订单应作为 TPDU 通过 case 1 APDU 发送到卡。 无法使用案例 4 APDU。应用程序或服务提供商有责任在需要时生成“获取响应”。

因此，在 T=0 协议下，传递 SCardTransmit 除了 Case 1、Case 2S 或 Case 3S 命令 APDU 之外的任何内容都是不谨慎的。

如果我们通过一个案例 4S 命令 APDU（CLAINSP1P2Lc[Lc Data bytes]Le，Lc 在 [Lc@64 中有效）许多司机和读者都很好。根据我的经验，无论是在 Windows 下使用 Microsoft 的 Usbccid WUDF 驱动程序和许多其他供应商的驱动程序，还是使用 pcsclite 及其配套的 libccid，都会将完整的 C-APDU 传递给阅读器，它会过滤掉 C-TPDU 中的 Le 到卡，一切都很好。但是也有例外，包括 GemCCID 4.1.4 Windows 驱动程序，它不执行传输并返回错误。