As described in earlier posts, Android 4.4 “Kitkat” has introduced host-based card emulation or HCE for NFC as a platform feature, opening this functionality up to third-party developers in ways that were not quite possible with the embedded secure element. In tandem with the platform API change, Nexus 5 launched without an embedded secure element, ending a run going back to the Nexus S where the hardware spec included that chip coupled to the NFC controller. Google Wallet was one of the first applications to migrate from using the eSE to HCE for its NFC use case, namely contactless payments.
An earlier four-part series compared HCE and hardware secure elements from a functional perspective, concluding that the current Android implementation is close (but not 100%) to feature parity with previous architecture when card-emulation route points to the eSE. The next set of posts will focus on security, looking at what additional risks are introduced by using HCE instead of dedicated hardware coupled to the NFC controller.
Another way to phrase this question: what did embedded SE buy in terms of security and what was lost when Android gave up on the SE due to opposition from wireless carriers? Can HCE achieve similar level of security assurance or are there scenarios inherently depending on special hardware incorporated into the device, regardless of its form factor as eSE, UICC or micro-SD?
Broadly speaking, there are 4 significant benefits ranging from the obvious to more subtle:
- Physical tamper resistance
- Reduced attack surface
- Taking Android out of the trusted computing base (TCB)
- Interface separation
Each of the following posts will tackle one of these aspects.