APDU team gets map ID

Question

Which APDU command receives 7 bytes of card ID? I am using T = CL (ISO7816) flashing with an ISO14443 level. On the detection card, I can only see 4 bytes of the card identifier. I searched, this is the APDU command to get the card id. For example, its:
0xFF, 0xCA, 0x00, 0x00, 0x00
but the result of the thouse command is: 6E 00 , which, according to the specifications of the APDU responses, says "The class is not supported"

Then I find that his APDU command might be like this:
0x00, 0xCA, 0x00, 0x00, 0x00
this command returns 6A 88
where 6A XX - "Invalid parameter P1-P2" and 88 - "Related data not found"

What do you think about this?

Thanks!

ps All commands: CLA, INS, P1, P2, LenData, Data
My other team works fine (for example, sellect aplet and work with it), the problem is only when getting the card ID

Answer 1

The answer above is incorrect. This is because here we are not talking about the ISO 7816 team, but about the internal PC / SC API team.

The APDU "0xFF 0xCA 0x00 0x00 0x00" is actually correct, and I have cards for which I get a 7-byte response. Please note that this will only work with contactless (RFID) cards, because this UID is part of the radio protocol. Note that some chips return a new random UID after each power-up. This, for example, is true for my passport chip, as well as my German national ID and countermeasures, to prevent tracking of cardholders. Theoretically, such random UIDs start with 0x08, but this is not always the case.

Since the UID is the "internal" value of the protocol, the APDU in question is NOT sent to the card, but is only an internal command (PC / SC interface) to get the UID from the card reader driver. CLA 0xFF is usually not used in normal mode, since it is only used for reserved for "Protocol Parameter Selection" (PPS). PC / SC violates this CLA for internal commands.

This command is an internal PC / SC Get Data command specified in Part 3 of Section 3.2.2.1.3 of the PC / SC Specification. Here P1 and P2 have special predefined values, so it makes no sense to try to use different values. The standard defines only P1 = 0, P2 = 0 to get the UID and P1 = 1, P2 = 0 for "all historical bytes from the ATS card ISO 14443 A without CRC". Other values ​​are not supported.

Interestingly, the answer 0x6A 0x88 is not defined in the standard. 0x6a 0x81 means "Function is not supported", which would be the case for cards that do not have a UID (the standard mentions contact card 7816-10). Two other specific answers (0x62 0x82 and 0x6C 0xXX) determine the discrepancy between the requested response length and the actual amount of data and will not arise here, because we simply request the length data, indicating 0 in the last byte of the request.

So why doesn’t it work for a submitter whom I don’t know. This works for me, some cards return 4 bytes, others return 7 bytes.

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

Answer 2

0xCA - GET DATA command. You must specify the TLV tag in P1-P2.

ISO 7816, part 6, “Cross-industry data elements for exchange”, has a list of these tags, but none of them correspond unambiguously to “card identifier”. I suggest you try all the P2 values ​​with P1 equal to 0x00, 0x5F or 0x7F to find out which data items are supported by your card.

Answer 3

I think your second command is correct, but the card was not programmed using the application identifier.

In 6A88, the BasicCard manual says: "The built-in GET APPLICATION ID command returns this error code if the application ID has not been configured in BasicCard."

Answer 4

This is a very often discussed issue.

0xFF, 0xCA, 0x00, 0x00, 0x00 - the correct pcsc command to get the card ID.

If you get a 6E00 answer, then there is an error in your driver. Update the driver or try a different reader.

Answer 5

I have tried:

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

I got SW1 = (byte) 0x9F SW2 = (byte) 0xXX 9FXX = "The command completed successfully; ' xx data bytes are available and can be

requested using GET RESPONSE. "

Except 9F00 and 9F04, which means

9F00 = PIN is locked and the counter of attempts to unlock is 3

9F04 = The PIN code was not verified successfully, the PIN code is blocked and the counter of attempts to unlock is 3