Hacker News Reader

Comment by ak217 | Hacker News Reader

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

View on HN

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.

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.

How and why did you learn about this topic? :)

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

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.

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

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

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

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

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

MIFARE cards are used in all kinds of applications and not all of them require the reader to authenticate itself. And even in authenticated uses the keys don't neccessarily need to be stored in a smartcard (SAM) depending on the security requirements. For the simpler MIFARE cards a secure enclave for the keys doesn't even provide any additional security since they key is transmitted to the card anyway - and the simplest ones don't have any authentication at all.

> a secure enclave for the keys doesn't even provide any additional security since they key is transmitted to the card anyway

I'd assume that the keys (more accurately passwords, since a key would never be transmitted to the card over an unencrypted interface) are diversified by card serial number though? In that case, it would still be useful to have an SAM to hold that diversification key. You could further store some MAC authentication tag on the password-protected tag that the SAM needs to see before revealing the password over the radio.

I'm not saying that this is how every transit system practically does use MIFARE Ultralight, but based on the design, it's definitely possible.

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)

Reply on news.ycombinator.com