Is it possible to implement a token queue in NFC c

Question

This question is specifically about MIFARE Ultralight C/EV1, or MIFARE DESFire EV1, or even NTAG cards. I want to implement a system of tokens, so that each time a normal user reads one of those cards they'll get one available token; that token will "pop out" from the NFC card they're reading. In other words, every time that NFC chip is read, it will issue a different usable token from the card's storage. Is this possible to implement?

Answer 1

UPDATE 2020/06/07>

NTAG 424 supports "Secure Dynamic Messaging" which might be applicable for your use case. You can store any NDEF message with a "dynamic part" which is optionally encrypted and authenticated.

Citing section 9.3 of NTAG 424 datasheet:

The Secure Dynamic Messaging (SDM) allows for confidential and integrity protected data exchange, without requiring a preceding authentication. NT4H2421Tx supports SDM for reading from one of the StandardData files on the PICC. Secure Dynamic Messaging allows adding security to the data read, while still being able to access it with standard NDEF readers. The typical use case is an NDEF holding a URI and some metadata, where SDM allows this meta-data to be communicated confidentiality and integrity protected toward a backend server.

But please note that this solution is not resistant to some specific tail-replay scenarios, citing:

When using SDM, residual risks coming with the Secure Dynamic Messaging for Reading have to be taken into account. As SDM allows free reading of the secured message, i.e. without any up-front reader authentication, anybody can read out the message. This means that also a potential attacker is able to read out and store one or multiple messages, and play them at a later point in time to the verifier. If this residual risk is not acceptable for the system’s use case, the legacy mutual authentication (using challenge response protocol) and subsequent secure messaging should be applied. This would require using an own application and operating outside a standard NDEF read operation. Other risk mitigation may be applied for SDM to limit the residual risk, without completely removing it:

• Track SDMReadCtr per tag at the verifying side. Reject SDMReadCtr values that have been seen before or that are played out-of-order. This is a minimum requirement any verifier should implement.

• Limit the time window of an attacker by requiring tags to be presented regularly (e.g. at least once a day) in combination with the previous mitigation.

• Read out the SDM-protected file more than once. This does not protect against attackers that have read out the valid tag also multiple times and play the received responses in the same sequence.

(Note that above-mentioned legacy mutual authentication protocol is what I described in the original answer below)

There is an interesting project implementing the backend server (with tag personalization instructions).

The original answer follows:

---

Common non-programmable smart cards usually provide one of (or some combination) of the following:

• fuse bits -- a memory area where values of individual bits can change only in one way (either from zero to one or from one to zero, but never both of them)

• monotonic counter -- an integer value stored on card which can change only in a single direction after the personalisation (either increase or decrease, but never both of them)

• electronic purse -- an integer value which can be decreased by one entity and increased by another entity (both entities proving themselves by a distinct secret key)

None of those functions directly provide any unpredictable tokens (see note 1).

Another aspect is that your 'token collectors' would have to possess a key allowing card write access (to be able to modify counters/purse) -- which allows them to easily deplete all remaining fuse bits or counter/purse values (effectively resulting in a denial of service condition for other 'token collectors'). Access control can't be fine-grained to allow only single token collection (which is probably what you want).

With a programmable smart card you can (semi) easily implement any operation semantics you need -- have a look at Java Card (programmable smartcards are more expensive though).

---

Given your 'token collectors' are online while reading the card then probably the simplest way is to use the card only to prove that 'token collector' is in its proximity and generate the 'token' on the server.

To prove the proximity to the card the 'token collector' would use his/her NFC phone to relay mutual authentication commands between the server and card. He/she does not need to know any of card keys for that.

Any smartcard with mutual authentication (e.g. Ultralight-C or DESFire) is usable in this scenario (see notes 2 and 3).

Communication for DESFire would look similarly to this:

Good luck!

---

Note 1: Actually there are cards which can generate an unpredictable 'balance certificate' for their electronic purse, but I am not aware of any CL card supporting this.

Note 2: Cards with password based authentication are not suitable as 'token collectors' could easily intercept the password being sent to the card. MIFARE Classic is not suitable as well as encryption key needs to be loaded directly to the reader (relaying is not possible).

Note 3: Notice that by performing this relayed authentication you grant the 'token collector' all access rights bound to the respective key (although he/she does not know the value of the session key). Thus Ultralight-C is not a good choice as you would technically give him/her a complete access to the card. Similarly do not use DESFire card master key for relayed authentication -- create a new application with 2 application keys (with random values known only to you) and use the second key (not application master key) for relayed authentication. Remember to change the card master key as well.

Note 4: DESFire EV2 has protection for command relaying so you would have to test if it works in your scenario.