Since reading a tag’s unique identifier (UID) or other hardware characteristics of NFC tags cannot be done with the beta release of CoreNFC, all anti-cloning measures at the developer’s disposal are precluded.
The concept of tag originality and reading a UID are related since both naive and advanced anti-cloning measures involve using it in some way. The decision to not allow developers to access the UID is discussed in this article.

Reading the Tag’s Unique Identifier (UID)

Even in its initial release, Android’s NFC API allowed developers to read an NFC tag’s UID. At the time, these UIDs were assumed globally unique and could serve as a simple means of ensuring a tag’s originality. Although applications such as payments or access control must use greater anti-cloning countermeasures than purely a tag’s UID, this decision was left to the developers. Apple’s Core NFC seems to be more opinionated on the topic as it does not expose the tag’s UID or provide a means to query its hardware attributes, which unfortunately precludes the use of most anti-cloning measures.

This decision is also disappointing because many use UID-only approaches have been used in applications where tag falsification is not a major concern. Android’s ability to read tag’s UID provided a readily available platform enabling such systems , which played a large role in facilitating NFC adoption. For example, many events featuring NFC badges or wristbands for interactive exhibits and contests base their systems on using the tag’s UID to identify an attendee without needing to store any other information on the tag.

Even without returning a tag’s UID, Core NFC’s ability to read NDEF messages is an immense step in the right direction. With it, developers can still easily implement the same use cases as those implemented with a tag’s factory identifier simply by encoding the tag with an NDEF message containing an identifier. Furthermore, unlike Android’s NFC API which allows developers to transceive arbitrary data packets with NFC tags, Core NFC from Apple does not expose these operations, preferring to present only valid NDEF messages that it discovers. This is a completely valid decision and a leap in the right direction from the previous Apple Pay-only NFC approach.

However, one is left to wonder why Apple would restrict access to something so basic such as a tag’s UID? To perform any operation on an NFC tag, a reader must learn the tag’s identifier through a process known as anti-collision, so choosing not to return it using either the NFC tag protocol or NFCNDEFPayload class is most likely deliberate. Also, without any data transceiving capability, other hardware attributes such as NXP’s authenticity signature can not be read either. It is possible that these features will be introduced in future releases of Core NFC, but, if not, then the possibilities for Apple are interesting. What Apple now has is a fleet of millions of readers that it alone controls. It decides what if any NFC capabilities will be possible and under what conditions.

MFi for NFC?

MFi stands for Made for iPhone/iPod/iPad. Certain peripherals such as Bluetooth headsets, game controllers, and CarPlay accessories require MFi licenses in order to interface with Apple devices. Since tag discovery is a feature that is highly sought after, Apple could very well monetize it by only allowing NFC tags featuring MFi compatibility to be discovered by iPhones. When a tag is discovered, no action would be taken unless the tag passes an MFi license check. If the tag is MFi licensed the iPhone would proceed to read the NDEF data and optionally verify the publisher’s identity. NFC tags are sold in the billions, so the revenue opportunity is clear. Apps would still be able to read tags without this license; however, to automatically discover the tag and read it without an app may require MFi compliance.

 

June 30, 2017