androidsecurityauthenticationnfcmifare

Read/write to NFC tag with password protection

I need to write/read textual data to an NFC tag. The way I am expecting the read/write should work is the following:

  1. First time write I should be able to set password.
  2. Next time when anyone tries to read OR write, if he has the password then he should be able to do the read/write.
  3. No other application should be able to modify my tag without the password I set at step 1.

I had one other approach in mind writing encrypted data to the tag once and the write is done make the tag read only. I am able to do this. But now I realize making the tag read-only is not so efficient.

I searched a lot over the internet but did not find any reliable article or guide yet. So if anyone has done password protection of NFC tags please guide me.

Solution

  • An NFC tag (or actually an NFC Forum tag that implements one of the five NFC Forum Tag Operation specifications) is a simple data memory without any security mechanisms (other than locking memory to read-only). These tags are intended to store freely readable data in NDEF format. No authentication or protection mechanisms against reading of tag contents (or copying of tag contents to other tags) are standardized.

    However, some existing tag products implement additional security features that go beyond what is specified by the NFC Forum.

    The most simple mechanism is a short "password" (typically a 32-bit value). For authentication, this password is transmitted to the tag in cleartext and the tag acknowledges/rejects the authentication. (Note that transmission in cleartext over NFC means that anyone sniffing the communication is able to obtain the password.) Some tags supporting this type of password protection can use the authentication to switch a defined memory area between no access, read-only access, and read/write access.

    A more sophisticated approach is mutual challenge-response authentication using a shared key. Compared to a simple cleartext password, this means that a passive eavesdropper can't discover the shared key. As with the password, the authentication state may be used to switch a defined memory area between no access, read-only access, and read/write access with most existing tag products. However, not all of them cryptographically bind the memory access and the authentication pahse together.

    When it comes to implementing any from of authentication on Android, you should be aware of the following:

    1. If you still want to benefit from automatic starting of your app through an NDEF message (either a custom record that you declare in the intent filter or an Android Application Record), you need to have a freely readable memory are containing that NDEF message. Since password protection/authentication is not part of the NFC Forum specifications, Android itself can't authenticate to the tag (Android would not have the right key/password anyways). Consequently, the NDEF memory area (for tags with flat linearly-addressable memory this is typically the first N blocks of the tag memory) must be readable without authentication.

    2. Even if you do not use NFC intent filters in the application manifest and only use the foreground dispatch system (or the reader-mode API), you might still want to use NDEF to discover/filter for your tags.

    3. You cannot use the NDEF abstraction layer (i.e. the Ndef/NdefFormatable classes) to access the protected memory area. Instead, you need to exchange the tag platform-specific low-level commands using one of the tag technology classes (NfcA, ..., IsoDep). Also don't try to mix between mutliple tag classes (e.g. using NfcA for sending the authentication command and Ndef for reading the data afterwards). While this works on some devices, it won't work on most devices since they reset the communication with the tag when swithcing between these communication objects.

    4. There are known issues with the tag presence check mechanism on some Android devices (mainly before Android 5) that may interfere with the authentication (i.e. the presence check may send commands between the authentication commands resulting in authentication failures). This problem can be overcome with the reader-mode API.

    5. Finally, be aware that if you store the password/authentication key within an app, an attacker could easily reverse-engineer your app to obtain the key.