Is HCE an enemy of NFC?

In recent months, since Google has announced the support for Host Card Emulation (HCE) in their latest Android 4.4 KitKat, we have seen a barage of articles and analyses (some in very reputable publications and blog sites) claiming that NFC is dead with the introduction and arrival of Google's now famous HCE.

It is not new nor the first time that analysts and journalists who write about payment industry developments make mistakes or inaccurate statements. They are not engineers nor they neccessarily understand how things work, especially when faced with relatively sophisticated technology systems like NFC based payments. Sometimes they make them intentionally in order to sound provocative. However I always believed and hoped that a serious analyst or journalist would do a deeper research before writting and publishing an article about sophisticated piece of technology, but hey we can't expect perfection from everybody. Now as an engineer by training, instead of just sitting and whining about the innacuracies inside these industry 'prophecies' and predictions, I decided to take little time from my own daily job and try to present how the HCE relates to NFC, purely based on technology facts.

Many of us already deeply involved in EMV payments and mobile wallets, knew that HCE technology is not new - first and foremost, it is not even Google's invention. BlackBerry has supported HCE in their devices for a long time before Google decided to make it available. The problem is that BlackBerries are getting close to extinction in well developed markets like Europe, North America, Japan, Australia, etc, so HCE was considered mainly irrelevant while available only on BlackBerry OS. Sorry my fellow countrymen Canadians - even here our beloved and celebrated BBerries are rapidly being phased out ;-) since they are being replaces with smartphones loaded with Android and iOS.

HCE technology is also not anti-NFC. On the contrary it is as much pro-NFC as anything NFC related so far, since it represents the significant (although initially missing) part of the whole NFC puzzle and ecosystem.

The Beginning
"In the beginning God created the Card Emulation (CE) NFC ..."
Before the HCE was introduced / rolled out, the developers of the mobile payment applications had to have access to the phone Secure Element (SE) in order to be able to deploy their NFC based payment solutions / mobile wallets. In other words they were forced to load their mobile payment payment applications (i.e. EMV based contactless payment applet code mainly) directly into the phone SE. Why? Because the NFC controller in the phone was directly wired to the mobile phone SE via something called 'Single Wire Protocol' (SWP).

The only way the messages along the 'logical chain' 

Mobile Payment Application <--> NFC Controller <---> POS Contactless Reader

could be exchanged during payment transaction was via SWP. Since SWP physically hard wired NFC controller directly to the phone SE, any mobile payment application had to reside INSIDE that SE. The technology solution was forced to look like this

Mobile Payment Application (in phone SE) <--- SWP ---> NFC Controller <---> POS Contactless Reader

This is indeed the cleanest and the most secure way to execute mobile payments at POS since it doesn't involve mobile phone main CPU. As such it clearly eliminates any application code running in the phone OS (and OS itself) interfering with the NFC based mobile payment message exchange. No phone malware, no viruses can embed themselves in-between and spy on anything flowing along this chain. It genuinely emulates the plastic contactless chip card interacting directly with the POS contactless reader without anything from the mobile phone in between. That is why this mode of NFC payments is called the Card Emulation (CE). Some even went so far and rebranded SWP as 'Secure Wire Protocol'.

Most ubiquitous SE available today in the mobile phones is the SIM card, and therefore it looked as a natural choice NFC CE payments. SIM is already in the phone, it is a standardized smart card itself and in NFC compatible phones it was already 'SWP-ed' to the NFC controller. But the problem was that the access to the SIM card is heavily controlled and guarded by the Mobile Network Operators (MNO) who issued it in the first place. It already has all of the sensitive GSM related mobile telephony code and cryptographic data loaded in it, so loading another sensitive piece of application aimed at executing mobile payments required great care and gatekeeping. On top of the need for control that was required for loading additional applications into SIM, the MNOs as the legitimate 'owners' of the SIM, naturally wanted to monetize the control they had and charge payment issuers for the real estate inside SIM required for the payment applications (or some MNOs wanted piece of the transaction fee revenue)

Some of the MNOs also started having plans of becoming fully fledged mobile payment solution / wallet providers on their own and simply didn't allow schemes, banks and payment providers loading their payment applications into the SIM at all.

Although this whole saga is of course much more complex when looked at holistically from the business modeling prospective you realize what the main issue was ... Due to the very complex and undefined business relationships between MNOs and payment schemes / payment application issuers, the Card Emulation (CE) based NFC deployments were very complex logistically. It also threatened to make costs of executing contactless transactions when using mobile phone, visibly more expensive than when consumers use their plastic contactless chip cards - simply because there was one more player in the game who needed to be fed from the payment transaction revenues.

