Is Host Card Emulation (HCE) the big enabler for Mobile Contactless Payments? - December 2015
An SPA Position
Host Card Emulation (HCE) simplifies Near Field Communication (NFC) implementation by eliminating the requirement of a Secure Element (SE) to store mobile payment applications. But HCE also increases the threat for payment credentials to be captured in the mobile device with the subsequent risk of payment fraud.
In this paper, SPA discusses some of the most significant issues related to the security, roll-out and management of payment applications using HCE, and offers recommendations to move forward with a competitive market for mobile contactless payments using both SE and HCE.
This paper does not intend to provide a detailed technical analysis on HCE security.
pdf 15-12-16 PP Position SPA Final.pdf (201 KB)
The following definitions apply in this document:
Mobile Device refers to mobile phones and smartphones equipped with an NFC controller and host payment applications using either one or more SE, or HCE functionality, or both.
We refer to Android OS mobile devices, because HCE is the NFC functionality of the Android OS.
Secure Element (SE) refers to a chip emulating a card in a mobile device and accessed using the NFC mobile controller.
The Secure Element is isolated from the mobile operating system and hardware, and therefore provides the security features of a certified smart card to a mobile device: secure storage, an isolated and secure execution environment, and hardware-based cryptography. The SE also stores cryptographic keys and execute protocols for the remote management of the mobile payment application.
Card Emulation (HCE) refers to a software module embedded in a mobile device emulating a card and accessed using the NFC mobile controller. The HCE is not a secure environment, meaning that other applications resident in the mobile device, malicious or not, may compromise the integrity of payment applications. To mitigate this risk, specific security mechanisms are required. They are discussed hereafter.
An electronic payment transaction is the result of the generation, transmission and verification of a pre-defined series of messages – each conveying specific sensitive data that needs to be protected.
Naturally, the security and effectiveness of such transactions have benefited significantly from the IT revolution of the past three decades and the continuous optimization of the algorithms that represent, encode, store, access and transmit digital data. Similarly, developments in the security of computing devices, telecommunication networks and database facilities have likewise had a positive impact on the processing of this sensitive payment data – with smartphones increasingly the access devices to a vast array of mobile financial services.
It is assumed that to succeed, a new payment instrument must be easy to use, low cost, accepted everywhere, be trusted by the user and backed by a sustainable business model. Trust here is key, and requires that the chosen payment instrument not only be secure, but be perceived as being secure. So that in the event of fraudulent transaction the consumer is certain to be protected and refunded.
The above conditions require that any newly-marketed payment instrument is also interoperable; being compliant with existing payment and communication standards that specify a protocol stack to be implemented. This constraint is observed even in payment products issued by Apple. While the company may not have a reputation as a standard promoter, or for designing products following accepted technical standards, ApplePay does feature NFC-compliance and supports EMV applications.
This paper however focuses on Host Card Emulation (HCE), a technology that offers an excellent example of the challenge of accommodating business, functional and security requirements in a single payment product; that must (1) feature compatibility with existing terminals and (2) manage the coexistence with Secure Elements without undermining the almost-zero level of fraud achieved with payment cards.
pdf 15-12-16 PP Position SPA Final.pdf (201 KB)
