I am using an ACR122U NFC reader/writer and a MIFARE Classic 1K card. To load authentication keys for the MIFARE card, I use the following APDU command:
FF 82 20 00 06 FF FF FF FF FF FF
The reader responds with 90 00 (indicating success). However, on another PC I have the same reader/writer and the same tag but I receive the response code 63 00, which means that the operation failed.
When I read the ACR122U documentation it states the command as
FF 82 00 00 06 <KEY>
This byte is named key structure and its value is 00 in the documentation. Can this byte be the source of this problem?
Can anyone help me on this and explain the value of the key structure byte?
I'm rather surprised that you found one ACR122U that supports key structure (P1) set to 0x20. The API manual of the reader (see section 5.1 Load Authentication Keys) clearly indicates that values other than 0x00 are reserved (i.e. must not be used). This means that the ACR122U only supports card keys (i.e. authentication keys for cards) in volatile memory (i.e. keys are cleared from memory when the reader is unplugged).
You can find the definition of the key structure (P1) byte in the PC/SC specification (in Part 3. Requirements for PC-Connected Interface Devices):
Bit 7: This bit indicates if the key transmitted in this command is a card key ('0') or a reader key ('1'). Reader keys are keys used to encrypt card keys during transmission in the LOAD KEYS command (see bit 6).
Bit 6: The key transmitted in this command is transmitted in plain text ('0') or encrypted ('1') using a reader key (see bits 3..0).
Bit 5: This bit indicates if the transmitted key should be stored in volatile ('0') or non-volatile ('1') memory.
Bit 4: Reserved and always set to '0'.
Bit 3..0: The reader key number used for encrypteion of the transmitted key if bit 6 is set.
Load Authentication Keys
find the attached picture
load key Image
Key Structure: 00 key loaded into the reader volatile memory
Key Number: 00~01 key location on the reader
Key: the key value loaded into the reader e.g {FF FF FF FF FF FF}
the response : 90 00 the operation completed successfully
: 63 00 the operation failed
Related
I was modifying a piece of PC software I wrote to read multiple NDEF records from an NFC tag. However, one of the tags I have contains a record with what seems to be a mangled NDEF header. It's the last record of 6, the other 5 coming in as expected. I've listed it below. For simplicity, all values are listed in hexidecimal and the payload has been truncated.
Record #6
Header: 42
Type Length: 03
Random Bytes: 00 00 00
Payload Length: 2C (44)
Rec. Type: 6E 2F 70 (n/p)
Payload: **
As you can see, 3 random zero bytes are shoved between what should be the Type Length and Payload Length. I have double checked the Length Field in the TLV and found that it accounts for these 3 bytes. I'm not getting any data truncated off of the end of the TLV due to these added bytes.
I decided to do a sanity check with NXP's TagInfo app to make sure I wasn't just reading the data incorrectly. Checking the data dump from a full scan, I saw that the data does in fact match. I've listed the memory scan below. Only the relevant data points are listed and the payload is, again, truncated.
Memory Dump
addr data
...
[30] -- -- 42 03 |--B.|
[31] 00 00 00 2C |...,|
[32] 6E 2F 70 ** |n/p*|
[33] ** ** ** ** |****|
...
[3D] ** ** ** FE |***.|
...
We thought that maybe this was an issue with padding given that, in this case, the Terminator TLV appears at the end of page 0x3D. However, due to the nature of previous records, this is not always the case. Sometimes, the Terminator TLV shows up in the middle of a page.
However, the strange thing is that, in the same TagInfo app on the NDEF page, it reports the NDEF message as follows.
NDEF Message
...
[A8] 52 03 2C 6E 2F 70 ** ** |R.,n/p**|
[B0] ** ** ** ** ** ** ** ** |********|
...
[D8] ** ** |** |
...
Somehow, the software has not only removed the 3 extra bytes, but has correctly set the SR bit in the NDEF header. I have double checked this with another NFC app on Android and have confirmed that the other app is able to read the NDEF Message this way as well.
My question is, is there a reason or logic behind how the app is able to correct not only the the added bytes, but also the NDEF Header? I'm not sure if this is Android doing the correction or something else deeper in the NDEF message structure. Either way, I'm looking at the right way to make the correction while not effecting how I read the other 5 records held within this tag.
Those bytes are also part of the payload length
If the record does not have the SR (short record) bit set, then the payload length is 4 bytes long rather than one byte.
https://learn.adafruit.com/adafruit-pn532-rfid-nfc/ndef#payload-length-9-9
The first byte is 0x42, which in binary is 0100 0010. If we separate that out, we can see that the record has the ME (or 'Message End') bit set, as well as a TNF ('Type Name Format') of 0x02 - 'MIME Media Record'. The SR bit is bit 4, which is zero in this case.
That's also why they disappear in the version corrected by the TagInfo app - it has set the SR (which is why the header jumps to 0x52) and removed the unnecessary bytes.
I've got a contactless chip card (not bank or SIM) which I can interact by NFC channel (ISO14443, ISO 7816 Part 4).
All I want to get from this card is getting of UID of the card, which can help me to differ one card from others. As I understand this is PAN value which I can get under the tag '5A'.
Firstly, I can send this command to the card
00:a4:04:00:0e:32:50:41:59:2e:53:59:53:2e:44:44:46:30:31:00
and get positive answer (SW:9000) with the AID value.
So, I have AID and I can send such command
00:a4:04:00:LеnAID:<AID>:00
to open file for reading TLV-based info under different Tag, am I right?
But when I send ('5A' - tag for PAN)
00:CA:00:5A:00
I have bad response -> 6E:00
So,
1)Should I change Class value (CLA = 00 for right now)? And for what value?
2)Maybe I have to change INS value for READ RECORD (B0 or B2 or something else) because "The kernel uses the value of the AFL (i.e. tag ‘94’) to issue one or more READ RECORD commands retrieve the Application data elements", in my case tag '5A' for PAN.
If so, what the complete workflow should be for getting PAN?
UPD.
When I sent
ff:ca:00:00:00
I receive
6e:00
For unknown for me reason I couldn't get positive answer on command
FF:CA:00:00:00
I got answer 6E:00
But I found another way how to get card info. I have to execute not one but a sequence of commands:
1) Firstly I have to find out the AID of the applet. If you know AID you can skip this step (2PAY.SYS.DDF in my case)
00:a4:04:00:0e:32:50:41:59:2e:53:59:53:2e:44:44:46:30:31:00
2) Then SELECT APPLICATION
00 A4 04 00 AID-Lenth AID
3) After that we GET PROCESSING OPTIONS
80 A8 00 00 02 83 00 00
4) And READ RECORD
00 B2 01 14 00
For decoding TLV-response I use this utility - https://www.emvlab.org/tlvutils
In response I got not only 5A tag but also others and for right now I have to parse the whole R-APDU for fetching particular tag value.
Is there any java-libs for parsing TLV-response?
I'm trying to write an application that will interact with smart cards using an ACS ACR122U card terminal. According to all that I can find the API uses a combination of standard APDU commands and psuedo-APDUs to interact with the terminal, however psuedo-APDUs don't seem to work as claimed.
The API Reference (provided on the ACS site) indicates that APDUs of the form "FF XX XX XX ..." will be interpreted by the terminal (rather than sent to the card) but I always get a response status of "6E XX" (which I interpret as me sending an invalid class ID).
I've tried sending commands to flash the LEDs on the terminal using "FF 00 40 0F 04 00 00 00 00" and also tried to get some unique identifier from the card using "FF CA 01 00".
I can't find anything useful within the ISO 7816-4 document (the standard for smart cards) and the API reference provided by ACS. Also, ACS are not very forthcoming with information.
Does anyone have any ideas as to what I may be doing wrong or where I might look for additional information?
I can get an ATR - Answer To Reset from the terminal when a card is connected. I'm developing for interaction with Mifare 1K cards and would like to read from them and interact with the LEDs and buzzer on the terminal.
You can retrieve the API documentation here. This is ACS' proprietary APDUs so don't refer to standard ISO-7816 specification. Refer to section 6 for pseudo-APDU requirements.
To simulate LED, refer to section 6.2 for details and appendix E for example. You may try changing your APDU as follow: FF 00 40 FF 04 0A 0A 03 03. Please note that I set the LED control and also put non-zero values for LED duration.
For the second APDU, refer to section 4. Please note that you are missing P3/Le in your APDU (shall be FF CA 01 00 00) and you need the card reader connected with PICC.
i have mifare classic 4k and ACR1281U reader. I can authenticate/read/load succesfully.I have search the sites how to read the NFC tags but I am missing some; here are my questions
how to read and convert the data from MIfare blocks to human readable form
how to change the default auth key.
EDIT
Ok I just found out something strange. I tried to authenticate the random sector trailor block with the
key A
FF FF FF FF FF FF
then i tried to read that trailor block i found this
00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF 90 00
what i am confused is acccording to documentation, in the sector trailer
the key A comes first then access bits and then key b then response status
now what i get is
keyb? | access bits | key A | response status
Note : i tried to authenticated with Key A which is FFFFFFFFFFFF and successfully authenticated.
could anyone explain this to me?
Thanks a lot.
To write a sector you need to authenticate on that sector with keyB. Then you can overwrite the key block as:
new Key A | access bits | Key B
I always get the failure result when using ACR122U tool to authenticate Mifare 1K NFC tag, but I can use Android phone to read/write this tag.
ACR122U Load Authentication Keys
< FF 82 00 00 06 FF FF FF FF FF FF
> 90 00
< Key Structure: 00 < Key Number: 00
< Key: FF FF FF FF FF FF
Load Authentication Keys Success
ACR122U Authentication
< FF 86 00 00 05 01 00 00 60 00
> 63 00
Operation failed
Your remark about an Android phone being able to read and write this tag suggests it is formatted to contain NDEF data. Instead of the factory default key 0xFFFFFFFFFFFF, you could try to use the MIFARE Application Directory key 0xA0A1A2A3A4A5 for the first sector (blocks 0-3) and the NFC Forum key 0xD3F7D3F7D3F7 for the following sectors. See NFC Type MIFARE Classic Tag Operation for more details.
Use "NFC TagInfo" application for android. You can read hex data with that app and find out your correct keys. In the end of every sectors there will be "keya, access, keyb" data. First 6 byte (12 hex character) is key a and last 6 byte (12 hex character again) is key b. Use new keys for reading and writing to card.
The authentication of a MF Classic 1k card can be failed with different reasons.
Wrong Key
a. Length : It should be 6 bytes (12 Hex chars).
b. Key Matching : The key will be the hex FFFFFFFFFFFF in transport mode (by default) and it can be changed by a card providing vendor. You have to get the exact key from the vendor.
Key Category : The access condition (6-9 bytes of Block 3 of all sectors) will explain which key you have to use to authenticate a corresponding sector for a particular memory operation .To know more details please refer
http://www.nxp.com/documents/data_sheet/MF1S50YYX.pdf
In Mifare Classic 1K tags There are 16 Sectors and each Sectors contains 4 Blocks and each block contains 16 bytes. Before Reading or writing from a page You must have to Authenticate The Sector using Key A or Key B. When Authentication is complete then you can read or write. Here is the Authentication Command Authenticate sector 0 using that key as key A (60):
FF 86 0000 05 01 0000 60 00
Or authenticate sector 0 using that key as key B(61):
FF 86 0000 05 01 0000 61 00
or using this command you can also authenticate sector 0
byte[] authenticationByte = new byte[10];
authenticationByte = new byte[] { (byte) 0xFF, (byte) 0x86, (byte) 0x00,
(byte) 0x00, (byte) 0x05, (byte) 0x00,(byte) 0x00, (byte) 0x04,
(byte) 0x60,(byte) 0x00 };
for more details you can follow this answer
I have written an utility for some ACR readers and the ACR 122U with Mifare classic cards is hitting some kind of bug. The identical code works for ACR 1222L.
However Mifare Classic cards are crap, so I suggest switching cards to work around the problem.