[HN Gopher] Using your Apple device as an access card in unsuppo...
___________________________________________________________________
Using your Apple device as an access card in unsupported systems
Author : ValentineC
Score : 228 points
Date : 2025-01-19 18:01 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| agos wrote:
| this is cool but the limitations make it almost unusable
| pockmarked19 wrote:
| Seriously. Better to tape something to your phone at that
| point!
| sgt wrote:
| Would be cool to get into the office like this. We have RFID
| tags.
| akersten wrote:
| 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.
| ShakataGaNai wrote:
| 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.
| eastbound wrote:
| $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".
| WanderPanda wrote:
| 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
| dymk wrote:
| Then you can stop using it, and you're no worse off than
| before when the choice wasn't even available.
| kormax wrote:
| 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.
| kormax wrote:
| 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.
| ValentineC wrote:
| 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!
| jtbayly wrote:
| 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.
| kormax wrote:
| 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
| jtbayly wrote:
| Thank you for the detailed answer!
| mschuster91 wrote:
| > 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".
| lxgr wrote:
| 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?
| mschuster91 wrote:
| 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_.
| ShakataGaNai wrote:
| 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.
| talldayo wrote:
| 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...
| moritzwarhier wrote:
| It's understandable in the context of Apple Pay I think.
| int0x29 wrote:
| Google pay coexists with an open NFC API on the same
| devices and has since before IOS had NFC support
| moritzwarhier wrote:
| Point taken
| ValentineC wrote:
| 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.
| lxgr wrote:
| 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.
| dijit wrote:
| 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.
| hmottestad wrote:
| 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-...
| jclulow wrote:
| 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.
| IgorPartola wrote:
| > 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.
| int0x29 wrote:
| 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.
| talldayo wrote:
| > 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.
| seec wrote:
| 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.
| lxgr wrote:
| > 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.
| eptcyka wrote:
| Yeah, NFC truly is the hot path to the majority of CVEs on
| Android, right?
| Terretta wrote:
| To not get eaten by a bear, you only have to be quicker
| than the slowest camper.
| dmurray wrote:
| > 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.
| plagiarist wrote:
| 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.
| avianlyric wrote:
| 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-...
| talldayo wrote:
| > 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.
| lxgr wrote:
| > 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.
| Spooky23 wrote:
| Apple is held to a higher standard. It's a feature of
| their model, as they are clearly accountable for the full
| stack.
| lxgr wrote:
| 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.
| Spooky23 wrote:
| In the press, absolutely.
|
| You're thinking about reality. Unfortunately, perception
| makes the world go round.
| diggan wrote:
| > 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.
| lxgr wrote:
| 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.)
| dcrazy wrote:
| The article is 2 years old, and predates any of the iOS 18.1
| changes.
| lxgr wrote:
| 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/
| diggan wrote:
| > 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?
| thibaut_barrere wrote:
| A bit less innovation-ish but with large concrete impacts
| https://commission.europa.eu/news/eu-common-charger-rules-
| po...
| diggan wrote:
| 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.
| withinboredom wrote:
| Does this work with ANY card set as the transit card in iOS? Or
| just this one type of transit card?
| noja wrote:
| Your question is answered in the article.
| withinboredom wrote:
| 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.
| mbilker wrote:
| Yes, it does explain it. 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.
|
| https://github.com/kormax/apple-device-as-access-
| card?tab=re...
| dymk wrote:
| That's explaining some specific technical properties of
| how this particular NFC card works, it not explaining
| what the implications of that are.
| withinboredom wrote:
| 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.
| mbilker wrote:
| There are many card types (notably the Japanese transit cards
| using the Suica system) that will change their UID when moved
| between iOS devices.
| rubatuga wrote:
| Or ... maybe we should take a step back and stop trying to shove
| everything into phones - like drivers license or all forms of
| payment.
| CrimsonRain wrote:
| Just because you like you walk with 1000 things in your pocket
| doesn't mean everyone else likes it too. Stop being a luddite.
| rubatuga wrote:
| Can't tell if this is sarcasm or not.
| throwaway290 wrote:
| 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
| jtbayly wrote:
| 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.
| hmottestad wrote:
| 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.
| avianlyric wrote:
| > 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.
| lxgr wrote:
| > 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).
| arghwhat wrote:
| > 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: htt
| ps://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.
| lxgr wrote:
| > 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.
| arghwhat wrote:
| > 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.
| arghwhat wrote:
| > 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.
| formerly_proven wrote:
| 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.
| lxgr wrote:
| > 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.
| data_ders wrote:
| Love seeing the Xiamen City Metro card! Would recognize the
| scenery from anywhere
| Havoc wrote:
| 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?
| atonse wrote:
| Given the UID is the same every time, I can assume it's to make
| surveillance easier?
| simondotau wrote:
| 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.
| lxgr wrote:
| 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.
| simondotau wrote:
| 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.
| lxgr wrote:
| 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.
| lxgr wrote:
| 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).
| gruez wrote:
| It's China. They can just tell the transit agency to pull up
| transaction records, no backfired system required.
| kormax wrote:
| 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).
| lxgr wrote:
| 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.
| kormax wrote:
| 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.
| amyames wrote:
| 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?
| londons_explore wrote:
| 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
| yencabulator wrote:
| 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
| lxgr wrote:
| 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).
| lxgr wrote:
| 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.
| behnamoh wrote:
| > 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).
| cluckindan wrote:
| > 1. Install the AliPay app
|
| > 2. Register inside the AliPay app
|
| How about no.
| lxgr wrote:
| That's obviously your choice, but if that frustrates you, make
| sure to ask Apple why they're making anything else so
| complicated.
| sureIy wrote:
| 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."
| chuanliang wrote:
| there's not technology problem, just because Apple grant NFC
| privilege to Alipay and local partner in China
| lxgr wrote:
| 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.
| dcrazy wrote:
| 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/
| rsanek wrote:
| should have a (2023) tag based on commits
| jonasmalaco wrote:
| 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.
___________________________________________________________________
(page generated 2025-01-20 23:03 UTC)