1 Topic by fufu65 (edited by fufu65 2012-11-06 10:26:21)

  • From: Pescara, Italy
  • Registered: 2012-11-06
  • Posts: 5

Topic: Mifare Ultralight C authentication configuration

Hi,

I'm writing an application that uses Ultralight C. Now I'm able to authenticate and to change the 3DES key, but I need to protect access to the card (the whole card or only some parts, if possible).

Can someone detail me how to use the pages 0x2Ah and 0x2Bh of the card? My new cards by default have this values stored: 0x2Ah -> 30:00:00:00; 0x2Bh -> 00:00:00:00. What that values mean and how to change them to protect access so that authentication is required for reading or writing the card?

Thanks in advance!

  • Registered: 2012-11-10
  • Posts: 11

Re: Mifare Ultralight C authentication configuration

This is a great question. I'm also searching for this... Anybody in the forum, please?

  • yobibe
  • Administrator
  • Offline
  • Registered: 2011-04-08
  • Posts: 142

Re: Mifare Ultralight C authentication configuration

Hi,

Only first byte of pages 0x2A and 0x2B is important.
So you have 0x2A = 0x30 and 0x2B = 0x00
0x2A defines the page address from which the authentication is required so here you don't need the key at all as memory goes up to 0x2F.
E.g. if you want to enforce authentication to access any part of the user memory, you've to set 0x2A = 0x04 as user memory starts at 0x04.
0x2B defines if authentication is required for read/write (0x2B=0) or only for write access (0x2B=1)

Phil

yobibe's Website

  • From: Pescara, Italy
  • Registered: 2012-11-06
  • Posts: 5

Re: Mifare Ultralight C authentication configuration

Hi Phil,

thank you for the response, but perhaps there is something wrong.
I have set first byte of page 0x2A to 0x04, leaving page 0x2B to 0x00; with this configuration I'm not able to read pages from 0x04 to the end of the card... even if the authentication is performed!!!
Furthermore, writing to the card is possible even without performing the authentication!!! So I succesfully restored the value 0x30 in the first byte of page 0x2A.
I repeated these steps three times on the same card, with the same result...
Is the description of value of page 0x2B wrong?

Thanks

Fulvio

  • yobibe
  • Administrator
  • Offline
  • Registered: 2011-04-08
  • Posts: 142

Re: Mifare Ultralight C authentication configuration

Mmm I just tried and it works as expected.

