Mobile Payments: What is HCE?

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.

se-ce

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.

hce-ce

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.

se-hce-dual-ce

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.

Related Reading

Mobile Payments: What is a Secure Element?

What is a Secure Element (SE)?

GlobalPlatform defines Secure Element (SE) as a tamper-resistant platform capable of securely hosting applications and their confidential and cryptographic data in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities. Put simply, a Secure Element can be considered to be a chip that offers a dynamic environment to store data securely, process data securely and perform communication with external entities securely. If you try to mess with it by tampering in any form, it may self-destruct, but will not allow you to gain unauthorized access.

While not all NFC applications require security, those that involve financial transactions do. The Secure Element resides in highly secure cryto chips. It also provides delimited memory for each application stored in it and other functions that can encrypt, decrypt and sign the data packet.

In today’s smartphones, a Secure Element can be found as a chip embedded directly into the phone’s hardware, or in a SIM/UICC card provided by your network operator or in an SD card that can be inserted into the mobile phone.

To put things into context, when you are using an NFC enabled mobile device to Tap & Pay, the NFC controller goes into card-emulation mode. The NFC controller itself does not deal with the data or processing associated with the payment transaction. It is just an interface that allows communication using standard protocols.

It is the Secure Element that actually emulates the contactless card. It performs handshake with the terminal, sends the right responses to the right queries, generates dynamic cryptograms, authenticates the stored card and so on.  To take it a step further and be even more accurate, it is not the Secure Element that emulates the card. The software that emulates a contactless card is the one that is stored inside the secure element in the form of payment applications or applets. The Secure Element provides secure storage and execution environment for the payment applications to do its job.

Secure Element is not a necessity to emulate contactless cards although it is the most secure to date. An alternative is to use Host-based Card Emulation (HCE) which moves the secure storage and execution environment to the cloud instead of the Secure Element. We will discuss HCE next.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #14. 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.

Mobile Payments: What is NFC?

What is NFC?

NFC stands for Near Field Communication. It is a standard defined by the NFC Forum, a global consortium of hardware, software, credit-card, banking, network-providers and others who are interested in the advancement and standardizing this technology. As the name implies, it’s a set of short-range wireless communication standards used in mobile phones and other electronic devices. It operates on the frequency of 13.56 MHz with data transfer of up to 424 kilobits per second.

NFC and RFID (Radio Frequency Identification) are sometimes used interchangeably, but NFC is really a newer version or extension of RFID. RFID waves can have very long ranges as they are generally used in manufacturing, inventory and object tracking. In contrast, NFC limits the range of communication to within 2 to 4 inches. This makes NFC more suitable for secure applications like payments.

NFC allows you to share small payloads of data between an NFC tag and an NFC enabled phone or between two NFC enabled phones. This may sound more like Bluetooth because it is also a communication technology between two bluetooth enabled devices over a short range. Yes, they are similar in that aspect, but they are also different in other aspects. For instance, NFC doesn’t need a pairing process; it can read from passive NFC tags; it consumes low power; it connects to its target very quickly ( one tenth of a second) etc. These qualities make NFC a good candidate for mobile payments. Bluetooth has other advantages that makes it a better choice for a different set of use cases. We will discuss about Bluetooth, BLE and Beacons in a different post.

 

Contactless cards, that we discussed in an earlier post, behave like NFC tags and emit NFC style radio frequency signals when provoked by a contactless reader terminal. So, in theory, a mobile phone with an NFC controller can do the same as long as they conform to the protocols defined by payment networks. And that is exactly what is happening when you use a Google or Isis wallet. We will discuss how this happens in practice in an upcoming post on card-emulation mode for NFC.

So, can you just replace all of your contactless credit and debit cards with Google wallet or Isis wallet and call it a day. Not yet. There are a couple of reasons for that.

First and foremost, today, contactless terminals/readers are not plentiful. There are just over 200K contactless terminals across US. The advantage of using your contactless plastic card is that it also comes with a magstripe for backward compatibility with traditional terminals. We do not have that luxury with an NFC enabled phone.

