3 ms·

Thanks for the write-up. How does this fit into the broader NFC ecosystem? What do other big metro systems like Omny, Clipper, Smartrip etc use? Apple and Goog

by ak217 2y ago

Thanks for the write-up. How does this fit into the broader NFC ecosystem? What do other big metro systems like Omny, Clipper, Smartrip etc use? Apple and Google seem to implement some NFC protocols in their devices but in a much more programmable way, how does that work? Is the protocol used in credit cards related at all? And how do these relate to Felica, the system used everywhere in Japan (which was in the news for a while because the factory where they made the chips burned down and they had a chip shortage - giving Apple an opening to move into the market with iPhone NFC)?

kens 2y ago
That seems like a question for @lxgr :-) As far as I can tell, the NFC ecosystem is a mess of competing, incompatible protocols from different companies, as well as incompatibilities for historical reasons. For example, Clipper uses MIFARE DESFire, which is the more secure sibling of the Ultralight chip that I examined. Washington's SmarTrip cards use MIFARE Plux X. New York City's OMNY, on the other hand, is apparently built on top of the Mastercard payment network using EMV. Montreal's rechargeable OPUS card (not the disposable one I examined) uses the completely different Calypso standard. FeliCa was developed in Japan along a different path and has a different standard (NFC-F vs NFC-A) with different modulation, protocol, and data rates. The NFC chips used in phones try to be compatible with as much as possible. These NFC systems all use the same 13.56 MHz frequency, so the radio hardware is compatible across them.
- Tijdreiziger 2y ago
  How and why did you learn about this topic? :)
- lxgr 2y ago
  On it, but I couldn't have said it better :) To expand on Felica vs. ISO a bit: Theoretically Felica is a different stack from ISO 14443, but it's close enough that it almost got specified as a variant of ISO 14443 as well (C; MIFARE and most other systems use A). NFC does specify Felica as one possible official tag type (then called NFC-F, as opposed to NFC-A and NFC-B), so practically, most mobile devices can just also read it. For anybody wanting to experiment a bit, I can highly recommend getting any Android device and installing NFC tag reader by NXP; it'll show you what technology exactly a given card uses, and in some cases can show you other interesting information as well. There's also an app that lets you read the current balance of various transit cards.
Tijdreiziger 2y ago
> Is the protocol used in credit cards related at all? In e.g. London and the Netherlands, the readers were upgraded to support tapping in and out with a debit/credit card or Apple/Google Pay. However, Apple also seems to have an ‘Express’ mode, which even works when the battery is empty (‘Power Reserve’). It seems to me that there must be three protocols: the one for the disposable and stored-value tickets (ISO 14443?), EMV for debit/credit/Apple Pay/Google Pay, and Apple Pay Express.
- lmz 2y ago
  EMV (specifically EMV contactless) is also based on ISO 14443, it's more like an application layer protocol on top of it. Apple Pay Express is just Apple Pay without the need for the full system UI: "If iOS isn’t in use because iPhone needs to be charged, there may still be enough power in the battery to support Express Card transactions." it interacts the same way as the physical card equivalent (otherwise they would need a reader upgrade).
  - MBCook 2y ago
    Right. Much like the fact Find My functionality can still let you track your phone when it’s “dead”, the power requirements are just so low that when the phone can’t get going due to the requirements of the CPU + RAM + display there’s plenty to power NFC/BT beacon stuff for a while. An AirTag can operate on a CR2032 for two years. An Energizer datasheet says that’s 235 mAh. An iPhone 13 Mini has a 2438 mAh battery (~10x). It makes sense the phone could do it for at least a day or two with the left over charge. (I don’t know how long it would actually keep working)
  - lxgr 2y ago
    Both EMV and MIFARE (and similar solutions) indeed sit on top of ISO 14443-4 (or -3 for the older/lighter MIFARE versions), but they're conceptually very different: EMV is an account-based payments protocol, and the card only confirms its presence in a transaction; balances are managed on the backend. The reader does not authenticate itself to the card at all. MIFARE is a stored-value service and as such keeps track of the card's balance on-chip. This requires another smartcard on the reader side, holding the necessary keys for mutual authentication, but allows two-sided offline transactions, which is quite useful for transit applications (e.g. buses dropping out of network coverage, allowing higher volumes even during short server outages etc.)
