什么APDU命令获得7个字符的卡ID？
我使用T = CL（ISO7816）pritocol和ISO14443层。在检测卡上，我只能看到4个字符的卡ID。
我搜索了，这是获取卡ID的APDU命令。
例如：
0xFF, 0xCA, 0x00, 0x00, 0x00
但是thouse命令的结果是：6E 00，关于APDU答案规范的结果告诉“不支持的类”
然后我发现它的APDU命令可能如下：
0x00, 0xCA, 0x00, 0x00, 0x00
此命令返回6A 88
其中6A XX - “错误的参数P1-P2”和88 - “未找到参考数据”
您对此有何看法？
谢谢！
P.S。所有命令为：CLA, INS, P1, P2, LenData, Data
其他我的命令工作正常（例如选择aplet并使用它），仅在获取卡ID时出现问题
答案 0 :(得分：16)
之前给出的答案是错误的。这是因为我们不是在谈论ISO 7816命令，而是PC / SC API的内部命令。
APDU“0xFF 0xCA 0x00 0x00 0x00”实际上是正确的，我有卡，我得到了7字节的答案。请注意，这仅适用于非接触式（RFID）卡，因为此UID是无线电协议的一部分。请注意，一些芯片将在每次加电后返回一个新的随机UID。例如，我的护照芯片以及我的德国国民身份证以及防止持卡人跟踪的对策都是如此。从理论上讲，这种随机UID应以0x08开头，但情况并非总是如此。
由于UID是协议的“内部”值，因此有问题的APDU不会发送到卡，而只是（PC / SC接口的）内部命令从读卡器驱动程序获取UID。 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用于“来自ISO 14443 A卡的ATS的所有历史字节，无CRC”。其他值不受支持。
有趣的是，标准中没有定义答案0x6A 0x88。 0x6a 0x81意味着“功能不受支持”，这是没有UID的卡（标准提到7816-10联系卡）。另外两个定义的答案（0x62 0x82和0x6C 0xXX）定义了请求的答案长度和实际数据量之间的不匹配，这里不会发生，因为我们只是通过在请求的最后一个字节中指定0来请求任何长度数据
那么为什么它不适用于我不知道的提交者。对我来说它有效，有些卡返回4个字节，其他返回7个字节。
请参阅PC / SC标准，特别是第3部分：http://www.pcscworkgroup.com/specifications/specdownload.php
答案 1 :(得分：1)
0xCA是GET DATA命令。您必须在P1-P2中提供TLV标签。
ISO 7816第6部分“用于交换的行业间数据元素”具有这些标记的列表，但它们都没有明确对应于“卡ID”。我建议您尝试P2的所有值，P1等于0x00,0x5F或0x7F，以找出您的卡支持哪些数据元素。
答案 2 :(得分：0)
我认为您的第二个命令是正确的，但该卡尚未使用应用程序ID进行编程。
对于6A88，BasicCard手册说：“如果在BasicCard中没有配置应用程序ID，内置命令GET APPLICATION ID将返回此错误代码。”
答案 3 :(得分：0)
这是一个经常讨论的问题。
0xFF，0xCA，0x00、0x00、0x00是获取卡uid的正确pcsc命令。
如果收到6E00响应，则说明驱动程序存在错误。更新驱动程序或尝试使用其他阅读器。
答案 4 :(得分：0)
我尝试过：
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 =密码已被阻止，解锁尝试计数器为3
9F04 =未成功验证PIN，PIN被阻止，“取消阻止尝试计数器”为3