"... And then God said,'Let there be Host Card Emulation (HCE) NFC'"
Introduction of Host Card Emulation (HCE) on Android platform is certainly significant news which can not and should not be ignored, because it makes at least theoretically possible to implement NFC based payment solution without need to have access to the phone's Secure Element (SE). In HCE solution there is no requirement anymore for SWP. Basically now any application which uses Google Android HCE API framework / API can go around the SWP-SE and communicate directly with the NFC Controller and therefore has an open path toward the POS contactless reader. With HCE we are back to the original logical picture

HCE enabled Mobile Payment Application <--> NFC Controller <---> POS Contactless Reader

Since NFC Controller is still involved in the mobile payment flow, this is still pretty much NFC payment, at least from the POS prospective, just without SE involvement. Dependence on MNOs is out of the picture now. Great freedom for the payment application issuers and mobile payment solution providers. Definitely great news and impetus for innovation ... at least in theory. Why? Because SWP-SE had its clear role - as already stated earlier in the text, it fully eliminated involvement of the mobile phone main CPU and any application running on it from interfering with the NFC payment process. It completely freed the mobile payment application developers from worrying about vulnerabilities of the mobile phone OS platforms and holes in their security models. For mobile payment application developers life was easy, but for business people inside payment schemes and banks it was a nightmare scenario.

With HCE comes freedom from MNOs, but it obviously has its price. It manifests itself in relaxed security model for the NFC mobile payments. HCE enabled Mobile Payment Application now runs on the main phone CPU. If present in the same phone, malware, spyware and viruses also run on the same phone CPU. Theoretically those 'intruder' applications can spy on the traffic between the NFC Controller and the HCE enabled Mobile Payment Application. Rooted  / jail-broken phones are especially vulnerable here. Even in non-rooted phones the only protection such phone OS provides to the HCE enabled application is the native OS 'sandbox' which is not as secure as it should be. Clearly now we have onus on mobile payment application developers to protect such code from any potential for 'theft' of the payment credentials and reusing those for illegitimate payments later.

Of course there are techniques to mitigate these newly exposed security risks in order to minimize impact and dangers of any spyware, malware involvement in and spying to the NFC traffic. Mobile payment technology solution providers may decide to store main payment credentials (including all sensitive payment related cryptographic keys and card data like PAN, Expiry Date, etc) in the secure cloud / server based Hardware Secure Module (HSM). Then provision the HCE enabled Mobile Payment App on-demand (when required - for example just in advance of the payment transaction) with 'temporary' PAN, 'temporary' Expiry Date, 'temporary' 'session based' cryptographic keys, etc. This provisioning will have to happen via 'over the air' (OTA) - using secure channel established between secure cloud and Mobile Payment Application (using SSL for example, or similar technique)

Basically the HCE enabled Mobile Payment Application has everything the real card needs for the execution of the standard contactless transaction with the POS - just made temporary and short lived. That way even if there is malware and spyware embedded along the contactless transaction payment chain, those 'intruder' programs would obtain the info which will become useless / expired either immediately or very soon after the transaction has been already completed. Please note that 'temporary' here can be fine tuned depending on the risk tolerance - in open loop systems probably it is prudent to make it valid for 1 transaction only, but in potentially less risky closed loop solutions it may be time based - let say several minutes up to couple of hours.

Hopefully you get the picture ... SE based NFC payment solutions (based on CE model) are shielded from the vulnerabilities of the mobile phone OS platforms since they depend on hardware SE and SWP. As such they are as secure as the contactless plastic card payments. But they are heavily policed by the MNOs and have complex deployment logistics, business models and incurred additional transaction processing costs

On the other hand, the HCE based NFC payment solutions are definitely exposed to all of the vulnerabilities of the mobile phone OS platforms, and the developers of such solution have to minimize those risks by combination of the server based SE and 'temporarization' of the payment credentials inside the HCE enabled Mobile Payment Application. However they are much more flexible to deploy, eliminate the MNO influence.

There you go. Time will tell whether either of these two NFC payment models will be adopted on a larger scale, but one is clear ... so far there is no more elegant way to pay at the POS by using the mobile phone than NFC (CE or HCE based) - it looks like a contactless card, feels like a contactless card payment and deeply inside ... it is ISO 14443 contactless card payment, just disguised in the mobile phone. All other mobile payment solutions (QR code based comes to mind) are clumsier and much slower than NFC based payments. In the end it will probably come down to the consumers deciding whether they see any value in abandoning their plastic cards in favor of the plastic card with the screen (i.e. mobile phone)