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?
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.
来源：https://stackoverflow.com/questions/57018428/is-it-possible-to-implement-a-token-queue-in-nfc-cards