Smartcard 什么APDU命令获取卡ID

哪个APDU命令获取7字节的卡ID？ 我使用带有ISO14443层的T=CL（ISO7816）协议。在检测卡上，我只能看到卡ID的4个字节。 我发现这应该是APDU命令来获取卡ID。 例如它：

0xFF、0xCA、0x00、0x00、0x00

但这个命令的结果是：

6e00

，在APDU的规范中，答案告诉我们“类不受支持”

然后我发现它的APDU命令可能是：

0x00，0xCA，0x00，0x00，0x00
此命令返回
6A88


其中
6A XX
-“错误参数P1-P2”和
88
-“未找到参考数据”

你觉得怎么样

谢谢大家!

所有命令均为：
CLA、INS、P1、P2、LenData、Data


其他my命令工作正常（例如sellect aplet并使用它），只有在获取卡ID时出现的问题是GET DATA命令。必须在P1-P2中提供TLV标签

ISO 7816第6部分“用于交换的行业间数据元素”列出了这些标记，但没有一个标记明确对应于“卡ID”。我建议您尝试P2的所有值，P1等于0x00、0x5F或0x7F，以确定您的卡支持哪些数据元素。
前面给出的答案是错误的。这是因为我们这里讨论的不是ISO 7816命令，而是PC/SC API的内部命令

APDU“0xFF 0xCA 0x00 0x00 0x00 0x00”事实上是正确的，我有一个7字节答案的卡。请注意，这仅适用于非接触式（RFID）卡，因为此UID是无线电协议的一部分。请进一步注意，某些芯片在每次通电后都会返回一个新的随机UID。例如，我的护照芯片和我的德国国民身份证也是如此，这是一种防止跟踪持卡人的对策。理论上，此类随机UID应以0x08开头，但情况并非总是如此

由于UID是协议的“内部”值，因此相关APDU不会发送到卡，而只是从读卡器驱动程序获取UID的内部命令（PC/SC接口）。CLA 0xFF通常不在正常使用中，因为它仅用于“协议参数选择”（PPS）的保留。PC/SC滥用此CLA执行内部命令

此处的命令是PC/SC内部“获取数据”命令，在PC/SC规范第3部分第3.2.2.1.3节中规定。这里P1和P2具有特殊的预定义含义，因此尝试不同的值没有意义。该标准仅定义P1=0，P2=0用于获取UID，P1=1，P2=0用于“不带CRC的ISO 14443 a卡ATS的所有历史字节”。不支持其他值

有趣的是，标准中没有定义答案0x6A 0x88。0x6a 0x81表示“功能不受支持”，这是指没有UID的卡（标准中提到7816-10联系人卡）。另外两个已定义的答案（0x62 0x82和0x6C 0xXX）定义了请求的答案长度与实际数据量之间的不匹配，并且不会在此处出现，因为我们只是通过在请求的最后一个字节中指定0来请求任何长度的数据

所以我不知道为什么它对提交者不起作用。对我来说，它可以工作，一些卡返回4字节，其他卡返回7字节

请参阅PC/SC标准，特别是第3部分，此处：
我认为您的第二个命令是正确的，但该卡尚未使用应用程序Id进行编程

对于6A88，BasicCard手册中说：“如果BasicCard中未配置应用程序ID，则内置命令GET APPLICATION ID返回此错误代码。”
这是一个经常讨论的问题

0xFF、0xCA、0x00、0x00、0x00是获取卡uid的正确pcsc命令

如果您得到一个6E00响应，那么您的驱动程序有一个bug。更新驱动程序或尝试其他读取器。
我尝试了：

byte data[] = new byte[]{};
CommandApdu((byte)0xA0, (byte)0xC0, (byte)0x00, (byte)0x00, data)

我得到了SW1=（字节）0x9F SW2=（字节）0xXX
9FXX=“命令已成功执行；'xx'字节的数据可用，可以

已使用GET RESPONSE请求。“

除了9F00和9F04，这意味着

9F00=PIN阻塞和解锁尝试计数器为3

9F04=PIN未成功验证，PIN阻塞和取消阻塞尝试计数器为3
命令{0x00，0xCA，0x00，0x5F，0x00}或{0x00，0xCA，0x00，0x7F，0x00}当然返回了错误。您必须尝试P2的所有值，从0x00到0xFF，以及P1的三个值0x00、0x5F和0x7F。总共是768种组合。本文档提供了对RFID卡UID的更多了解，包括随机UID以及如何确定其他非唯一UID：