Ever since Google announced support for Host Card Emulation (HCE) on Android - banks, tech providers and NFC based mobile payment companies have left no stone un-turned. After the early enthusiasm, there are several questions that need to be answered. It’s been a while since its launch, but HCE hasn’t gained the expected number of deployments across geographies. This article highlights the the two school of thoughts about HCE. One that is overly optimistic (based on Pros) and the others who are not so optimistic (the Cons).
Quick recap before we go into Pros and Cons. “HCE” describes the on-device technology that lets a phone to perform “card emulation” on a Near Field Communication (NFC)-enabled device without relying on access to a secure element. This means that apps in an NFC phone sporting KitKat can access payment, coupon, loyalty and other credentials on a host server and use them at merchants who have NFC terminals. All of this without having to rely on secure elements, usually controlled by a mobile operator or OS maker. Let's look at the current implementations done across the world with HCE technology in this table:
Android platform issues that can affect HCE from a security standpoint
The HCE technology itself emerged in Android OS and there are some specific aspects of the mobile OS that could make HCE an issue for the mobile payment industry.
>> Android allows users to root the device. Post rooting, users get access to all the information stored in the applications on device’s OS. Now that would include sensitive information like payment credentials as well. The payment service provider would want to prevent user from such high level access because malware can also access the data.
>> Malware might be developed that could root the device. One such malware was discovered back in 2012 named RootSmart. While such a malware had targeted the older Android versions, such malwares are potential risks and not to be ignored. Android’s limited protection can be bypassed easily by rooting the device. Also it has been proven that it is difficult to fix an identified vulnerability in Android due to its long update process.
Potential Risks Associated with HCE Services
In case the handset is lost or stolen, a malicious user can access the device’s memory by connecting it to another device. A malicious user could connect to all the information stored within the application and use that to make fraudulent payments.
A robust HCE system would require the establishment of a centralized storage system for storing payment credentials and creating those one-time use credentials as well. This centralized system can become a prime target for attacks.
HCE services are required to be online and be available in real-time. Any lags in this regard could lead to loss in transactions and put greater risks on the issuers. Not all the countries are capable enough of providing high speed data networks to mobile phone users.
With HCE the phone no longer acts as the storage for payment credentials but this brings in opportunities for thefts in the following manner:
>> Through applications that may request card data stored in the HCE service
>> The communication channel gets exposed over which payment credentials are transferred to the POS terminal
How it can be a Hassle for Banks
HCE allows issuers to put credential directly into mobile applications for transactions in the physical world without third party wallets, secure elements, or TSMs. However Host Card Emulation by itself doesn’t:
>> Make sure every application that wants to use the credentials is a trusted application.
>> Authenticate users to download and use credentials from third party HCE applications.
>> Provide for testing and certifying every HCE application that uses the credential.
This means that each time a bank issuer wishes to extend their credentials to new partner applications, it will take the same amount of overhead for each new application. The bank issuing the credential will need to make sure each application manages card lifecycle, application permissions, cardholder authentication, tokens, and trust. All this takes time and resources from the issuer and its merchant and other partners, making it difficult to scale and move at a speed necessary.
But there are indeed some answers and solutions around these HCE issues that still makes it an attractive option:
Why Cloud based SE is more Viable
While some may consider the use of HCE less secure as there is no physical secure element (SE) involved, it is really a matter of perspective. Instead of storing the card data in the SE, ‘tokens’ are downloaded to the device and used to complete the transaction at the point of sale (POS). Any breach of security would expose only one or a limited amount of tokens (typically associated with a low transaction value), not the account itself. The limited gain available to hackers in return for the considerable investment of effort and time is more likely to make them put their focus on more attractive targets.
The Layered Security Options that HCE Brings
Security is important and to mitigate the risk caused by the absence of hardware security there are a number of ways in which additional security layers can be added to HCE-based mobile payments such as white box cryptography, obfuscation of programming code (security through obscurity), use of concepts such as ‘Trust Zone’ and further securing the communication channels between the device and the server such as (layered) encryption, mutual authentication and use of dual channels. The software based approach makes it easier to deploy multiple levels of security features.
With HCE, there’s No Dependency on Mobile Carriers
Mobile payment service used to rely on mobile network operators because of the secure element perspective. Traditionally, the telco issued SIM card used to act as the secure element. But with HCE, the secure element goes to the cloud and irrespective of the mobile carrier being used by the consumer, NFC based mobile payment services can be issued via HCE. This opens up the HCE opportunity to a vast consumer base across multiple geographies. Considering the case of banks, they won’t have to rely on partnerships with telecom players and lose out on revenue opportunities. Banks can simply leverage solutions of fintech companies such as Oberthur Technologies, SimplyTapp, INSIDE Secure, G&D, Sequent, Bell ID and others to integrate HCE capabilities into their banking apps.
The Device Opportunity
A major criteria for a device to support HCE is to have NFC capabilities and have Android 4.4 or above installed. Although Windows phones would also be able to incorporate HCE but that aspect would arrive with the advent of Windows 10, which is yet to be launched.
As we said in our earlier article:
Banks cannot expect partner app developers to be knowledgeable about payments industry standards and compliance, Javacard security or obscure terms like “APDU commands.” That means banks will need systems to vet and authenticate new partners and apps, platforms with easy APIs to distribute credentials to these apps securely and monitor usage of credentials by the third party apps. All of this is needed to make it easy for merchants and other partners to add bank credentials and HCE mobile payment functionality to their applications.