This post is in response to the recent Bankinter story of NFC payments at the point-of-sale without requiring SE – and the lack of any real detail around how it plans to achieve that goal. I am not privy to Bankinter’s plan to dis-intermediate the SE, but as I know a wee bit about how NFC works, I thought a post would help in clearing up any ambiguity as to how Card emulation and Host Card emulation differs, upsides, challenges – the whole lot.
Back in December of 2012, Verizon responded to an FCC complaint over its continued blocking of GoogleWallet on Verizon network. The gist of Verizon’s response was that as GoogleWallet is different to PayPal, Square and other wallet aggregators in that its reliance on the phone’s Secure Element – a piece of proprietary hardware, lies behind the reason for Verizon denying GoogleWallet from operating on its devices or network. Verizon continued to write that Google is free to offer a modified version of GoogleWallet that does not require integration with the Secure Element.
Now Software Card Emulation was not born out of that gridlock. It had been always supported by both NXP and Broadcom chipsets at the driver level. Among operating systems, BlackberryOS supports it by default. With Android however, application support did not manifest despite interest from the developer community. Google chose to omit exposing this capability via the API from Android 2.3.4 – may have to do with opting to focus its developer efforts elsewhere, or may have been due to carrier intervention. What very few knew is that a startup called SimplyTapp had already been toiling away at turning the switch back on – since late 2011.
Host Card What?
But first – let’s talk a bit about Card Emulation and how Host Card Emulation (or SE on the Cloud) differs in their approach. In the case of GoogleWallet, Card Emulation represents routing communication from an external contactless terminal reader directly to the embedded secure element, dis-allowing visibility by the operating system completely. Only the secure element and the NFC controller are involved. Card Emulation is supported by all merchant contactless terminals and in this mode, the phone appears to the reader as a contactless smart card. Google Wallet, Isis and other NFC mobile wallets rely on card emulation to transfer payment credentials to the PoS. However the downsides to this are payment apps are limited to the SE capacity (72kb on the original embedded SE on Nexus S), SE access is slower, and provisioning credentials to the SE is a complex, brittle process involving multiple TSM’s, multiple Carriers (in the case of Isis) and multiple SE types and handsets.
Host Card Emulation (or Software Card Emulation) differs from this such that instead of routing communications received by the NFC controller to the secure element, it delivers them to the NFC service manager – allowing the commands to be processed by applications installed on the phone. With that, the approach allows to break dependency on the secure element by having credentials stored anywhere – in the application memory, in the trusted execution environment (TEE) or on the cloud.
The benefits are apparent and a couple is noted:
- NFC returns to being a communication standard, enabling any wallet to use it to communicate to a PoS – without having to get mired down in contracts with Issuers, Carriers and TSMs.
- No more complex SE cards provisioning to worry about
- Multiple NFC payment wallets can be on the phone without worrying about SE storage size or compartmentalizing.
- No need to pay the piper – in this case, the Carrier for Over-the-air SE provisioning and lifecycle management. Card Issuers would be ecstatic.
However this is no panacea, as software card emulation is not exposed to applications by Android and host card emulation patches that have been submitted (by SimplyTapp) have not yet been merged with the main android branch – and therefore not available to you and I – unless we root our phones.
Which is where SimplyTapp comes in.
SimplyTapp appealed to an early segment of Android enthusiasts who abhorred having been told as to what functionality they are allowed to enable on their phones – by Google, Carriers or anyone else. And to any who dared to root an NFC phone (supported by CyanogenMod) and install the Cyanogenmod firmware, they were rewarded by being able to use both SimplyTapp as well as GoogleWallet to pay via NFC – the former where credentials were stored on the cloud and the latter – within the embedded SE.
So how does this work? SimplyTapp created a Host Card Emulation patch which resolves potential conflicts that could arise from having two competing applications (SimplyTapp and GW) that has registered for the same NFC event from the contactless external reader. It does so by ensuring that upon receiving the event – if the SimplyTapp app is open in the foreground (On-Screen) then the communication is routed to it and if not – it gets routed to GoogleWallet. This allows consumers to use both apps harmoniously on the same phone (take that ISIS and Google Wallet!). SimplyTapp today works on any NFC phone supported by CyanogenMod. Apart from SimplyTapp, InsideSecure is working on a similar initiative as reported here.
You get a wallet! And you get a wallet! Everyone gets a wallet!
Well not quite. What are the downsides to this approach? Well for one – if you wish to scale beyond the enthusiasts, you need Google, the platform owner to step up and make it available to all without having to root our phones. For that to happen it must update the NFC service manager to expose Host Card emulation for the NXP and Broadcom chipsets. And if Google is not onboard with the idea, then you need to find an OEM, a Handset manufacturer or an Amazon ready to distribute your amended libraries. Further, you can also expect Carriers to fight this move as it finds its investment and control around the secure element threatened. With the marked clout they enjoy with the OEM’s and Handset manufacturers by way of subsidies, they can influence the outcome.
Some wonder how is it that BlackberryOS continues to support Host Card Emulation without Carrier intervention. The short answer may be that it is such a marginal player these days that this was overlooked or ignored.
The limitations do not stop there. The process of using any cloud based credentials in an EMV or contactless transaction has not been certified yet. There is obviously interest and it probably will happen at some point – but nothing yet. Debit cards may come first – owing to the ease in certification. Further, Closed loop cards may probably be ahead of the curve compared to Open loop cards. More about that later. *Update: Latency is another issue when the credentials are stored on the cloud. Especially when NFC payments were called out last year to be not quick enough for transit.*
So for all those who pine for the death of secure elements, but swear fealty to NFC, there is hope. But don’t set your alarm yet.
So what will Google do?
Let’s consider for a moment that Google is down with this. If so, does that represent a fork in the road for Google Wallet? Will the wallet application leverage HCE on phones with inaccessible Secure Elements, while defaulting to the Secure Element on phones it has? If so, it risks confusing consumers. Further – enabling HCE lets other wallets to adopt the same route. It will break dependency with the secure element, but so shall it open the flood gates to all other wallets who now wants to play. It would seem like a pyrrhic victory for Google. All those who despised proximity payments (I am looking at you Paypal & Square!) will see their road to contactless clear and come calling. As the platform owner – Google will have no choice but to grin and bear it. But on a positive note, this will further level the playing field for all wallets and put the case for contactless back – front and center. Will Google let this happen? Those who look at Google’s history of tight fisted control over the embedded SE are bound to cite precedent and stay cynical.
But when it comes down it, I believe Google will do the right thing for the broader android community. Even on the aspect of not relinquishing control over the embedded SE in the devices it issued, Google had put the interests of consumer first. And it felt that, after all things considered it felt it was not ready to allow wanton and unfettered access to the SE. Google had at one point was even talking about allowing developers write their own “card emulation” applets and download them to the SE.
Broadcom also has an upcoming quad-combo chip BCM43341 that has managed to wrap NFC, Bluetooth 4.0, Wi-Fi and FM Radio, all on a single die. Further, the BCM43341 also supports multiple Secure Elements. Now, I also hear Broadcom happens to be a major chip supplier to a fruit company.
What do you think?
This is content was originally posted to Cherian's personal blog at DropLabs.
