What is HCE?
Previously, we discussed about Secure Element and how it enables payment transactions in card-emulation mode. We also briefly discussed that SE is not the only choice available. Today, we also have HCE as an alternative. HCE stands for Host-based Card Emulation. As its name suggests, it has something to do with card-emulation mode. But what does host-based mean? Before we talk about what host-based means, let’s review how things were before HCE.
Prior to HCE, the only way to emulate a card using a mobile NFC device was to use a Secure Element. Let’s take the Android platform as an example. Here, the host operating system (Android in this case) and its apps do not get involved with a payment transaction at all.
When a consumer holds the device over an NFC terminal, the NFC controller in the device routes all data from the reader directly to the Secure Element. The Secure Element itself performs the communication with the NFC terminal, and no Android application is ever involved in the transaction. After the transaction is complete, an Android application can query the Secure Element directly for the transaction status and notify the user. This is the approach used by ApplePay as well
This SE based approach is inherently secure and that is a very big advantage. But, there are some downsides too. The SE owner owns the key to the kingdom. All others will have to go through complex business models, partnerships, and dependencies to gain access and it makes the whole process that much more complex and expensive. Moreover, the SE itself has only limited storage capacity and processing speed.
The alternative is to use Host-based Card Emulation. Here, the host operating system (Android) and its apps gets involved with a payment transaction.
When a consumer holds the device over an NFC terminal, the NFC controller in the device routes all data from the reader directly to the Host CPU on which Android applications are running directly. Then, an Android application (a Mobile Wallet) that deals with a particular payment application can do its magic and provide for the card emulation requests and responses.
Since the host CPU is inherently insecure, any mobile wallet worth its salt will not store the real payment credentials inside the phone. Google Wallet for example moves all such data to a hosted cloud environment, and that is where the secure storage and secure processing takes place. In essence, we have moved the Secure Element from inside a chip to a cloud environment (HCE Cloud) instead.
This approach has its downsides – like security and a need for data connection. This does not mean that your private information is vulnerable. We can still have a very high degree of security using other technologies. Payment card Tokenization is one of them and we will discuss it in an upcoming post. On the bright side, the complex business models, partnerships and access restriction to SE can be dramatically simplified. This enables payment application issuers to easily provision to the cloud and get it over with.
Using SE-based Card Emulation and Host-based Card Emulation is not an either-or scenario though. Android allows both to co-exist in the same NFC enabled device and offers tools and technologies to work with both of them as shown in the diagram below.
All the above diagrams were taken from Android developers website.
Mobile Payments Blog Series
Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #15. The idea behind this series is to share and learn as much as possible about the field of mobile payments. If you like, you can read all of the FAQs on the Mobile Payments category or by visiting the Table of contents page.