Second, provisioning a contactless application to an NFC enabled phone is a much more complicated process involving a larger ecosystem of participants like SP TSM, SE TSM, MNO, Issuing banks and the complexity involved with security, key management and over-the-air provisioning cannot be discounted either. Technically, these have been solved, but not all Issuing banks are ready to invest in it yet. That said, the industry is slowly, yet steadily moving towards a digital wallet. So, it is going to happen sooner rather than later, but don’t hold your breath.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #12. 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.

Mobile Payments: What is Mobile Payment?

What is Mobile Payment?

Mobile Payment is one the overly hyped phrases in the industry today. It could mean a lot of different things in different contexts. In general, Mobile Payment means that as a consumer you can use your mobile device to make payments instead of paying by Cash, Check, Credit Card, Debit Card or any other payment mechanism. It could also mean that you could use your mobile device to accept payments from others; or, it could mean that you can use your mobile to pay a friend back; or just pay a bill. You get the idea.

Let’s start a list of things we can do with mobile and payments in this post. We will keep adding to the list as we find more.

  • Mobile at the Point of Sale
    • Tap & Pay using your Mobile NFC device – Google Wallet, Isis
    • Scan a QR code using your mobile’s camera to make a payment – Paydiant
    • Show a QR code displayed on your mobile at the POS – Starbucks Wallet
    • Pay using Mobile BLE and iBeacon technology and the Cloud – Paypal
    • Simulate Magnetic Stripe signals – LoopPay
  • Mobile Point of Sale (mPOS)
    • Mobile card reader dongle to accepts payments – Square
    • Fully integrated tablet based POS system – ROAM
  • P2P payments – Person to Person
    • Pay a friend using their phone number – PayM
    • Pay a friend using their email address – PayPal
    • Pay a friend by bumping the phones together – BumpPay
    • Transfer money between different bank accounts – Bank apps
  • mCommerce
    • Pay in apps using digital wallet – Pay with Paypal
    • Pay across apps – Venmo Touch
    • Pay in mobile web sites – Regular mobile checkout
    • Pay utility bills using your mobile device
  • Old Fashioned
    • Pay using SMS – Premium SMS or MMS
    • Direct carrier billing

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #10. 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.

Mobile Payments: What is EMV?

What is a EMV?

EMV is defined by EMVCo as, “a global standard for credit and debit payment cards based on chip card technology”. It was named after its original developers – Europay, MasterCard and Visa. EMVCo is the organization that manages, maintains and enhances the EMV specifications.  Today, EMVCo is owned by American Express, Discover, JCB, MasterCard, UnionPay, and Visa. Other organizations from the payments industry also participate as technical and business associates from time to time.

EMV chip cards contain embedded microprocessors that provide strong authentication, security and cryptography features not possible with traditional magnetic stripe cards. In addition to storing payment information in a secure chip rather than a magnetic stripe, using EMV improves the security of a payment transaction by adding 3 important features:

Card Authentication:

Card authentication protects the payment system against counterfeit cards. Card authentication methods are defined in the EMV specifications and the associated payment network chip specifications. Card authentication can take place online, offline or both.

Cardholder Verification:

Cardholder verification authenticates the cardholder. Use of a PIN is a common cardholder verification method (CVM) that authenticates the cardholder and protects against the use of lost or stolen card. EMV supports Online PIN, Offline PIN, Signature and No CVM as part of its specifications. As mobile payments grow new CVMs, in the form of finger-print, voice and device PIN may also get added to the list

Transaction Authorization:

For an online transaction authorization, EMV supports the notion of a dynamic transaction cryptogram. The presence of the dynamic component completely eliminates replay style attacks. EMV supports both online authorization and offline authorization based on rules and risk-parameters set by the Issuer

The Contact chip cards and Contactless chip cards that we discussed in earlier posts can comply to the EMV specification and reap its security advantages. In fact, all of the contact and contactless chip cards in Europe are created using the EMV specification. At present, contact chip cards are in very limited use in US, but the good news is that they are migrating towards it and they are using EMV as the underlying specification.

In contrast, many US banks did offer contactless chip cards over the last few years. These cards did not follow the EMV specification. They instead used a complementary Contactless MSD specification which is an equivalent to regular magenetic stripe data, but a bit more secure. They chose to use MSD because US does not have the EMV infrastructure setup yet. As and when the migration towards EMV matures, these existing contactless MSD cards will also be migrated to Contactless EMV cards or that is what I think.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #9. 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.