topic Re: security free Ultralight C reading in NFC

security free Ultralight C reading

petercwallis — Tue, 19 Apr 2022 15:45:42 GMT

We have an Android reader/writer adding log data to a collection of NTAG213 and Ultralight-C tags. According to the person who write the code, there is no authentication, nor security - I just have to (re)write 4byte blocks. I can do this with the NTAG213 and a MFRC522, but theUltralight-C tags seem to require some form of authentication to work at all. I am guessing that is all built in to the Android Phone - I can certainly see the required data when I scan it with the phone. The MFRC522 looks as if it doesn't even interface to the Ultralight-C tags. Is that true?

In front of me I have what is called a PN532 NFC/RFID breakout board. Should I open the packet or is that not what I want either? I gather I want the NFC Reader Library, but is there an intro that does the use-cases or something? I was sort of thinking our system would be NFC class 101 but no.

The aim is to read the tags with a pi and was quite happy using the spi interface and a datasheet. Less happy about installing a deb package that might or might not break everything else attached to the pi.

Re: security free Ultralight C reading

Fabian_R — Mon, 25 Apr 2022 18:28:27 GMT

Hello, sir,

Thank you for your interest in our products.

The MFRC522 does support any Mifare card but, the application implementation has to be developed. As you may notice, MFRC522 nor MIFARE Ultralight C. Aren't recommended for new designs but if you check the MIFARE Ultralight Documentation, you will find the MIFARE type identification procedure (AN10833).

Please evaluate the possibility of creating your project, based on CLRC663 and using MIFARE Ultralight AES as mentioned on the product page.

If you use CLRC663, the NFC Reader Library is fully supported and you will find a very useful example for MIFARE Classic cards.

I hope this information may have been useful.

Re: security free Ultralight C reading

petercwallis — Wed, 27 Apr 2022 08:14:15 GMT

Thanks yes it is sorted.

I needed to use the legacy product as that is what the client has.

It turned out the tags were being reported as Ultralight-C by the app on the phone but were in fact just Ultralight. The issue was that the Ultralight tags' memory, for some reason, is not random access, and the reader needs to read block 0 first before the rest of the blocks can be read. I could not see this anywhere in the datasheet and discovered it by trial and error. I still do not understand how the "wrapping" from 4 byte blocks on the tag to 16 byte blocks on the reader should work. I guess it is something to do with tearing, but the system behaviour is certainly confusing, especially near the first and last readable blocks.