The two other defined answers (0圆2 0x82 and 0圆C 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. 0圆a 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). Interestingly the answer 0圆A 0x88 is not defined in the standard. 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". Here P1 and P2 have special predefined meanings, so there is no point in trying different values. 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. PC/SC abuses this CLA for internal commands. CLA 0xFF is generally not in normal use as it is only used for reserved for "Protocol Parameter Selection" (PPS). In theory such random UIDs shall begin with 0x08 but this is not always the case.Īs 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.
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. Please note further that some chips will return a new random UID after each power up.
Please note that this will only work with contactless (RFID) cards because this UID is part of the radio protocol. The APDU "0xFF 0xCA 0x00 0x00 0x00" is in fact correct and I have cards for which I get a 7 byte answer. This is because we are not talking about a ISO 7816 command here but a internal command of the PC/SC API.
0 kommentar(er)
