Read/write to NFC tag with password protection

Some tags such as MIFARE DESFire natively support passwords / encryption as you describe. Recreating this functionality on the more common types of tags (Topaz/MIFARE Ultralight, etc.) is inherently impossible as NFC tags do not have built in protections for the copying of their data (by design). You could potentially encrypt your data before it is encoded, but this would require the tool decoding the data to be privy to the encryption method (likely a standalone app, separate to the Android OS, for example). Cheaper tags can, as you say, only be made permanently read only.

In other words, most NFC tags will not support what you are trying to achieve but there exists tags (that are considerably more expensive) that support larger amounts of data and tools such as password based encryption.

As MIFARE DESFIRE adhere to ISO 14443-4 and assuming you're using Android you are able to make use of the IsoDep methods. For more info about how to read/write passwords, etc. see this related article: How well does the Android NFC API support Mifare Desfire?

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.

• Products implementing this type of password validation are, for example, Infineon SLE66R01P, NXP MIFARE Ultralight EV1, and NXP NTAG21x.

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.

• Products implementing a three-pass mutual authentication are, for example, NXP MIFARE Classic*, NXP MIFARE Ultralight C, NXP MIFARE DESFire (EV1), Sony FeliCa cards.

  ^{*) Note that the proprietary authentication and encryption protocol of MIFARE Classic is known to be broken since 2008. Moreover, MIFARE Classic is only supported on Android devices with an NFC chipset from NXP.}

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.