Using your Apple device as an access card in unsupported systems
github.com
github.com
Classic Apple.
You'd think that it was common sense to avoid that, but we are talking about the company that invented DRM for the USB protocol...
I'm aware of this myself, because I work in games, and sometimes we literally can't comment on things; which leads to the speculation being very often the absolute most negative possible interpretation of what is happening, and completely invalid.
To take another more obvious example; imagine OpenBSD was, well, not open. Yet they didn't support Bluetooth. (they don't).
From and outside perspective, is this: because they don't consider it open source? Because they're not capable? Because they hate bluetooth headphones or interfacing with audio devices? Is it due to security- maybe related to file sharing or something... it could be privacy.
And if we thought they were just pure-through-and-through bastards, we'd think up more.
There's another perspective, ironically that covers your point as well as OpenBSD's lack of bluetooth support:
What if; it's actually much harder than we realise to make it easy to use and secure?
It's totally possible that a standardised format has only hacky, rushed and dangerous implementations. It's not uncommon at all, actually.
https://freedom-to-tinker.com/2008/07/15/transit-card-maker-...
If the company wants people to have positive thoughts, they should do positive things! If indeed there are positive reasons for an apparently negative thing, they should explain them.
If they can't or won't explain them, then people absolutely should assume if they feel like they're getting screwed, that they probably are.
This is I think the crux of so many modern philosophical problems. Is it possible for a corporation to do the right things and thrive? Arizona Iced Tea could be an example of this I suppose.
Do mega corporations and does Apple actually want people to think positive thoughts about them? We as consumers certainly want them to want that. But I have yet to see evidence of corporations caring about that.
Do consumers at all care about how unethical a corporation is (to the first approximation; there are always protest. Remember when Budweiser went out of business? Or Harley?)? If not, this whole thing is moot.
This happens everywhere, it's not a problem exclusive to games. It's a problem fundamental to trust - when you stop communicating with your audience, what do they assume from your behavior? Gamedevs feel this pressure as a consequence of releases like Duke Nukem Forever and No Man's Sky that promised the world and came out with nothing. Apple feels this scrutiny for the same reason - the quality of software they make is markedly worse than what they put out 15 or 25 years ago. We have to hold them accountable, Apple's silence is an unacceptable response to the rift they've created with the software standards community.
Apple has plenty of unexplained fees and double-standards, as developers we've learned better than to ask why. There is no reason Apple makes me pay $99 per year to improve their platform - they have no justification to arbitrarily deny third-party payment processing. The obvious reason, on the surface, is that offering another business the same full-fat feature access that you have threatens the service you intend to sell.
When Apple creates institutions like the App Store, iMessage and Apple Pay, they are implicitly asking themselves how they will treat their competitors. When they design these institutions around features with no third-party parity, they are creating unfair businesses and sustaining them on a policy of secrecy. We are not stupid people, we can surmise why Apple cares about service revenue by looking at their quarterly financials.
> What if; it's actually much harder than we realise to make it easy to use and secure?
So what? HTTPS is hard to secure, but Apple's not going to stop supporting that over some unnamed ideological protest. NFC and USB are comparatively simple, and you can implement every feature that Apple uses without resorting to DRM or middleware. The only tangible explanation comes in the form of licensing fees for MFi and Apple-branded serial connectors. It's about control and money, two perfectly acceptable explanations for a business as greed-oriented as Apple.
You have to be arguing in entirely bad faith to look at the rest of the technology market and assert that it's the standards forum's fault for not responding to issues that Apple won't even confirm they have in the first place. Not only is that one hell of a baseless assumption, it's an apologia based on a source that doesn't exist. Faith is not a virtue, in the business world.
Now, corporations are always greed driven to some extent but the problem is the sole focus on that and the duplicity around the subject from Apple "fans".
Modern Apple is so greedy that it makes the Bill Gates era look like child's play. It's not surprising, Bill Gates was an effeminate duplicitous man and Tim Cook is the turbocharged version of that.
No, it's really just Apple being paranoid/greedy about their platform. Android has had HCE for over a decade now.
That said, in my view Apple has every right to, on top of HCE, offer access to their secure element at restrictive terms: Even though Java Card has a "firewall" between installed applications, these things aren't really battle-tested to run completely untrusted and potentially hostile applications side by side with e.g. payment card applications.
But HCE and SE implementations can coexist! Android has, again, been doing it for over a decade!
And Apple even has implemented both HCE and SE – but HCE is EU only (if you're quiet, you can still hear Apple stomping their feet in the distance), whereas SE is "some non-EU countries" only, and requires paying (at least according to TFA) exorbitant fees.
If they didn't outwardly support Bluetooth, but a group of the OpenBSD devs had a side project to support it, and also that side project was deployed on a billion devices around the world and makes those devs millions of dollars every week...then yes, people would definitely accuse them of having motivations that were less than pure.
It’s easy to say that it’s not Apple’s problem if people use horrifically insecure RFID and NFC access systems. But I doubt the media, or the lawyers for any office block, would see it that way. The headlines basically write themselves “iPhone used to hack into secure government facilities” or something silly like that. Just look at the uproar the Flipper Zero created in Canada[1]. Now imagine if you could do that with an iPhone (which has most of the hardware needed) by simply downloading an app. Not a chance in hell Apple is gonna let their products be used like that (heck the AirTag stalking debacle demonstrates how silly the reaction can be when there’s an opportunity to roast Apple over an open flame).
It would be great if all this stuff was open but the reality of the situation is that RFID and NFC standards are trash, and even when there is a secure “standard” (I’ve yet to see any evidence that manufacturers actually aim for any kind of cross compatibility, even when following a standard), access control manufacturers haven’t bothered using them.
[1] https://arstechnica.com/security/2024/02/canada-vows-to-ban-...
iPhone users should be able to do that if they have any semblance of control over the hardware they bought. If MacOS supports SDR without any issues, and Apple's own implementation of NFC is good enough, I think this is a silly argument. Enabling NFC access does not turn an iPhone into a Flipper Zero any more than it does with Android, the argument is moot.
If the best reason we can muster is "it would make Apple look bad" then we might as well have put the Magic Keyboard and USB-A/HDMI ports in the garbage and withdraw Apple from the EU economic zone. Apple is perfectly capable of adapting to changes that do not align with their insular and stubborn worldview. Some would even say these changes improve their products.
Android devices use the same chips, and any access card that can be trivially cloned by any device, consumer or otherwise, doesn't deserve to be called that.
> It would be great if all this stuff was open but the reality of the situation is that RFID and NFC standards are trash
You clearly have no idea what you are talking about. What's broken isn't the entire ISO 14443 stack, but rather some legacy implementations. This is like saying "TLS is trash", because some old versions supported RC4 and DES 56 bit at some point.
> Just look at the uproar the Flipper Zero created in Canada
People create uproars about things they don't understand every day.
This attitude is exactly why we (hobbyists, security researchers etc.) can’t have nice things, and of course actual criminals still can.
You’re thinking about reality. Unfortunately, perception makes the world go round.
They didn't just consider it, that's what happened and was their plan. Not until EU regulations were on their radar did they actually start considering opening up the NFC APIs for others to implement.
> those official solutions require manual approval, incur additional (in some cases absolutely cuckoo $$$) fees
In the EU, there is HCE, under less restrictive terms but geographically isolated.
Imagine a world in which Apple would let people just... use the expensive devices they already paid good money for! (Yeah, I can't either.)
But all of that is still gated behind a ton of requirements, most importantly a required third-party lab certification [1]. I haven't found anything regarding pricing (but I'd be willing to bet it still doesn't come cheap), but even just the public requirements make this a no-go for hobbyist projects, unlike Android's HCE.
No need, since they're only doing this after (again) being forced by EU regulations, https://9to5mac.com/2024/01/25/apple-pay-nfc-europe-alternat..., so no extra credit handed out :)
Curious to hear what people who usually think EU regulations hinders innovation thinks of this move, since it seems like regulation actually promoted innovation in this case. Just a edge-case or perhaps something more?
A complementary method is to attach a writable NFC sticker tag to the phone. Though it has to be placed far enough from the phone's NFC antenna in order for both/either to work.
The upside is that you get a second tag of your choice (physically) on your phone. There are even UID-writable sticker tags out there (even if they can be a tiny bit harder to find).
You also don't need to replace your default transit card, which could be inconvenient depending on where you live.
In particular, I know unifi cards rotate keys. So you can’t simply clone them with a Flipper, and this also means third party cards don’t work. By default, this is true, but you can’t simply clone turn it off, as mentioned in the article.
Does this mean that the other systems’ cards are easily cloned? This seems very insecure, if so.
UniFi has support for this, but seemingly not by default.
This solution also doesn’t allow you to clone an existing card. You actually need the admins to add the UID of your Chinese transport card to their system.
Broadly, yes, almost all NFC based access systems are insecure and pretty broken. They mostly operate via security via obscurity, and the fact that anyone serious about security that deploys these systems will put a huge amount of effort into identifying one of an actually secure systems. More likely they will pair the NFC element with multiple other secure elements, such as photo badges, big security humans that demand people keep their badges visible, and card + pin entry on all important access points.
A big part of the reason why these Apple Wallet systems have taken so long to appear is because Apple seems to refuse to integrate with any system that isn’t built using secure cryptography. Turns out there aren’t many systems out there that use strong cryptography, rather than cryptographic systems that have been broken for decades.
Actually getting information on how any particular system actually provides its “security” is extremely difficult. Mostly you have to figure it out by being familiar with the different systems out there, and different NFC systems. Then it’s possible to parse the marketing terms into actual technical specifications that might give a hint at how a system works. The only sure fire way to find out, is to buy parts of the system (such as access tokens or readers), and evaluate the hardware using various NFC and RFID hacking tools to figure what manner of awful design this particular system uses.
This is like saying "almost all TLS/SSL versions are insecure and pretty broken". Don't use the broken ones!
> A big part of the reason why these Apple Wallet systems have taken so long to appear is because Apple seems to refuse to integrate with any system that isn’t built using secure cryptography.
The reason Apple Pay actually took longer than Google's solutions is because Apple (presumably) co-developed the payment networks' tokenization solution, which was required to avoid the problem of every issuer having to individually integrate with Apple or issue a "proxy payments card", which significantly complicates the business side of things (which is what Google Pay originally did, when it was still called Google Wallet).
It's definitely an impressive solution, but cryptography had little to do with it. Apple Pay uses the exact same cryptography as Google Pay and any physical credit/debit card issued in the past few years (in the US; decades elsewhere). If it wouldn't, you wouldn't be able to use it on any existing terminals!
Don't believe it? Here's some "Apple-grade" security in action: https://practical_emv.gitlab.io/ – a vulnerability, unpatched for years, because Apple has to work with the same standards as everybody else, since even they don't have the power to make every merchant, transit agency, and fuel pump rip out their existing hardware (or even software update it).
Google Wallet launched with NFC-based mobile payments in 2011. Apple Pay launched in 2014. Neither solution is fully rolled out yet.
Apple's "co-development" was all pre-launch, but not sure how much of this was Apple helping vs. Apple demanding. During this time, Apple demanded secrecy so that only select bank employees would know what was being developed/that it was being made for Apple.
There's an article about what was going down back then: https://archive.nytimes.com/dealbook.nytimes.com/2014/09/11/...
Slow uptake afterwards is a matter of not only every issuer needing to integrate, but also every payment terminal/network needing to be upgraded. Apple in turn likely held back release in a region until enough banks and payment processors had done the legwork.
These services are still rolling out - Google Pay added two more countries last week! Apple Pay came to Egypt last year. Samsung Pay came to Germany in 2020, Denmark, Finland and Norway in 2022 and Saudi Arabia in 2024. Doing anything with the financial sector anywhere is a bloody pain.
Sure, there's a long tail of banks/cards that don't support it yet, but I think it's fair to call Apple Pay and Google Pay massively deployed and successful solutions.
> every payment terminal/network needing to be upgraded.
Absolutely nothing needed to be upgraded in the payment terminals, or even the acquirers' systems. Tokenization involves only the network, the issuer, and the wallet provider (for POS/in-person payments).
To a POS terminal, an iPhone looks indistinguishable from a regular old contactless card, unless it's explicitly looking at some of the new (and backwards-compatible) tags indicating otherwise.
Sure, but my point was that Google didn't have an easier time as a result of Apple putting in the legwork - Google was first, neither is done, and others are far behind.
> Absolutely nothing needed to be upgraded in the payment terminals
You need to upgrade to support contactless payments, which was not previously a requirement to accept a payment method and not at all widely rolled out - in Denmark, contactless payments launched a year after Apple Pay released in the US, and that's despite Denmark generally being cashless and far ahead of US on credit card security stuff.
Contactless payment is still not universally supported, so upgrades are still pending.
Just because you can perform a secure payment with your iPhone, doesn’t suddenly mean every crappy MiFare classic access control system has suddenly become secure.
That's not the issue. Rather, there's an issue of what protocols existing access control systems support, what the iPhone can reasonably expose, and a need for integrating iPhone provisioning into every system, and for the last part, Apple likely hiding this behind some costly MFI certification program.
According to Ubiquiti, Apple Home Key integration strictly requires that the lock, reader and "processing unit" is a single combined device installed on the door. If your architectures splits that into two or three devices, then you'll be turned away at the door. There's numerous of these access key types, with different features and requirements.
Also, just being NFC doesn't automatically make it fit into the box of a smartphone wallet card. For example, take transit cards that use on-card balances to be able to board a bus in intermittent-connectivity areas.
Aliro is an access control standard launching this year which all major players seem on board with. This avoids the integration, certification and gatekeeping headaches.
> Broadly, yes, almost all NFC based access systems are insecure and pretty broken
To clarify, some NFC based systems just use the card ID, use ancient deprecated card types that have been broken for over two decades, or both. If the NXP NFC Reader app says your fob or card is MiFare Classic, then yeah it's in that category.
But higher security solutions also mean no card cloning, so pre-Aliro the vendor would have to go out of their way to get e.g. Apple integration and MFI certification.
Even if you have a system which is more secure than UID-only (i.e. not at all), e.g. using DESfire EV1/EV2 (and assuming they use it correctly) to have a non-trivially clonable access token, 99.9% still use what the industry calls "non-transparent readers" (simply because "transparent readers" were invented in like 2023), which is to say the actual card/NFC reader out in the insecure area has the DESfire master key in it and performs the challenge/response and only reports the decoded UID back to the access controller over some wires. Which is obviously completely insecure and open to all sorts of tampering. The physical access industry puts tamper contacts on the card readers for this reason.
The physical access industry is generally extremely tight-lipped about how their garbage actually works. Half the reason is that they know they're selling insecure garbage for a lot of money, the other half is that the industry genuinely believes not documenting stuff increases security. The third half is that having documented and open systems would mean their franchise/installer people would maybe not be able to take their fat cut in some cases.
No, basically all stored-value/transit cards and access cards use cryptographic two-way authentication, and for newer ones, the algorithms used are even decent (AES, 3DES etc.)
Essentially all old MIFARE Classic cards can be cloned with little effort these days, and some older access control and transit payment systems are still using these, but modern cards are much more robust.
Your analogy is poor for at least two reasons:
1. Transit cards are generally hidden inside a pocket and can only be read when read by specific machines in close proximity. Whereas number plates are designed to be on display and readable by human eyes from medium distances, or from publicly (or privately) owned cameras over long distances.
2. Your unspoken but implied alternative to the highly trackable number plate is no number plate. Whereas this discussion is discussing a cryptographically insecure transit card as an alternative to a cryptographically secure transit card.
You can achieve both better privacy (e.g. by not revealing the UID to unauthenticated readers, and never in plaintext) and better tracking (by cryptographically authenticating cards to unauthenticated readers), depending on how you structure the system, so I don't think it's possible to intrinsically say one is more private than the other.
The T-Union card definitely has other means of doing that, like by checking the card serial, which is stored in one of the files, or by getting the same static UID value as it is also reported in RATS.
But in the end, seems like one of the important transit partners did not want to even bother fixing it, so Apple was forced to allow the static UID.
It really shows how big companies like Apple, who like to talk about "privacy" and "security", are willing to bend over backwards, if this means getting access to the revenue stream. AFAIK they get a percentage cut of transit card top ups, and Chinese market is obviously massive.
For comparison, from what I've heard, when it comes to implementing the same transit feature in the US or in the EU, Apple is extremely strict with their partners. They may even tell their partners that they're unwilling to work with them unless they fully re-implement their transit card standard stack using other technology, or to format their cards differently, even if they are fully secure. The reasoning is, depending on how big the project is, is that Apple may not want to bother with porting the Applet implementation (in case of niche card standards), or writing a new card state parser (for existing card types like Mifare, which can be 'formatted' and store data differently, even if they use the same protocol).
That can be the ISO 14443 level UID (which is what TFA is talking about) or some application-level ID, potentially only accessible once the reader has authenticated itself using a system-wide "ID privacy" key, but unfortunately I'm not aware of any system that does that.
In other words, most, if not all, other cards usable in Express Transit mode are just as identifiable. For example, when you enable your credit/debit card for Express Transit in NYC, London or other open-loop systems, anyone (and I really mean anyone, not just any transit system reader, as readers are unauthenticated in the payment scheme protocols based on EMV!) can just read your card number (fortunately Apple Pay masks that and it's not directly usable for payments, but it's definitely a static identifier).
That said, you do have to be very close to somebody's device or wallet to be able to read the card.
As far as I know, no existing transit card in Apple wallet is fully secure in this regard. All of them (value-based ones like Calypso/Mifare/FeliCa/TUnion) have at least a couple of sectors/files/blocks/records readable without mutual authentication (be it for balance or S/N access), which could enable user tracking. FeliCa has constant NFCID2/IDM/PMM values. And CEMV and EMV ones (at least, MC & Visa) expose D-PAN through "magstripe data" tag or through ICC certificate data (9f46) via DDA (although Visa does not publish the key for Mobile in transit mode).
On the other hand, all of the Wallet-compatible "Access Card" implementations I've seen are pretty locked down. For MFDES, "list app", "list keys", "list file", "get virtual UID" and other commands are blocked, and no files are readable unless an authentication with the common/privacy key is made.
Returning back to the original argument: in my opinion, doing the tracking via UID, vs having to add proper reading & parsing logic for each card standard & particular implementation, is a much more involved process, so lack of UID randomization can't be fully disregarded as a security issue, even if there are other ways of achieving tracking.
IMO this is partly the reason why China (+ JP) are the only exceptions for Apple, and Google does not allow manual UID configuration via any of the official Android APIs (although some partners do so for their OEM wallets so that they could support some legacy card types). This way, they at least encourage their partners to avoid failure at the first step.
It doesn't seem explicit.
What makes this card powerful, lies in the way it changes how NFC behaves on your device when it's set as a default transit card:
Your device stops randomizing the UID on each tap;
Your device begins responding to all NFC readers as if they were express-transit enabled, just like on Android;
Also this card does not change its serial number and UID when moving to other devices, unlike most other ones.
"what the default behavior is for other cards set as transit cards" statement is countered by the article "Your device stops randomizing the UID on each tap". Granted, I know this part because in the past Google Pay on Android would randomize the UID on each read and on Apple devices transferring cards between devices would reinitialize the UID but would keep some application-specific (like a Suica card identifier) static, thus making these virtual cards unsuitable for UID-based identification for access control.
"how transit providers are supposed to match people to tickets" is not relevant to the premise of "This repository describes general status on the topic and a possible solution to allow you to use your device as an access card in UID-based access systems." In general, these are stored fare cards so they do not store a ticket and instead store an available balance.
They can provision these transit cards into Apple Wallet, but that's not the same thing as NFC access at all. The transit provider would have had to integrate with Apple, though, to get their card application loaded onto the iPhone's secure element.
> 2. Register inside the AliPay app
How about no.
> To address the Commission's competition concerns, Apple initially offered the following commitments:
> - To allow third-party wallet providers access to the NFC input on iOS devices free of charge
EU only of course. I'd be interested in seeing the EU overstep a bit and force Apple to apply EU rules worldwide, either "on all devices" or "on all devices sold in the EU, even while traveling."
I don't know if it's Apple or UniFi to blame for this fee, but it turned me off entirely of what would have been a day 1 purchase. Other, cheaper junky IoT home locks support Apple HomeKit for unlocking for free, why can't UniFi figure it out?
Really glad to see hacking in this space.
As far as I know, Ubiquiti is not responsible for this 5$ per year "tax".
Apple takes about 3$ per user per year for usage of "Apple Access Platform", and the rest is spent for licensing the credential technology, like to NXP for Mifare DESFire in this case.
This limitation was added precisely as to prevent HomeKey from cannibalizing that sweet recurring revenue from "Apple Access Platform" targeted at business customers, as companies want detached readers which can be hooked into existing PACS architectures.
There was a device which did not follow that rule - the Aqara U200 but it seems like they had spent a lot of time arguing with Apple to get approval, as there were multiple occasions where they promised HomeKey (thus generating lots of hype and pressure), and then came back on that promise. Although they delivered on it in the end, good for them.
I was testing my new Hikvision keypad against every card I have and wondering if I could use Apple Express Transit, when I stumbled upon your writeup. Looking forward to trying out a T-Union card later!
I understood in the past that iPhones weren’t supported because of the limitations described in the article. I figured once Apple opened up the system and Ubiquiti actually implemented it (both of which have now happened) that the old readers would work.
Although irritating, I’d consider paying $5/user/year, but I’m not about to rip out 6 card readers that I just installed.
Thing is, the PN7160 chip used in G2 does not support Apple's proprietary extension to the NFC standard, called Apple Enhanced Contactless Polling [1], so they had to replace it with the PN7161 version, which is a special SKU created by NXP in collaboration with Apple. ECP modifies the lower levels of the NFC stack, which "NFC Controller" chips do not always give the host full control over, as they abstract away the protocol implementation for use in non realtime systems. Hence the need to replace the chip.
Funnily enough, PN7160 and PN7161 is exactly the same hardware with exactly the same firmware. NXP just 'fused' some extra data into *1 model so that it does not ignore the special configuration command to enable ECP. The extra SKU exists only because of licensing, and could have been a firmware update instead.
Theoretically, as ECP is really only needed for the automatic selection & use of a card, and it does not affect the upper protocol layers, UI could have brought support for Wallet credentials to older readers, just without the "express mode", but Apple specifically prohibits the use of their cards with any non-certified and non-ecp readers.
[1] https://github.com/kormax/apple-enhanced-contactless-polling
On the other side... look at the status quo in access control systems. If you never did, be happy you never had to because the status quo is shit because the entire ecosystem is suffering from a severe lack of money - for physical locks, most people buy the cheapest shit they can get at Home Depot or whatnot, and for "fancy" stuff involving smartphones they do just the same, or order right from Alibaba. And that is a damn horror show.
Ubiquiti, for all I dislike the trend for recurring revenue everywhere, at least makes high quality and secure stuff - but with anything interconnected, keeping updates available costs recurring expenses. So it's either "the product is cheap ass and will likely have multiple bypasses in a year or two", "the product is extremely expensive but you will get updates for a reasonable time" or "the product is affordable, but costs recurring money".
I already paid for my iPhone! Why should my apartment building/employer/... have to pay a yearly fee to allow me to enter a building using it?
> The distance from which an attacker is able to eavesdrop the RF signal depends on multiple parameters, but is typically less than 10 meters.
That said, Apple devices use an active amplifier even in card emulation mode (which is why Apple Pay works considerably more reliably at awkward angles than Google Pay does on most Android phones).
Android has supported HCE-based card emulation and provided access to any app developer out there for a decade now. No special entitlement, certification, or licensing fee required.
but Apple doesn't do it for "privacy and security" reasons (read: they want iron grip on their closed ecosystem).
But even if yes, it's much less dangerous to lose 1 out of 1000 instead of losing one phone and poof all 1000 are gone and you are stuck asking random people a phone to call your relatives for help