> developers who want to build secure contactless experiences into their iOS apps using these APIs will need to enter into an agreement with Apple and request the NFC & SE Platform Entitlement
This is cool, do love the hacking ingenuity. And not that I want to give Apple extra credit, but they are slowly opening up NFC: https://www.macrumors.com/guide/apple-nfc-chip-ios-18-1/ - Is is very restrictive (probably) and very late - most certainly. But at least it's slowly coming.
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?
Another move that seems at a glance to foster innovation, not remove it. Just like having a common standard like PCI helped innovation in desktop computers, making sure companies use a standard charging connection could have the same effect.
iOS 18.1 has enabled more and deeper integrations: You can now essentially write your own, custom-logic SE applications, and more use cases are available than before.
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.
The fact that Apple even considered "closing" a general purpose standard like NFC is a testament to how much they are willing to drag their feet on any innovative customer-facing features.
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...
This is a common trope, and given that they don't speak about these things publicly people will take whatever negative opinion they think up and consider them completely valid.
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.
> What if; it's actually much harder than we realise to make it easy to use and secure?
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.
They're an absolutely staggeringly immense company and they fight tooth and nail to preserve their rent seeking and premium margins. Nobody owes them a positive interpretation of apparently poor behaviour, especially not when discoverable materials often show the principals are absolutely doing the wrong thing (e.g., Jobs and the anti-labour wage fixing racket).
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.
> If the company wants people to have positive thoughts, they should do positive things!
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.
Well, it’s not like anyone sued a Dutch university for finding security vulnerabilities in their NFC transport card solution…NXP would never rush their implementation to market and then try to sue their way out of any vulnerabilities.
> To take another more obvious example; imagine OpenBSD was, well, not open. Yet they didn't support Bluetooth. (they don't).
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.
I also disagree with their analogy. Like a truer comparison would be if this hypothetical "NonopenBSD" had a fully-functional Bluetooth stack but only with paid partner organizations.
> and sometimes we literally can't comment on things; which leads to the speculation being very often the absolute most negative possible interpretation
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.
Thanks for saying all the right things.
I'm always dumbfounded when I find all kinds of people on HN who will fight tooth and nail for Apple when clearly their behavior is almost always purely greed motivated.
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.
> The fact that Apple even considered "closing" a general purpose standard like NFC is a testament to how much they are willing to drag their feet on any innovative customer-facing features.
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.
Google's implementation is also more janky, with phones needing a data connection and having to go online to download new tokens(?) every 3 transactions or so.
Nothing prevents Apple from running HCE (which is what Android offers all app developers) in parallel with SE-based cards (which are generally more offline-capable). In fact, Android has supported just that for years.
Eh, the NFC chips in Apple devices are very capable. If Apple opened them up to everyone, you would see half a dozen “clone your access card” app a day later.
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.
> 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.
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.
> If Apple opened them up to everyone, you would see half a dozen “clone your access card” app a day later.
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.
Eavesdrop, but not initiate a transaction. I definitely wouldn't want to be in the same room as an active ISO 14443 antenna capable of powering up even low-powered tags/cards from 10 meters. That would be a lot of power!
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).
Yes, but let's be clear: You have Apple to thank for it.
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.
> 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).
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.
I’m curious what the security of these NFC lock systems looks like. (I’m talking about the commercial building systems mentioned like Brivo and Unifi, not home systems.)
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.
The physical access industry is a complete, unmitigated clusterfuck.
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.
> Does this mean that the other systems’ cards are easily cloned? This seems very insecure, if so.
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.
> 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.
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.
> Broadly, yes, almost all NFC based access systems are insecure and pretty broken.
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).
> The reason Apple Pay actually took longer than Google's solutions is because Apple (presumably) co-developed the payment networks' tokenization solution,
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.
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, 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.
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.
Erm, we’re discussing NFC/RFID used for access control systems. That has literally zero to do with Apple Pay, beyond using some of the same hardware.
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.
They specifically write that this only supports UID based authentication. So, the card answers with the same unique ID every time.
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.
> Does this mean that the other systems’ cards are easily cloned? This seems very insecure, if so.
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.
My guess is that there's some city or transit system which needs the UID to be static for one reason or another, like in order to avoid double charging the same user if they accidentally scan their card multiple times.
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).
Most stored-value transit systems require to be able to read some form of ID from the card for key diversification (otherwise you'd have to use the same key for all cards in the system, which is obviously pretty insecure).
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.
A more secure card doesn't make surveillance any harder. If anything, it's the opposite. An easily copyable UID makes bad data more plausible. Bad data makes surveillance harder.
The fact that license plates can quite easily be forged by anyone willing to put some effort into it doesn't make them not uniquely capable of tracking where you go in your car.
I don't disagree with that at all. I never said that insecure unique identifiers weren't useful for tracking. What I said is that a cryptographically system is superior to an insecure system for the purposes of surveillance, because the ability to track is the same, and the quality of data is higher. From this I concluded that surveillance doesn't make sense as a motive for this particular transit market sticking with an older, insecure system.
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.
Even if it weren't, then there would just be another form of ID at the application layer (e.g. the card number for credit/debit cards used for some other transit systems via Apple Pay).
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.
I guess what I am saying is: it doesn’t explain the problem it is solving very well. It doesn’t say what the default behavior is for other cards set as transit cards do (I would expect it to work the same way-ish) and how transit providers are supposed to match people to tickets, etc. then why this particular card is special. It assumes you know.
That whole "The solution" section does explain this.
"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.
I don't think Alipay actually has any direct NFC access, does it?
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.
> 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 was really excited about the new UniFi G3 access card reader claiming support for iPhone unlock until I realized it's $5/year/device. It just seems like a slow boil into subscriptions for a company whose entire value prop is prosumer networking without the contracts.
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?
Hi, I'm the author behind the article referenced in this post.
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.
They could not implement "Home Key", because Apple requires that compatible devices are implemented as a single unit, containing reader + lock.
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!
It's SSO tax applied to hardware devices. But at the same time, it's clearly a more premium feature and if you're a business you've got the $5000/year to pay for 1000 devices. $5/device/year is not exactly expensive. Heck, I'd pay Ubiquiti $15/year for my family to be able to use it at home. That's less than I pay for almost any subscription for anything.
It’s sad that we have to assume this is the agenda for all offerings that don’t allow paying current price x years in advance (possibly including adjustion for expected inflation). Leaves a very sour taste, especially in the case of hardware devices
> It just seems like a slow boil into subscriptions for a company whose entire value prop is prosumer networking without the contracts.
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".
For Apple, the same thing applies. Keeping an entire zoo of operating systems safe from malicious entities requires serious work that needs to be funded somehow.
What I can’t figure out is why the old readers, which clearly read NFC cards, can’t work to read iPhones, which emit NFC.
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.
The reason why only the G3 supports Apple Wallet is exactly because of the NFC chip. Otherwise, they are completely the same hardware, and mostly the same software.
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.
Unless you are homeless why you need so many things on you all the time?
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
Note that this article is 2 years old, and therefore predates iOS 18.1, which allows applications to directly access the NFC hardware: https://developer.apple.com/support/nfc-se-platform/
> developers who want to build secure contactless experiences into their iOS apps using these APIs will need to enter into an agreement with Apple and request the NFC & SE Platform Entitlement
Classic Apple.
Has there been an emulation solution made for Mifare Classic since this direct access?
This is cool, do love the hacking ingenuity. And not that I want to give Apple extra credit, but they are slowly opening up NFC: https://www.macrumors.com/guide/apple-nfc-chip-ios-18-1/ - Is is very restrictive (probably) and very late - most certainly. But at least it's slowly coming.
> And not that I want to give Apple extra credit
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 bit less innovation-ish but with large concrete impacts https://commission.europa.eu/news/eu-common-charger-rules-po...
Another move that seems at a glance to foster innovation, not remove it. Just like having a common standard like PCI helped innovation in desktop computers, making sure companies use a standard charging connection could have the same effect.
The only thing that's been opening up so far is Apple's cash register. From the article:
> 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.)
The article is 2 years old, and predates any of the iOS 18.1 changes.
iOS 18.1 has enabled more and deeper integrations: You can now essentially write your own, custom-logic SE applications, and more use cases are available than before.
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.
[1] https://developer.apple.com/support/nfc-se-platform/
The fact that Apple even considered "closing" a general purpose standard like NFC is a testament to how much they are willing to drag their feet on any innovative customer-facing features.
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...
This is a common trope, and given that they don't speak about these things publicly people will take whatever negative opinion they think up and consider them completely valid.
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.
> What if; it's actually much harder than we realise to make it easy to use and secure?
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.
They're an absolutely staggeringly immense company and they fight tooth and nail to preserve their rent seeking and premium margins. Nobody owes them a positive interpretation of apparently poor behaviour, especially not when discoverable materials often show the principals are absolutely doing the wrong thing (e.g., Jobs and the anti-labour wage fixing racket).
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.
> If the company wants people to have positive thoughts, they should do positive things!
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.
Years after nfc was added to android I have yet to see anyone complain that I can write an android app that has raw NFC access.
Well, it’s not like anyone sued a Dutch university for finding security vulnerabilities in their NFC transport card solution…NXP would never rush their implementation to market and then try to sue their way out of any vulnerabilities.
https://freedom-to-tinker.com/2008/07/15/transit-card-maker-...
> To take another more obvious example; imagine OpenBSD was, well, not open. Yet they didn't support Bluetooth. (they don't).
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.
I also disagree with their analogy. Like a truer comparison would be if this hypothetical "NonopenBSD" had a fully-functional Bluetooth stack but only with paid partner organizations.
Yeah, NFC truly is the hot path to the majority of CVEs on Android, right?
To not get eaten by a bear, you only have to be quicker than the slowest camper.
> and sometimes we literally can't comment on things; which leads to the speculation being very often the absolute most negative possible interpretation
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.
Thanks for saying all the right things. I'm always dumbfounded when I find all kinds of people on HN who will fight tooth and nail for Apple when clearly their behavior is almost always purely greed motivated.
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.
> The fact that Apple even considered "closing" a general purpose standard like NFC is a testament to how much they are willing to drag their feet on any innovative customer-facing features.
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.
It's understandable in the context of Apple Pay I think.
Google pay coexists with an open NFC API on the same devices and has since before IOS had NFC support
Google's implementation is also more janky, with phones needing a data connection and having to go online to download new tokens(?) every 3 transactions or so.
Nothing prevents Apple from running HCE (which is what Android offers all app developers) in parallel with SE-based cards (which are generally more offline-capable). In fact, Android has supported just that for years.
Point taken
Eh, the NFC chips in Apple devices are very capable. If Apple opened them up to everyone, you would see half a dozen “clone your access card” app a day later.
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-...
> 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.
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.
> If Apple opened them up to everyone, you would see half a dozen “clone your access card” app a day later.
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.
Apple is held to a higher standard. It’s a feature of their model, as they are clearly accountable for the full stack.
Apple is accountable for everything users do with their devices? Seriously?
This attitude is exactly why we (hobbyists, security researchers etc.) can’t have nice things, and of course actual criminals still can.
In the press, absolutely.
You’re thinking about reality. Unfortunately, perception makes the world go round.
Oh and I only have to give my identity to Alipay and Chinese transit? And modify my phone so it consistently beacons out a trackable ID?
It isn't beaconing out a trackable ID unless one manages to get into NFC range, which isn't gonna be read from miles away
10 meters is plenty to covertly track you entering/leaving a building.
> The distance from which an attacker is able to eavesdrop the RF signal depends on multiple parameters, but is typically less than 10 meters.
https://en.wikipedia.org/wiki/Near-field_communication
Eavesdrop, but not initiate a transaction. I definitely wouldn't want to be in the same room as an active ISO 14443 antenna capable of powering up even low-powered tags/cards from 10 meters. That would be a lot of power!
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).
Yes, but let's be clear: You have Apple to thank for it.
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.
> 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).
That information could come in handy, cool.
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.
I’m curious what the security of these NFC lock systems looks like. (I’m talking about the commercial building systems mentioned like Brivo and Unifi, not home systems.)
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.
The physical access industry is a complete, unmitigated clusterfuck.
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.
> Does this mean that the other systems’ cards are easily cloned? This seems very insecure, if so.
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.
> 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.
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.
> Broadly, yes, almost all NFC based access systems are insecure and pretty broken.
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).
> The reason Apple Pay actually took longer than Google's solutions is because Apple (presumably) co-developed the payment networks' tokenization solution,
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.
> Neither solution is fully rolled out yet.
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, 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.
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.
Erm, we’re discussing NFC/RFID used for access control systems. That has literally zero to do with Apple Pay, beyond using some of the same hardware.
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.
They specifically write that this only supports UID based authentication. So, the card answers with the same unique ID every time.
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.
> Does this mean that the other systems’ cards are easily cloned? This seems very insecure, if so.
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.
I wonder why the Chinese transit card uses an unsecure method. Sounds like that is a lone outlier case so presumably intentional for some reason?
My guess is that there's some city or transit system which needs the UID to be static for one reason or another, like in order to avoid double charging the same user if they accidentally scan their card multiple times.
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).
Most stored-value transit systems require to be able to read some form of ID from the card for key diversification (otherwise you'd have to use the same key for all cards in the system, which is obviously pretty insecure).
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.
That's a fair argument.
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.
Given the UID is the same every time, I can assume it’s to make surveillance easier?
It's China. They can just tell the transit agency to pull up transaction records, no backfired system required.
A more secure card doesn't make surveillance any harder. If anything, it's the opposite. An easily copyable UID makes bad data more plausible. Bad data makes surveillance harder.
The fact that license plates can quite easily be forged by anyone willing to put some effort into it doesn't make them not uniquely capable of tracking where you go in your car.
I don't disagree with that at all. I never said that insecure unique identifiers weren't useful for tracking. What I said is that a cryptographically system is superior to an insecure system for the purposes of surveillance, because the ability to track is the same, and the quality of data is higher. From this I concluded that surveillance doesn't make sense as a motive for this particular transit market sticking with an older, insecure system.
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.
Cryptography is a means to an end.
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.
Even if it weren't, then there would just be another form of ID at the application layer (e.g. the card number for credit/debit cards used for some other transit systems via Apple Pay).
this is cool but the limitations make it almost unusable
Seriously. Better to tape something to your phone at that point!
should have a (2023) tag based on commits
Does this work with ANY card set as the transit card in iOS? Or just this one type of transit card?
Your question is answered in the article.
I'm not sure that it is. It goes to great lengths to explain how to get this particular card + says 'any transit card' in so many words.
It doesn't seem explicit.
Yes, it does explain it.
https://github.com/kormax/apple-device-as-access-card?tab=re...That's explaining some specific technical properties of how this particular NFC card works, it not explaining what the implications of that are.
It's explaining what sets this NFC card applet apart from others on iOS and why it is ideal for use in a UID-based access control system.
I guess what I am saying is: it doesn’t explain the problem it is solving very well. It doesn’t say what the default behavior is for other cards set as transit cards do (I would expect it to work the same way-ish) and how transit providers are supposed to match people to tickets, etc. then why this particular card is special. It assumes you know.
That whole "The solution" section does explain this.
"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.
Maybe it was updated then.
There are many card types (notably the Japanese transit cards using the Suica system) that will change their UID when moved between iOS devices.
Love seeing the Xiamen City Metro card! Would recognize the scenery from anywhere
there's not technology problem, just because Apple grant NFC privilege to Alipay and local partner in China
I don't think Alipay actually has any direct NFC access, does it?
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.
> 1. Install the AliPay app
> 2. Register inside the AliPay app
How about no.
That's obviously your choice, but if that frustrates you, make sure to ask Apple why they're making anything else so complicated.
Luckily the EU and Apple already reached an agreement for this, however it seems to be limited to payments only: https://ec.europa.eu/commission/presscorner/detail/en/ip_24_...
> 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 was really excited about the new UniFi G3 access card reader claiming support for iPhone unlock until I realized it's $5/year/device. It just seems like a slow boil into subscriptions for a company whose entire value prop is prosumer networking without the contracts.
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.
Hi, I'm the author behind the article referenced in this post.
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.
They could not implement "Home Key", because Apple requires that compatible devices are implemented as a single unit, containing reader + lock.
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.
This is amazing. :) Small world!
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!
It's SSO tax applied to hardware devices. But at the same time, it's clearly a more premium feature and if you're a business you've got the $5000/year to pay for 1000 devices. $5/device/year is not exactly expensive. Heck, I'd pay Ubiquiti $15/year for my family to be able to use it at home. That's less than I pay for almost any subscription for anything.
$5/year… this year. They will add a “No SOC2 compliance, please upgrade to our $19pm solution and benefit from 10% if you subscribe annually”.
It’s sad that we have to assume this is the agenda for all offerings that don’t allow paying current price x years in advance (possibly including adjustion for expected inflation). Leaves a very sour taste, especially in the case of hardware devices
Then you can stop using it, and you're no worse off than before when the choice wasn't even available.
> It just seems like a slow boil into subscriptions for a company whose entire value prop is prosumer networking without the contracts.
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".
Definitely, but it really irks me that part of that money goes to Apple for... what exactly?
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?
For Apple, the same thing applies. Keeping an entire zoo of operating systems safe from malicious entities requires serious work that needs to be funded somehow.
What I can’t figure out is why the old readers, which clearly read NFC cards, can’t work to read iPhones, which emit NFC.
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.
The reason why only the G3 supports Apple Wallet is exactly because of the NFC chip. Otherwise, they are completely the same hardware, and mostly the same software.
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
Thank you for the detailed answer!
Or ... maybe we should take a step back and stop trying to shove everything into phones - like drivers license or all forms of payment.
Just because you like you walk with 1000 things in your pocket doesn't mean everyone else likes it too. Stop being a luddite.
Unless you are homeless why you need so many things on you all the time?
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
Can't tell if this is sarcasm or not.
Would be cool to get into the office like this. We have RFID tags.