We did extensive research on the subject, there is no mystery. iOS will only read MIFARE tags with NDEF formatted data.
If you write NDEF data to a formatted MIFARE card, it will be 'compatible' with iOS.
Otherwise, only the UID can be detected.
The real mystery is why Apple refuses to open the low-level read commands. (To read NDEF, or determine that the data is _not_ NDEF, you need to read the card.)
It's not a mystery - it's anti-competitive behavior where they only want to give access to low-level NFC access (required to enable things like door locks, car keys, payment/loyalty card systems, transport, etc) to "partners" who sign an NDA and agree to a rev-share.
For all the things wrong with/bad about Apple's iron grip on low-level interfaces, in this case that's not the only reason:
MIFARE Classic uses a mandatory, proprietary (presumably still patented) encryption algorithm even for "world-readable" cards, on top of the ISO 14443-3 standard. I'm not even sure whether Apple could legally offer that capability without licensing it from NXP.
On Android, only devices with an NXP chip support these tags for the same reason.
You could argue that Apple could just provide even lower layer access to the contactless interface to allow apps to implement it in software, but I'm not sure if that's feasible (due to timing constraints).
(Note that the article doesn't specify which MIFARE tags it is about. If it's MIFARE Classic, something must have changed, and maybe Apple has licensed the required NXP patents? DESfire should work with iOS without jumping through any hoops, since that implementation is ISO 14443 compliant all the way up to -4.)
Seconded. There’s almost certainly NXP IP used in nearly all NFC implementations which makes them subject to their terms.
Those terms are in turn set by the partners that asked for these technologies to be developed in the first place. And so any development gets slowed to a crawl in this space.
That's for card emulation. This article is about using iOS devices as readers.
ISO 14443 card reader functionality has been made available some iOS versions before, but it's still restricted (e.g. you can't select any "payment" ISO 7816 applications, you have to predefine the list of AIDs you want to be able to select, and you don't have lower layer access to ISO 14443).
I'm not aware of any announcements to further open up "reader" mode.
Big companies that can afford to pay the certification fees maybe can; I definitely can’t. The entitlement is not available to regular app developers, unfortunately.
In the EU, maybe. And even then you will most likely need to beg for an "entitlement" to use it which may have requirements around being a registered business, etc so hobby apps are still excluded.
There's two versions of access to "card emulation" mode:
- The EEA-only HCE (which lets you emulate the card in your app in software, for a limited list of use cases, which makes it a non-starter for fully offline systems unfortunately, as there's no protection against exfiltrating any keys from the app), and
- The some-non-EEA-countries-only "full smartcard access" solution, which requires you to pay Apple and do a ton of (presumably also very expensive) certification.
So for different reasons, neither is something in scope for hobbyists at the moment, unfortunately.
Back in 2015 I was tech lead for a modern (web based) SaaS library management system and getting it to work with RFID tags with a wrapper application was all sorts of fun and games.
We got RFID library tags working on Android, but with iOS locking down NFC access it turned out to be impossible and we had to get libraries to buy bluetooth connected RFID scanners.
This is cool, but the most interesting part is the part that requires investigation, i.e., what do the compatibility tools write to the card to make it iOS-compatible? I've done some work with iOS NFC, but not enough to have experienced the undocumented quirks.
My read of the proxmark code (https://github.com/RfidResearchGroup/proxmark3/blob/master/c...) is that the `ndefformat` formatted the tag MAD (https://www.nxp.com/docs/en/application-note/AN10787.pdf), which you'd do for NDEF, then had a single TLV TERMINATOR at the block where the NDEF message starts. Then he used NFC Tools to write on an NDEF text record (which iOS background reading would ignore) and maybe something else? After that he then used `ndefwrite` to write on a URL record. I wonder if he could have skipped the NFC Tools and written the URL record and gotten the same result. Proxmark dumps before and after using NFC Tools would be insightful.
This is one of those cases where I know I really should investigate further, but I'm taking this one step at a time. Perhaps digging in to the "why" will become a follow-up post
I didn't intend for what I wrote to be a criticism; that's on me. I just found it funny the most interesting step was akin to "... and now you've drawn the animal", if you understand the reference.
My quick eye-skim didn't see much, but I'll do a byte-for-byte diff. I imagine its a difference in the NDEF headers? (but even that doesn't make sense, since I wrote the headers again from the pm3)
Something's clearly up there. You can see that even IOS and Android disagree with each other on what NDEF should look like by a few bytes. Very interesting.
Yep, 89 EC A9 7F 8C 2A 00 00 on iOS versus FF FF FF FF FF FF on Android. Interesting how the number of bytes is different, I should play with them a bit.
If a URL is written using NFCTools on iPhone, iOS will open it in the default browser without using NFCTools, or in the related app (eg Instagram) if there is one.
I find this only to be true when used on the same iPhone where NFCTools was used.
If you try to have another iPhone detect the badge, it appears not to work - unless you use NFCTools on that iPhone, too. I don't have conclusive proof but that's what the evidence seems to indicate.
Proxmark's "auto" command should get you most of the way to knowing.
Then check if any of the "hf mf c*" commands work on it (in which case, you have a gen1a magic card)
Nice, I didn't know about auto, thanks! It turns out I have some Gen 1a "magic" cards (as in, actually in a card form factor), and some tags that seem to be Gen 3, but not magic?
Gen 1, 1a, 3 and 4 all use special commands to unlock and edit block 0.
Gen 2 treats block 0 as always being r/w. This allows Android phones to directly write to it (but also makes it possible to lock the card).
In terms of pm3 commands, "auto" tries everything. You might also want to use "lf search" or "hf search" to only try one of your antennas and not the other.
The actual Magic part isn't really important here, since my phone doesn't even care about block 0. It just makes it easier to read and wipe the card when you have the extra command set at your disposal.
I suspect the comment (above, at the time I wrote this), where they mention that Apple only wants partners to be usable, is the Ockham's Razor answer.
Probably some "magic key" ID.
But this is not my area of expertise. It's a cool story, though, and why I like hanging here. Considering getting a Proxmark and the NFC Tools app, just to play around.
The cheapest RFID/NFC "card" tag is an expired tap-to-use transit ticket. It has a unique ID that can be used to trigger an iOS Shortcut to take any action, e.g. speak an audio description, open URL, open app, etc.
In a simple sense, NTAG cards can do NFC things, but MIFARE can do lots more (access control for example)..and also NFC things..somewhat.
Magic mifare refers to special cards that let you bypass the write-lock of genuine mifare cards. These are mostly used for cloning keys (either for red-team pentesting or for people who want a copy of an office key for whatever reason)
MIFARE Classic uses a proprietary and mandatory encryption/authentication algorithm and is therefore not ISO 14443-4 compliant. As a result, NFC-compliant readers don't need to support it, and in fact non-NXP ones (including many popular Android phones) usually don't.
On the other hand, as you say, MIFARE Classic supports capabilities beyond NFC/NDEF, but there are fully NFC-compliant tags that do so as well (e.g. MIFARE DESfire, which properly stacks encryption in an ISO 14443-4 compliant way).
Many of my cards are just repurposed from other things. Lots of hotel keycards can be rewritten to open URLs on phones for example.
I actually have a hotel keycard taped to my washing machine to do some laundry-based automation with my phone. Maybe I should write about that sometime..
If you're getting an implant already, why not make it an actual smartcard that you can use for WebAuthN, GPG, SSH etc.? :)
On the other hand, the fear of permanently bricking it or messing up the GlobalPlatform card management key has so far prevented me from doing it myself...
Because those cost $350 as opposed to $89, and the install only costs $60, and there is no stopping you from implanting more than one in different locations.
Many people get the small xEM or xM1 first to play with.
If you only care about static data that you can optionally freeze to a permanent read-only mode, NTAG21[3|5|6] tags are probably among the cheapest ones that reliably work with all iOS and most Android devices.
MIFARE Classic supports (completely broken and for this use case) useless encryption and doesn't work with some Android devices, as they're not really a part of the standardized NFC stack.
If you want to get really fancy, you can also get a Java Card based smartcard and install an NDEF application yourself. You could then also install a FIDO application and use the same card as a "homebrew Yubikey" :)
In my experience, the notification you see at the end of article was used to advertise your brand/site.
The number of obnoxious people/guerilla ad companies that printed and programmed NFC tags and stuck them in random places was way too high. In some cases, they would replace the businesses QR code with the NFC tag. In some cases that NFC notification would pop up instead of the business’s menu. Quite annoying.
Then there was a case where the person stuck the raw tags _under the table_, so putting your phone down in random places would spam this notification on your screen.
Ah, we did the under-the-table thing with NFC stickers in school! Love rickrolling a well-placed phone on a classroom desk lol.
I'm personally not a huge fan of needing to use NFC tags in the real world (parking meters use them for payment around here), but I do like creating tags.
Has anyone managed the opposite feat, i.e. made a piece of hardware that can recognise an iPhone over NFC? I'm trying to design control system that relies on you touching your phone to various hardware readers (with some kind of unchanging key/identity), but off-the-shelf MFRC522 etc don't seem to work, and the 'official' Apple way requires an NDA...
And iOS as well as iPadOS now also support USB smart card readers. iPads can actually use them to access NFC FIDO tokens. (Why iPads don't have native NFC is completely beyond me, there are so many obvious use cases for it)
> And iOS as well as iPadOS now also support USB smart card readers.
Oh, that's very cool!
Apple seems to silently be implementing more and more features to make iOS/macOS a full-fledged smart card OS; I've also noticed that FIDO over CCID is now available natively on macOS, and by extension in Firefox and Safari via WebAuthN (which finally lets me use my smartcard form factor FIDO authenticator).
I think you're supposed to make a "Pass", load it on Wallet app, then load the card with double press of side button. You can't just tap a blank iPhone and get its raw hardware ID.
At least Suica train cards(based on FeliCa/NFC-F) on iOS can be read from third party Android apps, and Apple do advertise iPhone feature to store corporate IDs, so the idea of using iPhone for gate tap-in card should be completely fine.
Without getting into the weeds of programming for the secure element (some non-EEA markets only, NDAs, tons of certifications etc.) or restricting yourself to HCE (available only in the EEA), you could also "flip the model around":
ISO 14443 reader access has been available globally, so if you're fine with having to open an app before an interaction with a reader, you could have the reader perform card emulation, and the phone "read/write" it like a tag, i.e. send APDUs which the device behind it then interprets.
Otherwise, only the UID can be detected. The real mystery is why Apple refuses to open the low-level read commands. (To read NDEF, or determine that the data is _not_ NDEF, you need to read the card.)