lxgr 2y ago
Apple and Google achieve the same outcome (i.e. something called "card emulation", where an NFC chip can act as an emulated ISO 14443-4 smartcard), but they achieve it through very different ways: Google just has an Android API for it called HCE (Host Card Emulation), and anybody can write an app that implements it (i.e. Google Pay has no special position compared to competitors). In a nutshell, you just get a callback for every APDU (protocol message) the phone receives from the reader and get to respond as you wish. Apple embeds a secure element in their devices, which is a chip almost identical to that you'll find in actual physical cards, but with an additional interface that connects it to the application processor, so that the OS and (privileged, i.e. Apple Wallet only) apps can interface with it and load new card applications. That's why the storage in Apple Wallet is limited to 50-ish cards, but Google Pay allows many more :) Felica is not part of the ISO 14443 family, but closely related and also an official physical layer of NFC (NFC-F), so many devices practically support it as well. To my knowledge, there is no software-based emulation for it though (that's always a bit risky for stored-value cards), so Suica etc. only work on Japanese phone models that have the necessary secure element, as well as on all iPhones (Apple installs a Felica applet into their secure element on demand).
- abhayhegde 2y ago
  Is it possible that the Android implementation could be less secure given the lack of a dedicated secure element? Perhaps not, but I am curious why Apple does it that way.
  - lxgr 2y ago
    It's definitely less secure for issuers: The entire point of having a secure element is that the issuers of digital wallet cards and passes can't trust all of their users to not decompile their app and extract a private key that grants fraudsters infinite money or transit rides. Physical cards and secure elements on the other hand are resistant against key extraction even in an adversarial environment. There are ways to mitigate that in software (e.g. by not ever loading long-lived keys into software, fetching them just in time after device attestation etc.), but while that works pretty well for the kind of payments where the terminal needs to be online anyway, it's very risky for offline transactions. That's why Suica and most other stored-value passes only support iPhones and a handful of specific Android devices that have a secure element (or can use the SIM card as one).

by ak217 2y ago

kens 2y ago

That seems like a question for @lxgr :-) As far as I can tell, the NFC ecosystem is a mess of competing, incompatible protocols from different companies, as well as incompatibilities for historical reasons. For example, Clipper uses MIFARE DESFire, which is the more secure sibling of the Ultralight chip that I examined. Washington's SmarTrip cards use MIFARE Plux X. New York City's OMNY, on the other hand, is apparently built on top of the Mastercard payment network using EMV. Montreal's rechargeable OPUS card (not the disposable one I examined) uses the completely different Calypso standard. FeliCa was developed in Japan along a different path and has a different standard (NFC-F vs NFC-A) with different modulation, protocol, and data rates. The NFC chips used in phones try to be compatible with as much as possible. These NFC systems all use the same 13.56 MHz frequency, so the radio hardware is compatible across them.

Tijdreiziger 2y ago
How and why did you learn about this topic? :)
lxgr 2y ago
On it, but I couldn't have said it better :) To expand on Felica vs. ISO a bit: Theoretically Felica is a different stack from ISO 14443, but it's close enough that it almost got specified as a variant of ISO 14443 as well (C; MIFARE and most other systems use A). NFC does specify Felica as one possible official tag type (then called NFC-F, as opposed to NFC-A and NFC-B), so practically, most mobile devices can just also read it. For anybody wanting to experiment a bit, I can highly recommend getting any Android device and installing NFC tag reader by NXP; it'll show you what technology exactly a given card uses, and in some cases can show you other interesting information as well. There's also an app that lets you read the current balance of various transit cards.

Tijdreiziger 2y ago

