[Full disclosure: This blogger worked on Google Wallet 2011-2013.]
Android version 4.4 dubbed Kitkat has recently introduced a new (at least “new” for the official Android distribution) NFC feature called host-based card emulation or HCE for short. HCE is the basis for a different approach to contactless payments, a pivot away from the original strategy based on the embedded secure element. The first signs of that shift arrived earlier this summer with a curious change in the Nexus 7 hardware specs. Previous Nexus devices starting with Nexus S all contained an embedded secure element, a critical feature leveraged by Google Wallet for NFC payments. While the tablet form-factor is arguably less convenient for tapping against a point-of-sale terminal– and Wallet even ran on the larger Nexus 10 tablet– the SE was also present in the original Nexus 7 in 2012. Fast forward one year, it was conspicuously absent from the update released in July. Similarly the flagship Nexus 5 launched without an embedded secure element, becoming the first pure Google-experience phone to shed the SE.
This is unfortunate for mobile device security in general; an embedded secure element has many applications beyond NFC payments. There is a fascinating lesson in market-dynamics here: how a consortium of US wireless carriers invested in a rival payment project called ISIS successfully thwarted the deployment of an important security technology. But that is a discussion for a different time. This post will focus on the mechanics of HCE and subtle interactions from trying to coexist with embedded SE or SIM-based applications on the same device.
In card-emulation mode an NFC controller simulates the behavior of an ISO-14443 smartcard. This allows mobile devices to substitute for standalone plastic cards and dongles used in traditional security applications such as EMV payments, US government PIV card, public-transit, physical access with badge-readers and logging into a personal computer. Grossly oversimplified, that involves tunneling ISO7816 commands over NFC to some application sitting behind the controller. This is where the different hardware options come into play. An NFC controller is just a gateway; it is not a general-purpose computing environment where applications get installed. The actual “card application” lives on some other piece of hardware that is wired to the controller. For example:
- Embedded secure-element or eSE for short, typically part of the same hardware as NFC controller. This was the original approach taken with Android devices. For example Nexus S and Galaxy Nexus feature a PN65N chip from NXP Semiconductors, combining the PN544 controller coupled to a SmartMX secure execution environment.
- UICC or glorified SIM card with additional features. Single Wire Protocol (SWP) is the standard for connecting connect UICC & NFC controllers. This is the approach taken by ISIS for its mobile payment application.
- Special micro-SD cards containing a secure element. No production Android device operates in this configuration, but µSD cards such as Tyfone SideTap have certain advantages. They are easily moved between devices and they are not tied to the mobile carrier or handset manufacturer.
- Host-based card emulation. Originally implemented by SimplyTapp as a patch on top of Cyanogenmod 9, and now independently implemented by Google for Android 4.4. Incoming NFC traffic from external reader is delivered to the host operating-system which generates the response.
Direct connection and security implications
One important detail about the first three options above stands in sharp contrast to host-based card emulation. In these modes data sent/received does not travel through the host operating system. In other words, it is not the case that eSE outputs data to Android which in turn forwards that packet over to NFC controller for transmission over the air. Links to/from eSE/UICC/µSD are direct. Android never sees that traffic. This is an important security feature. Consider a payment application implemented on the eSE. Such an application communicates sensitive financial information to a point-of-sale terminal during payment transactions, including credit card numbers. If that data was routed through the host OS, malware running on the host could observe it. This property is enforced by the firmware of the NFC controller itself; it is independent of any Android-side behavior. Not even malware running with Android kernel privileges can change that.
Interestingly the converse property for incoming traffic does not hold. Before the user taps their phone against an NFC reader, host malware could have switched the NFC controller into HCE mode to gobble up data intended for the eSE. But even in this scenario a weaker guarantee holds: a given command is delivered either to the eSE or the host operating system, but not both.
Another subtlety: there is also a connection from the host the embedded secure element that allows host OS to speak ISO7816 and exchange APDUs with the SE directly. At first this appears to enable a man-in-the-middle attack executed by host applications: malware receives traffic from external reader in HCE mode, accesses the SE directly over the host-interface and forwards same command as if it were received directly over NFC radio. Incidentally this hypothetical example assumes malware has already breached Android security, and is executing with root privileges. Ordinary apps on non-rooted device are limited to the subset of operations exposed by the NFC stack. There is no permission defined to allow privileged operations such as switching controller state. Even under these generous assumptions, the attack fails for a different reason. Applications running on SE can determine whether any given command is received over the “wired” interface– connected to the host– or “contactless” interface attached to the NFC antenna. So-called interface detection logic is an integral aspect of many standards including EMV. It is critical for keeping the host operating system out of the threat model. (There is also the incidental fact that changing NFC controller mode on PN65N/O will reset the secure element, losing application state and further frustrating attempts to relay commands. But it is unwise to rely on such hardware idiosyncrasies.)