kormax's comments

Author of the "Osaifu-Keitai-Google-Pixel" article here.

There's a big chance that Apple does not eat the cost for Osaifu-Keitai actually, as they may have a sweet-heart deal, hinted by an article from watch.impress [1], which I found a very long time ago via Twitter.

So the fee is either waived by FeliCa networks, covered by Japanese Carriers, and (as an educated guess) paid only upon enrollment of the first FeliCa-compatible card to device.

I think it would be naive to believe that Apple, of all companies, would be the one willing to pay a couple of cents per device in order to offer a feature that, at best, only a single digit percentage of their users would use.

[1] https://www.watch.impress.co.jp/docs/series/suzukij/1297656....

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.

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

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).

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.

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.