|
|
|
|
|
|
by lxgr
515 days ago
|
|
|
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.