[kormax]

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]

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]

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.