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