Mobile devices and NFC in public transit (part II)

[continued from part I]

Looking at the progression of NFC hardware on Android devices:

  • Initial devices had PN65N and later PN65O chip from NXP, which combines an NFC controller with an embedded secure element. That secure element is capable of emulating Mifare Classic. (Not surprising; Mifare is an NXP design so it is not unexpected that NXP hardware could speak a proprietary NXP protocol.)
    As an example application of that feature, Google Wallet originally stored coupons on  sectors of the emulated Mifare Classic tag. These coupons were redeemed by the point-of-sale during the NFC transaction as a distinct step from the payment itself. (It’s as if two different NFC tags were presented to the reader.)
  • Later Android devices used a different chipset, combining a Broadcom NFC controller with a secure-element from STMicro running a card operating system from Oberthur. (What better demonstrates the inter-dependencies of hardware industry?)
    Surprisingly that Broadcom controller can not read Mifare tags in reader mode— this is the reason for the debacle of Samsung Tactiles and why Pay-By-Phone NFC stickers pasted on parking meters can not be read by a good chunk of Android phones. One can only assume Broadcom did not want to fork over the $$ for licensing the protocol from NXP.
    Oddly enough in card-emulation mode the Oberthur SE can emulate Mifare classic tags. But the story does not end there: due to unrelated NFC issues revealed during Android  testing, that Mifare emulation capability was disabled in firmware. So there is no Mifare emulation possible on devices such as Nexus 4 and Galaxy S4 based on the Broadcom chipset.
  • Eventually Google dropped support for the secure element altogether in favor of a plain NFC controller. On devices without SE, the story is simple: there is no Mifare emulation.

2. Reader configuration

Bottom line: none of the hardware options on the market for the past 3 years were capable of emulating DESFire or EV1 type cards used in some of the largest transit networks around the world. But this turns out not to be the final word on the problem. Going one level deeper, DESFire protocol can operate in 2 different ways: “native” mode or “standards” mode. In standard mode the protocol messages are actually compatible with ISO7816. Cards support this, which explains the existence of Android apps that can interface with a transit card and display your recent travel history and remaining balance.

That sounds like good news because SE applets and ordinary Android applications alike can act as card-emulation targets for these. For example one could write a plain JavaCard applet to run on SE, which will be activated by the turnstile to walk through the DESFire protocol. That mode may not perform very well; general-purpose SE environment lacks the hardware crypto acceleration found in a dedicated DESFire chip. (A user-mode Android application in HCE mode would be even worse due to the additional overhead involved in shuttling messages back and forth from NFC interface to the process.) But at least it is possible to use standard ISO7816 messages to communicate with the turnstile.

Except it turns out most deployed readers are configured for native mode only. That makes eminent sense from a design perspective. Transit systems have a closed architecture with both readers and cards under control of a single operator. If the cards can operate in native mode, why complicate the reader side by adding an extra, less efficient alternative? In principle the operator–which happens to be Cubic for many of these systems– could go around to every subway station, bus, ferry terminal and update readers. But it is difficult to see any compelling scenario to justify that effort at the moment.

This is the short answer to why we can not tap an Android phone to walk into BART: prevailing NFC hardware included on these devices is not capable of communicating with the turnstile. There is no intrinsic reason for this. It will change with the introduction of better hardware. Anticipating that moment, we can pose a different question. Suppose all turnstiles are magically reprogrammed to support standards mode or perhaps all future handsets are capable of full DESFire and EV1 emulation. What other challenges remain for enabling the public transit scenario?




Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s