I am using Mifare Ultralight C to make a access control system. The method I am using is based on the UID of the card. I can read the UID by NFC Reader (SeeedStudio shield on Arduino UNO) However, the UID is not reliable since there are writable UID card out there in the market. So I think that I should secure the connection by 3DES authentication and then block the reading from 0x00 which is from the first serial number byte. Is it the correct way to implement access control?
1 Answer
You cannot block read access to the UID. The UID is an immanent part of the anticollision/tag enumeration phase of ISO 14443 so the tag will always reveal that information. Moreover, Ultralight C permits read/write protection only from page 3 to the end of the memory.
What you could do is the following:
- Use the UID to identify the tag.
Derive a tag-specific key based on a master key and the tag's UID.
Ktag = fkey_derivation(UIDtag, Kmaster)
Use that key Ktag as 3DES key for the Ultralight C authentication.
- Protect (read and write) the whole data memory of the tag.
- Possibly store some additional authentication information on the tag (e.g. a signature over the UID). However, you should keep in mind that after authentication read operations are neither encrypted nor integrity protected. This means that an attacker could potentially retrieve the data stored on a tag by listening into the communication between a legit tag and a legit reader. Moreover, an attacker might be able to authenticate with a legit tag and then intercept any further read commands to return manipulated data. Basically this means that you should refrain from storing any non-integrity-protected permission information on such a tag.
And finally: MIFARE Ultralight C is certainly not meant to be used for access control!
-
So I should do like this: Reader: read the UID, then compute with known Kmaster to provide Ktag, after that, using that Ktag to authenticate with Ultralight C. If authenticated => provide the access. Ultralight C: write my own Kmaster(shared with reader) into the tag, then protect all info not to be read by other readers. Am I understanding correctly? Question about 3DES: so what is 3DES function in the tag? Does it just provide us slots to store enough 3 Keys as I understand? And 1 more thing, in the datasheet, we have 16 bytes to store 2 key (8 bytes/each). I am confusing about this now– Bao DoanCommented Jan 9, 2014 at 19:27
-
Oh, now I raise another question: So how the tag can authenticate with the Ktag we compute, does it have function to find that Ktag automatically?– Bao DoanCommented Jan 9, 2014 at 19:34
-
Thanks in advanced, you are my savior since I get lost in this for a while :)– Bao DoanCommented Jan 9, 2014 at 19:35
-
K_tag vs. K_master: No, you would need to do the same key derivation when personalizing the tag (i.e. when initially writing the key to the tag). So each of your tags actually contains a derived key and not the master key. Commented Jan 9, 2014 at 19:42
-
3DES is basically a concatenation of three single DES operations: ENC_3DES(x) = ENC_DES(DEC_DES(ENC_DES(x, K_1), K_2), K_3). (For 3DES decryption, DES encrypt and decrypt operations are the other way round.) There are two versions (one less secure and one more secure): 2-key 3DES and 3-key 3DES. In 3-key 3DES, K_1 != K_2 != K_3. In 2-key 3DES K_1 != K_2 and K_3 = K_1. Ultralight C uses 2-key 3DES, so the two 64 bit (actually only 56 bit with some parity bits) keys are K_1 and K_2, where K_1 is used for the two DES encryption operations and K_2 is used for the DES decryption operation. Commented Jan 9, 2014 at 19:50