They are designed to provide an additional layer of security to the NFC communication process by preventing unauthorized access to the chip’s data.
One example of such a chip is the NTAG 424 DNA from NXP Semiconductors. This chip has a unique feature called “Secure Unique NFC”, which generates a new and unique ID every time it is read.
Another example is the MIFARE Plus EV2 from NXP Semiconductors, which also has a feature called “Random ID” that generates a new and unique ID every time it is read.
That’s interesting but I feel uThat’s interesting but I feel it’d just confuse most systems unless they’re prepared to handle the yubikey-like OTP seed/key random generation. I’d love to see some use cases though, and ideally, non-proprietary hardware that can interpret and use the data.
Quick edit because I didn’t answer the title - No I don’t believe there are any implants with that kind of functionality.
Generally speaking, randomized UID is not a security feature. It is a privacy feature. It’s meant to make the true UID of the chip effectively hidden until properly authenticated.The random UID feature is defined in the ISO/IEC 14443 spec.
We don’t bother with this on the Spark 2 or Apex or any of our DESFire based implants because it’s not a significant positive impact for our customers. To the contrary, most of the time it becomes a problem for people that want to use their products with simple access control systems that don’t employ any security features and just use the UID.
In a stupid move they called it Random ID (RID) and use “RID” to describe it… but RID has a different meaning with smartcard chips like Apex that use Javacard AIDs and RIDs. Anyway, the whole UID thing is explained pretty well here;
From what I recall there is a command you can use to enable it with the DESFire chips, but it’s one way only. Once enabled I don’t think you can disable it. More reading is necessary.
Just to note, the “secure unique NFC” (SUN) and “Random ID” are two very different technologies. As noted by Amal, “Random ID” is for privacy, so that someone can’t get your UID until they are authenticated. The goal of the SUN is to have a public information (like a URL) that isn’t subject to replays. That is, I can have an ID, and, with a SUN, scanning that card will generate a different NDEF record every time I scan it, and the record can be verified on the server. Additionally, the server can verify whether the SUN is new or has been replayed, as it is based on an ever-increasing counter.