September 17th, 2014 by Elma Jane
Host Card Emulation (HCE) offers virtual payment card issuers the promise of removing dependencies on secure element issuers such as mobile network operators (MNOs). HCE allows issuers to run the payment application in the operating system (OS) environment of the smart phone, so the issuing bank does not depend on a secure element issuer. This means lower barriers to entry and potentially a boost to the NFC ecosystem in general. The issuer will have to deal with the absence of a hardware secure element, since the OS environment itself cannot offer equivalent security. The issuer must mitigate risk using software based techniques, to reduce the risk of an attack. Considering that the risk is based on probability of an attack times the impact of an attack, mitigation measures will generally be geared towards minimizing either one of those.
To reduce the probability of an attack, various software based methods are available. The most obvious one in this category is to move part of the hardware secure element’s functionality from the device to the cloud (thus creating a cloud based secure element). This effectively means that valuable assets are not stored in the easily accessible device, but in the cloud. Secondly, user and hardware verification methods can be implemented. The mobile application itself can be secured with software based technologies.
Should an attack occur, several approaches exist for mitigating the Impact of such an attack. On an application level, it is straightforward to impose transaction constraints (allowing low value and/or a limited number of transactions per timeframe, geographical limitations). But the most characteristic risk mitigation method associated with HCE is to devaluate the assets that are contained by the mobile app, that is to tokenize such assets. Tokenization is based on replacing valuable assets with something that has no value to an attacker, and for which the relation to the valuable asset is established only in the cloud. Since the token itself has no value to the attacker it may be stored in the mobile app. The principle of tokenization is leveraged in the cloud based payments specifications which are (or will soon be) issued by the different card schemes such as Visa and MasterCard.
HCE gives the issuer complete autonomy in defining and implementing the payment application and required risk mitigations (of course within the boundaries set by the schemes). However, the hardware based security approach allowed for a strict separation between the issuance of the mobile payment application on one hand and the transactions performed with that application on the other hand. For the technology and operations related to the issuance, a bank had the option of outsourcing it to a third party (a Trusted Service Manager). From the payment transaction processing perspective, there would be negligible impact and it would practically be business as usual for the bank.
This is quite different for HCE-based approaches. As a consequence of tokenization, the issuance and transaction domains become entangled. The platform involved in generating the tokens, which constitute payment credentials and are therefore related to the issuance domain, is also involved in the transaction authorization.
HCE is offering autonomy to the banks because it brings independence of secure element issuers. But this comes at a cost, namely the full insourcing of all related technologies and systems. Outsourcing becomes less of an option, largely due to the entanglement of the issuance and transaction validation processes, as a result of tokenization.
Posted in Best Practices for Merchants, Credit Card Security, EMV EuroPay MasterCard Visa, Near Field Communication, Visa MasterCard American Express Tagged with: (MNOs), (OS), assets, bank, card, card issuers, cloud, cloud based payments, cloud based secure element, cloud-based, hardware secure element, Host Card Emulation (HCE), issuing bank, MasterCard, mobile, mobile app, mobile application, mobile network operators, mobile payment, mobile payment application, nfc, operating system, payment application, payment transaction, payments, platform, risk, secure element, smart phone, software, software based technologies, token, tokenization, transaction, virtual payment, visa
August 8th, 2014 by Elma Jane
Apple talking to Visa about mobile payments
Apple is in talks with Visa as it ponders launching a mobile wallet this autumn. The latest bout of rumours suggest that the ability to make instore payments could finally arrive with the iPhone 6, although the information’s sources offer contradictory takes on the technology, with one saying that the system is likely to be NFC-based and another suggesting that it will rely on Bluetooth and WiFi. The report suggests that Apple will not be going down the host card emulation route, instead making use of the Secure Element, although the famously proprietorial tech titan has no intention of giving up any control to wireless carriers. Apple hopes that working with Visa will also help it bypass the payment processing chain, helping it to lower costs for merchants and customers.
Posted in EMV EuroPay MasterCard Visa, Mobile Payments, Smartphone, Visa MasterCard American Express Tagged with: Apple, bluetooth, customers, host card emulation, instore payments, iPhone 6, Merchant's, mobile wallet, nfc, payment processing, secure element, visa, wifi, wireless carriers
November 7th, 2013 by Elma Jane
Android 4.4 introduces an additional method of card emulation that does not involve a secure element, called host-based card emulation. This allows any Android application to emulate a card and talk directly to the NFC reader. This document describes how host-based card emulation (HCE) works on Android and how you can develop an app that emulates an NFC card using this technique.
Many Android-powered devices that offer NFC functionality already support NFC card emulation. In most cases, the card is emulated by a separate chip in the device, called a secure element. Many SIM cards provided by wireless carriers also contain a secure element.
Card Emulation with a Secure Element
The secure element itself performs the communication with the NFC terminal, and no Android application is involved in the transaction at all. After the transaction is complete, an Android application can query the secure element directly for the transaction status and notify the user.
When NFC card emulation is provided using a secure element, the card to be emulated is provisioned into the secure element on the device through an Android application. Then, when the user holds the device over an NFC terminal, the NFC controller in the device routes all data from the reader directly to the secure element.
Host-based Card Emulation
The NFC standards offer support for many different protocols, and there are different types of cards that can be emulated. When an NFC card is emulated using host-based card emulation, the data is routed to the host CPU on which Android applications are running directly, instead of routing the NFC protocol frames to a secure element.
Android 4.4 supports several protocols that are common in the market today. Many existing contactless cards are already based on these protocols, such as contactless payment cards. These protocols are also supported by many NFC readers in the market today, including Android NFC devices functioning as readers themselves. This allows you to build and deploy an end-to-end NFC solution around HCE using only Android-powered devices.
Posted in Electronic Payments, Mobile Payments, Near Field Communication, Smartphone Tagged with: 4.4, Android, app, card, cards, communication, contactless, controller, cpu, data, emulation, HCE, host, nfc, notify, payments, protocols, query, reader, routes, secure element, sim, status, terminal
