什么APDU命令获取卡ID [英] What APDU command gets card ID
问题描述
什么APDU命令获取7字节的卡ID？
我使用T = CL（ISO7816）pritocol和ISO14443层。在检测卡上，我只能看到4字节的卡ID。
我搜索，也就是APDU命令获取卡ID。
例如：
0xFF，0xCA，0x00，0x00，0x00
： 6E 00 ，关于APDU回答的规格说明不支持类别
What APDU command gets 7 byte of card ID?
I use T=CL (ISO7816) pritocol with ISO14443 layer. On detect card I can see only 4 byte of card ID.
I searched, that is APDU command for gets card ID.
For example its:
0xFF, 0xCA, 0x00, 0x00, 0x00
but result of thouse command is: 6E 00, that on specifications of APDU answers tell that "Class not supported"
然后我发现它的APDU命令可以是：
0x00，0xCA，0x00,0x00,0x00
此命令返回 6A 88
其中 6A XX - 错误的参数）P1-P2和 88 - 找不到引用的数据
Then I find, that its APDU command may be as:
0x00, 0xCA, 0x00, 0x00, 0x00
this command return 6A 88
where 6A XX - "Wrong parameter(s) P1-P2" and 88 - "Referenced data not found"
您对此有何看法？
谢谢！
所有命令为： CLA，INS，P1，P2，LenData，Data
其他我的命令工作正常（如sellect aplet并使用它） ，问题只在获取卡片ID
p.s. All command as: CLA, INS, P1, P2, LenData, Data
Other my command work normaly (such as sellect aplet and work with it), problem only at getting card ID
推荐答案
前面给出的答案是错误的。这是因为我们不是在这里谈论ISO 7816命令，而是PC / SC API的内部命令。
The answer given before is wrong. This is because we are not talking about a ISO 7816 command here but a internal command of the PC/SC API.
APDU0xFF 0xCA 0x00 0x00 0x00事实正确，我有卡，我得到一个7字节的答案。请注意，这只适用于非接触式（RFID）卡，因为此UID是无线电协议的一部分。请注意，一些芯片将在每次上电后返回一个新的随机UID。例如我的护照芯片以及我的德国国民身份证和防止跟踪持卡人的对策。理论上，这样的随机UID应以0x08开始，但并不总是这样。
The APDU "0xFF 0xCA 0x00 0x00 0x00" is in fact correct and I have cards for which I get a 7 byte answer. Please note that this will only work with contactless (RFID) cards because this UID is part of the radio protocol. Please note further that some chips will return a new random UID after each power up. This is for example true for my passport chip as well as my german national identity card and a countermeasure to prevent tracking of card holders. In theory such random UIDs shall begin with 0x08 but this is not always the case.
由于UID是协议的内部值，所讨论的APDU没有发送到卡，但只是一个内部命令（PC / SC接口）从读卡器驱动程序获取UID。 CLA 0xFF通常不正常使用，因为它仅用于协议参数选择（PPS）的保留。
As the UID is a "internal" value of the protocol, the APDU in question is NOT sent to the card but is only a internal command (of the PC/SC Interface) to get the UID from the card reader driver. CLA 0xFF is generally not in normal use as it is only used for reserved for "Protocol Parameter Selection" (PPS). PC/SC abuses this CLA for internal commands.
此处的命令是PC / SC内部Get Data命令，在第3部分第3.2.2.1节中指定。 3的PC / SC规范。这里P1和P2有特殊的预定义，所以尝试不同的值没有意义。该标准仅定义了用于获得UID的P1 = 0，P2 = 0，对于来自ISO 14443 A卡的所有历史字节的所有历史字节，没有CRC，P1 = 1，P2 = 0。不支持其他值。
The command here is the PC/SC internal "Get Data" Command, specified in Part 3, Section 3.2.2.1.3 of the PC/SC specification. Here P1 and P2 have special predefined meanings, so there is no point in trying different values. The standard only defineds P1=0,P2=0 for getting the UID and P1=1,P2=0 for "all historical bytes from the ATS of a ISO 14443 A card without CRC". Other values are not supported.
有趣的是，答案0x6A 0x88没有在标准中定义。 0x6a 0x81意味着功能不支持，这将是没有UID（标准提到7816-10联系人卡）的卡的情况。另外两个定义的答案（0x62 0x82和0x6C 0xXX）定义了请求的答案长度和实际数据量之间的不匹配，这里不会出现，因为我们通过在请求的最后一个字节中指定0来请求任何长度数据。
Interestingly the answer 0x6A 0x88 is not defined in the standard. 0x6a 0x81 would mean "Function not supported" which would be the case which cards which don't have a UID (standard mentions 7816-10 contact card). The two other defined answers (0x62 0x82 and 0x6C 0xXX) define a mismatch between the requested answer length and the actual amount of data and won't occur here, because we simply request any length data by specifying 0 in the last byte of the request.
所以为什么它不工作的提交者我不知道。对我来说它工作，一些卡返回4字节，其他返回7字节。
So why it isn't working for the submitter I don't know. For me it works, some cards return 4 bytes, other return 7 bytes.
请参阅PC / SC标准，特别是第3部分，其中： http://www.pcscworkgroup.com/specifications/specdownload.php
See the PC/SC standard, part 3 in particular, here: http://www.pcscworkgroup.com/specifications/specdownload.php
这篇关于什么APDU命令获取卡ID的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
