What APDU command gets card ID

Question

Which APDU command gets 7 bytes of the card ID? I use T=CL (ISO7816) protocol with ISO14443 layer. On detect card I can see only 4 bytes of the card ID. I found that this should be the APDU command to get a card ID. For example its:
0xFF, 0xCA, 0x00, 0x00, 0x00
but result of this command is: 6E 00, that on specifications of APDU answers tell that "Class not supported"

Then I found 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"

What you think about it?

Thank you!

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

Charades

Answer 1

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.

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.

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.

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.

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.

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.

See the PC/SC standard, part 3 in particular, here: http://www.pcscworkgroup.com/specifications/specdownload.php

Vanward

This document gives some more insight into the UID of RFID cards, including the random UIDs and also how to determine other non-unique UIDs: nxp.com/documents/application_note/AN10927.pdf – Vanward

Answer 2

0xCA is the GET DATA command. You must supply a TLV Tag in P1-P2.

ISO 7816 part 6 "Interindustry data elements for interchange" has a list of these tags, but none of them corresponds unambiguously to "card ID". I suggest that you try all values of P2, with P1 equal to 0x00, 0x5F, or 0x7F, to find out which data elements are supported by your card.

Cygnet

The command {0x00, 0xCA, 0x00, 0x5F, 0x00} or {0x00, 0xCA, 0x00, 0x7F, 0x00} returned error 6A 88 – Charades

Yes, of course. You must try all values of P2, from 0x00 to 0xFF, together with the three values 0x00, 0x5F, and 0x7F for P1. That's 768 combinations in total. – Cygnet

Answer 3

I think your second command is correct, but the card has not been programmed with an application Id.

For 6A88 the BasicCard manual says: "The built-in command GET APPLICATION ID returns this error code if no application ID was configured in the BasicCard".

Hindbrain

Answer 4

This is a very often discussed problem.

0xFF, 0xCA, 0x00, 0x00, 0x00 is the correct pcsc command to get th card uid.

If you get a 6E00 response, then your driver has a bug. Update the driver or try another reader.

Pereira

Answer 5

I tried :

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

I got SW1=(byte)0x9F SW2=(byte)0xXX 9FXX = "Command successfully executed; ‘xx’ bytes of data are available and can be

requested using GET RESPONSE."

Except 9F00 and 9F04 which means

9F00=PIN blocked and Unblock Try Counter is 3

9F04=PIN not succesfully verified, PIN blocked and Unblock Try Counter is 3

Railhead