* Authenticate
* Read dump:
Address: 0x00    04:2C:A1:01:E1:ED:25:80:A9:48:00:00:00:00:00:00    .,�.��%.�H......
Address: 0x04    02:00:00:10:00:06:01:10:11:FF:00:00:00:00:00:00    ................
Address: 0x08    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x0c    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x10    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x14    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x18    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x1c    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x20    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x24    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x28    00:00:00:00:00:00:00:00:28:00:00:00:00:00:00:00    ........(.......

So here 0x2A=0x28 and 0x2B=0x00

* Reset
* (no authenticate)
* Read dump:
Read dump without authentication:
Address: 0x00    04:2C:A1:01:E1:ED:25:80:A9:48:00:00:00:00:00:00    .,�.��%.�H......
Address: 0x04    02:00:00:10:00:06:01:10:11:FF:00:00:00:00:00:00    ................
Address: 0x08    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x0c    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x10    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x14    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x18    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x1c    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x20    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
Address: 0x24    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00    ................
No data returned from read

So as expected I cannot read from 0x28

* (no authenticate)
* Write 0x04 to 0x2A
* Read dump:
Same as before, write failed obviously.

* Authenticate
* Write 0x04 to 0x2A
* Reset
* Read dump:
Address: 0x00    04:2C:A1:01:E1:ED:25:80:A9:48:00:00:00:00:00:00    .,�.��%.�H......
No data returned from read
No data returned from read
No data returned from read
No data returned from read
No data returned from read
No data returned from read
No data returned from read
No data returned from read
No data returned from read
No data returned from read

So now 0x2A is correctly set to 0x04 and we cannot read from 0x04

* Authenticate
* Read dump:
Dump completed successfully
* Write 0x01 to 0x2B
* Reset
* Read dump:
Dump completed successfully

Phil

yobibe's Website

  • From: Pescara, Italy
  • Registered: 2012-11-06
  • Posts: 5

Re: Mifare Ultralight C authentication configuration

Hi,

thanks, Phil, I've resolved my issues.
I've configured my application to automatically perform an authentication just before the first write operation; for this reason, write attemps were successfull.
I've NOT configured my app to automatically authenticate before a read operation, so I executed the authentication by clicking a button of my app; later, through another button, I tried to read the card.
So I discovered that if the time elapsed between the auth and the next op (read or write) is greater than about 1 second, the card returns in a non authenticated state and the read/write op fails!
If the auth operation is immediately followed by a read or write, the auth state is not leaved (at least after 5 minutes I'm able to read/write without another authentication).

I've also noticed that trying to authenticate a second time after a successfull one, the second auth fails; than the third succeeds; the fourth fails... and so on; I don't known if this is a normal behaviour or what is the reason, but I resolved this "problem" authenticating only one time... smile

Now another question...
I successfully tried to protect page 0x03 (OTP); but... I would want to protect the two lock bytes in page 0x02: it is possible? I suppose that it's possible if I protect the card from page 0x02 for writing, but I'm unsure of what could happen if I accidentally set the protection even for reading, because of the first byte (part of serial number).

Any ideas?

Many thanks

Fulvio

  • yobibe
  • Administrator
  • Offline
  • Registered: 2011-04-08
  • Posts: 142

Re: Mifare Ultralight C authentication configuration

I'm happy you managed to solve your issue.

Timeouts you're facing are due to the phone NFC stack.
If the tag remains powered the authentication remains valid forever (which is what happens on a PC reader for example).

You cannot set 0x2A to 0x02, that's easy.
Which means that there is probably a risk that people write the two first lock bytes and lock the tag as read-only.

Phil

yobibe's Website

  • From: Pescara, Italy
  • Registered: 2012-11-06
  • Posts: 5

Re: Mifare Ultralight C authentication configuration

Currently I'm developing a desktop app (MS Windows) with an SCL010 device (probably the next steps will be a phone and an Arduino board...)

I can confirm that if the time elapsed between the auth and the next op (read or write) is greater than about 1 second, the card returns in a non authenticated state and the read/write op fails; I even tried with an SCL011 (German nPA version) device with the same results, instead with an SCL3711 the auth state persists.
So this behaviour might be related to the drivers of the devices or to the internal chips.

I can set page 0x2A to 0x02! I've tried this with page 0x2B=0x01 (write protect only) and then I've tried to write the value 0x07 in the Lock0 cell, but the write op has failed!!!

Fulvio

9 Reply by yobibe (edited by yobibe 2012-11-14 08:15:33)

  • yobibe
  • Administrator
  • Offline
  • Registered: 2011-04-08
  • Posts: 142

Re: Mifare Ultralight C authentication configuration

Thanks for having shared your experiences!
You're right if auth vanishes it's fault of the reader side, not the UltralightC, and should be the same for any card (unless reader behavior depends on the card, weird weird)
Actually I'm using mainly PN533 chips with libnfc ant without PCSC so there I've full control of what happens and I can maintain power & authentication state stable.

0x2A=0x02: well you've discovered either a hidden feature or a discrepancy in the user manual :-)

I tested it also with read/write requiring auth and it works too.
Even 0x2A=0x00 & 0x2B=0x00 works.
In that case nothing can be read from the tag without authentication but it has no impact on the anticollision mechanism so card is not lost!

Phil

yobibe's Website

10 Reply by yobibe (edited by yobibe 2012-11-14 09:14:37)

  • yobibe
  • Administrator
  • Offline
  • Registered: 2011-04-08
  • Posts: 142

Re: Mifare Ultralight C authentication configuration

BTW after having tested all those weird cases I unveiled one bug in libfreefare, not yet fixed, see
https://code.google.com/p/nfc-tools/iss … ail?id=106
Problems occur when reading pages between AUTH0 - 4 < page < AUTH0  without prior authentication
Phil

yobibe's Website

  • Registered: 2013-09-04
  • Posts: 1

Re: Mifare Ultralight C authentication configuration

I have a doubt related, I want to make an application that essencialamente will only use NFC to authenticate the person in the system, and it requires that the NFC is extremely safe, and I've been searching and can not find where the safest and which uses best algorithm password.

thank you