> Is the protocol used in credit cards related at all? In e.g. London and the Netherlands, the readers were upgraded to support tapping in and out with a debit/credit card or Apple/Google Pay. However, Apple also seems to have an ‘Express’ mode, which even works when the battery is empty (‘Power Reserve’). It seems to me that there must be three protocols: the one for the disposable and stored-value tickets (ISO 14443?), EMV for debit/credit/Apple Pay/Google Pay, and Apple Pay Express.

lmz 2y ago
EMV (specifically EMV contactless) is also based on ISO 14443, it's more like an application layer protocol on top of it. Apple Pay Express is just Apple Pay without the need for the full system UI: "If iOS isn’t in use because iPhone needs to be charged, there may still be enough power in the battery to support Express Card transactions." it interacts the same way as the physical card equivalent (otherwise they would need a reader upgrade).
- MBCook 2y ago
  Right. Much like the fact Find My functionality can still let you track your phone when it’s “dead”, the power requirements are just so low that when the phone can’t get going due to the requirements of the CPU + RAM + display there’s plenty to power NFC/BT beacon stuff for a while. An AirTag can operate on a CR2032 for two years. An Energizer datasheet says that’s 235 mAh. An iPhone 13 Mini has a 2438 mAh battery (~10x). It makes sense the phone could do it for at least a day or two with the left over charge. (I don’t know how long it would actually keep working)
- lxgr 2y ago
  Both EMV and MIFARE (and similar solutions) indeed sit on top of ISO 14443-4 (or -3 for the older/lighter MIFARE versions), but they're conceptually very different: EMV is an account-based payments protocol, and the card only confirms its presence in a transaction; balances are managed on the backend. The reader does not authenticate itself to the card at all. MIFARE is a stored-value service and as such keeps track of the card's balance on-chip. This requires another smartcard on the reader side, holding the necessary keys for mutual authentication, but allows two-sided offline transactions, which is quite useful for transit applications (e.g. buses dropping out of network coverage, allowing higher volumes even during short server outages etc.)

lxgr 2y ago

Apple and Google achieve the same outcome (i.e. something called "card emulation", where an NFC chip can act as an emulated ISO 14443-4 smartcard), but they achieve it through very different ways: Google just has an Android API for it called HCE (Host Card Emulation), and anybody can write an app that implements it (i.e. Google Pay has no special position compared to competitors). In a nutshell, you just get a callback for every APDU (protocol message) the phone receives from the reader and get to respond as you wish. Apple embeds a secure element in their devices, which is a chip almost identical to that you'll find in actual physical cards, but with an additional interface that connects it to the application processor, so that the OS and (privileged, i.e. Apple Wallet only) apps can interface with it and load new card applications. That's why the storage in Apple Wallet is limited to 50-ish cards, but Google Pay allows many more :) Felica is not part of the ISO 14443 family, but closely related and also an official physical layer of NFC (NFC-F), so many devices practically support it as well. To my knowledge, there is no software-based emulation for it though (that's always a bit risky for stored-value cards), so Suica etc. only work on Japanese phone models that have the necessary secure element, as well as on all iPhones (Apple installs a Felica applet into their secure element on demand).

abhayhegde 2y ago
Is it possible that the Android implementation could be less secure given the lack of a dedicated secure element? Perhaps not, but I am curious why Apple does it that way.
- lxgr 2y ago
  It's definitely less secure for issuers: The entire point of having a secure element is that the issuers of digital wallet cards and passes can't trust all of their users to not decompile their app and extract a private key that grants fraudsters infinite money or transit rides. Physical cards and secure elements on the other hand are resistant against key extraction even in an adversarial environment. There are ways to mitigate that in software (e.g. by not ever loading long-lived keys into software, fetching them just in time after device attestation etc.), but while that works pretty well for the kind of payments where the terminal needs to be online anyway, it's very risky for offline transactions. That's why Suica and most other stored-value passes only support iPhones and a handful of specific Android devices that have a secure element (or can use the SIM card as one).