So, What’s this HCE Thing Anyway?

Image: “Stock Exchange Graph” courtesy of “cooldesign” / FreeDigitalPhotos.net

Introduction

“HCE” stands for Host Card Emulation; and, if you were to read the current torrent of stories on Social Media about this technology you’d be forgiven for thinking that it was invented by Google and first implemented in Android 4.4 “Kit Kat”. Like a lot of hype the facts are actually a bit different.

The very first support for HCE was released several years ago in BlackBerry OS7; only, it wasn’t called HCE then, it was originally called Virtual Target Emulation. Ok, maybe that term doesn’t roll off the tongue as easily as HCE but it’s the very same technology that has existed in BlackBerry devices for several years including both BlackBerry 7 and BlackBerry 10. HCE is essentially a rebranding of an existing technology.

So, “What has changed?” I hear you say. Well, since we first originally released HCE in BlackBerry 7 the mobile payments ecosystem has evolved and what were regarded as complex challenges have recently become tractable due to recent changes in a number of standards. I’ll talk more about this later in this article but it’s sufficient to say that HCE has seen a dramatic resurgence in interest in the past few months and BlackBerry 10 is perfectly positioned to take advantage of that opportunity.

I’ll also illustrate the basic concepts with a real BlackBerry 10 application which you can find on GitHub.

Background

To understand HCE you need to understand how credit card payments are made at Point of Sale (PoS) terminals using secure “Chip-and-PIN” technology. The processes involved here are governed by a set of specifications called EMV® administered by EMVCo ( http://www.emvco.com/ ) whose work is overseen by six member organisations: American Express, Discover, JCB, MasterCard, UnionPay, and Visa.

Whenever you make a payment with a modern credit card with an embedded chip you’re using EMV® technology and specifications.

The PoS terminal connects to the card either through a set of contacts on the card as shown here, or through a contactless connection using Near Field Communication (NFC), as shown below.

As far as EMV® transactions are concerned these are just two different transport mechanisms to communicate with the Secure Element (SE) that lives inside the tamper-proof chip. The SE is where all the attributes that personalise a credit card as being “yours”. In addition to the obvious things like: the PAN (Personal Account Number – the long 16 digit number embossed on the front), validity dates, your name, and card issuer; the SE also contains a host of other data including: user’s preferred language, currency of the card, PIN, PIN retry count, secret keys, various certificates. These attributes are stored on an empty card through a process called “Personalisation” which is done by the card issuer in a highly secure location.

Some of these attributes are accessible to the PoS terminal and others, such as the PIN and secret keys, are obviously not. In general, most cards these days use a particular standard whereby a JVM (Java Virtual Machine) runs in the secure element; java applications (identified by a hex string called an AID – Application Identifier) run in this JVM and communicate with the PoS terminal, performing tasks such as: checking a presented PIN against the stored PIN, signing transactions with stored secret keys to authorize payments etc. The key point to understand is that the PoS terminal communicates with the SE using a protocol defined in the ISO 7816-4 standard. It sends commands to the SE and received responses. EMV® defines a complete set of commands and responses that are sent to and from the SE consistent with ISO 7816-4.

The PoS terminal is but one entry point to a complex ecosystem that is used securely to route transactions to financial institutions, approve transactions and perform a host of other operations such as updating data in the SE. You may occasionally hear the term TSM (Trusted Service Manager) used to identify this management ecosystem. The diagram below gives a flavour of all the stakeholders that play their parts in this ecosystem.

Card Emulation – The First Step

So, now you’ve got a basic idea how a payment card interacts securely with a PoS terminal. Historically the next step was to recognize that the model of Secure Elements as containers for attributes and authentication details is not limited to payment cards. In fact the first real use for SEs was as secure containers for attributes and credentials to allow you to connect to and access a mobile phone network. The SIM card (or UICC in 4G parlance) in your GSM phone uses just the same technology as the SE on a payment card.

It’s not a big step to recognize that, technically, it’s possible to install the same java payment applications that run inside a credit card’s SE into the UICC’s SE in a mobile phone. There are two additional elements of technology that were needed to make this work:

A means of connecting the phone’s UICC to an external interface to the PoS terminal;
A means of provisioning credit card personalization data over the air (OTA) from the credit card issuer to the SE in the UICC.

The first of these was achieved by repurposing one of the UICC’s pins as a communication channel called Single Wire Protocol (SWP) and connecting it to an NFC controller in the phone. So, now the PoS terminal could “speak” EMV® directly to the SE in the UICC. Job done!

The second of these was achieved by recognizing that Mobile Network Operators (MNOs) already did this through their SMS infrastructure in order to provision subscriber information in the UICC. By suitably melding the TSM into the SMS framework card issuers could provision credit card personalization data into the SE in a UICC. Job done!

Other mechanisms, such as BIP (Bearer Independent Protocol) also evolved in cases where it was desirable to avoid using the MNO’s SMS infrastructure and to allow direct TCP/IP connections from the TSM to the SE in the UICC.

The diagram above shows a representation of this model with the solid blue arrows showing the path taken by commands and responses from the PoS terminal to the SE in the handset. It’s very important to understand that ordinary applications running in the BlackBerry 10 handset play absolutely no role in the handling of transactions from the PoS reader. There is essentially no difference between this model and a real physical credit card other than how the SE is hosted.

Whilst this architecture was technically sound and secure it brought with it complexities of a business nature. To understand this take an example of a Transit Authority which uses NFC smart cards to store ticketing information that is read at the gates on entry to and exit from their transit stations. They want to install their ticketing application, which runs in their smart cards, into the UICC in mobile phones. This means that they have to establish business relationships with each MNO whose phones they want to be able to access.

This model is difficult to scale. For example, upgrades to the application would have to be tested on different MNO’s UICCs and provisioning networks. MNOs also wanted to “monetize the real estate” of their UICCs which meant competition existed for access to the limited application storage space on a UICC even with a single MNO. For the Transit Authority to achieve wide deployment of their application they would need to establish many contracts with different MNOs.

So, things languished whilst card issuers struggled with the business complexities that underpinned the model where the SE resided in an MNO’s UICC. One approach that’s had some success in tackling this issue is that of a “TSM Aggregator”, where a TSM acts on behalf many MNOs offering services to multiple card issuers – this helps reduces the original problem from an O(N²) one to a more tractable O(N) one.

Host Card Emulation – The Final Step

Remember I said that Host Card Emulation has been available on BlackBerry devices for some time now? Well, what exactly is HCE?

It’s really quite a simple concept.

So far we’ve seen how a PoS terminal can communicate directly with a secure java application running in an SE in the UICC in a BlackBerry device using ISO 7816-4 and EMV®. The NFC controller routes messages to and from the UICC.

With HCE the NFC controller routes these messages directly to and from a standard BlackBerry (OS7 or OS10) application; a java application in the BlackBerry 7 case and a Cascades application in the BlackBerry 10 case. The BlackBerry application becomes responsible for responding to the EMV® commands from the PoS terminal and generating responses.

Here’s a diagram to help you visualize this.

That’s it – that’s HCE!

Well, it occurred to some organizations that moving the credential store from the SE in the UICC into a “Hosted SE” in the “cloud” would solve the issues of business complexity. This was a great idea however, it suffered from some issues:

A mobile device would have to be “online” to the SE in the cloud to authorize payment transactions – a non-starter;
There were no standards for how to securely communicate with an SE in the cloud – specifically, no EMV® standards – without standards there is fragmentation and low adoption;
The risks of compromising EMV® credentials if they were stored in a mobile phone application in order to address the connectivity issue to the SE in the cloud were not acceptable.

These are all valid concerns. However, they must be tempered with the business problem that you’re trying to solve. For many applications, such as customer loyalty cards or where the types of transactions are for small amounts and sandboxed in a niche area, these risks and their consequences are relatively small compared to the end-user benefits and convenience that the application provides. It’s a classic case of where the risks have to be weighed against the consequences.

A great example of this is PVR Cinemas in India which launched a “PVR Wallet” application on BlackBerry 10 using HCE. This has proved to be extremely popular allowing customers to purchase cinema tickets and other items from the in-cinema store using a “closed loop payment wallet” model where rights to use the transaction money remains on the cinema premises.

Another great example is Tim Hortons, the North American Coffee House Chain, which launched an NFC payments service for its customers using HCE on BlackBerry 10 devices and where the card balance data is stored with the payments processing company First Data.

The major change that occurred to resurrect interest in HCE-based EMV® payments came earlier this year when EMVCo announced a new standard. It’s a called The EMV Payment Tokenisation Specification and it addresses and resolves each of the three issues noted above. The ingenious part is that it manages to do this without altering any of the EMV® messages that are sent between a PoS terminal and an NFC smart-phone handset. It re-purposes some of the EMV® fields in a non-disruptive manner that is transparent to the transaction flow – for example, the PAN is used to communicate one-time-use “tokens” in a transparent manner.

This standard, along with the release of support in Android 4.4 (“Kit Kat”) for HCE, has generated enormous interest in the mobile payments community. It’s all beginning to come together.

Here’s a modified version of the earlier diagram to help you visualize this new model. The dotted blue line just indicates that the interaction between the BlackBerry 10 application and the cloud hosting the secure EMV® service implements a different set of protocols compared with the path between the application and the PoS terminal.

It ought to be noted that not everyone is comfortable with this. Whilst card issuers and financial institutions consider this standard as key to implementing secure mobile payment solutions that are decoupled from MNOs, others, specifically MNOs and smart card manufacturers, assert that this approach is still not secure and that physical SEs are the only truly secure solution.

There are merits on both sides of this argument but whatever the approach it should be noted that BlackBerry is capable of supporting both solutions!

So, how would you go about implementing a BlackBerry 10 application that would interact with an EMV® PoS terminal?

Well, let’s do that now!

A BlackBerry 10 HCE Application

There already exist a number of resources about BlackBerry 10 HCE (called Virtual Target Emulation in older posts) so I won’t duplicate these. What I want to demonstrate is the sort of messages that an EMV® PoS terminal might send to a BlackBerry 10 HCE application, how to handle these and generate some stock (and fake) responses that the application might make to the reader.

I took as my starting point a tool called “javaemvreader”. You can find it here: https://code.google.com/p/javaemvreader/. It’s a testing tool that can be used to communicate with, and read data from an EMV® smart card. The primary purpose of this tool is to read and parse all the openly accessible information (non-secure data) on an EMV® card. It basically produces a report of the basic attributes of the card including open data that you’d find embossed on the card. It’s great for testing.

The BlackBerry 10 application would work this way:

I first start the “javaemvreader” application on my PC and it communicates with an NFC capable HID OmniKey reader that’s USB-attached – that is it emulates the PoS terminal;
I than start my BlackBerry 10 application that uses HCE and “tap” the handset onto the HID reader;
The “javaemvreader” application starts sending EMV® commands to the BlackBerry 10 application which then constructs the appropriate stock responses;
The output from the “javaemvreader” application reports on the details of my emulated “credit” card.

Here you can see the application and hardware setup with my Z10 sitting on the NFC reader which is connected to my PC:

Here’s the basic procedure to enable the application to initialise and start receiving NFC related events:

Now, NFC events will cause the event() function to be called and it’s in this function that the event is checked as being an NFC one, whereupon it’s handled at handleNfcEvent(). There are two specific NFC events of interest to us:

One when the NFC reader (i.e. the PoS terminal) selects the handset, and;
One when a command is detected from the NFC reader (i.e. the PoS terminal).

It’s the second one that we’re really interested in since we need to parse and respond to this command in this function processIso144434CommandEvent(). Since the required responses are almost stateless in this simple, contrived example they can be generated easily – I’ve used simple macros to check the inbound command COMPARE() and generate a response RESPOND():

The first challenge for a PoS terminal is to figure out what type of card has been presented. Remember I said that the java application (applet) that runs inside card’s SE is identified by an AID? Well, each card issuer will have its own payment applet and the PoS terminal can determine the type of card you’ve presented by the presence of that applet.

You can see this is actually the case by looking at a receipt you’ve received after paying for goods with a card. Take a look at the receipt on the left. I’ve highlighted the annotation that a card with a payment an applet of AID of “A0000000041010” was use in this transaction. This AID is the one for a MasterCard credit card.

Well, the PoS terminal could use brute force and try to “SELECT” each possible AID that it knows about in turn until it found one. This just isn’t manageable or scalable. So, cards generally have another applet: “Proximity Payment System Environment (PPSE)” with “well-known” AID of “0E315041592E5359532E444446303100”. This applet’s primary role is to inform the PoS terminal of the AID of the payment applet on the card.

Out of the box the “javaemvreader” tool uses a combination of these techniques (check it out and see what it does) but you can see from the code fragment above that one of the commands I check for is the selection of the PPSE to which I reply appropriately.

Once it’s figured out the AID of the payment applet it can start asking it questions to determine its capabilities. To do this it sends a “GET PROCESSING OPTIONS” command and after an interchange of some other messages it is able to determine information like the PAN, card validity dates, card holder name, currency used, language used and other processing options of the card. Amongst other things the PoS terminal can use this information to select the correct language to walk the cardholder through the payment menus.

This is as far as the “javaemvreader” tool will go but a real PoS terminal would then start a transaction authorisation process which involves checking of the PIN, and processing of transaction details using the secret keys in the SE – way out of scope for this simple example.

You can look at the code in GitHub for the details but I’ll just highlight two particular command-response pairs. Just to demonstrate that you can pretty well invent your own commands and responses provided they follow the ISO 7816-4 format you can see that in the case of the command “COMMAND_HELLO_POS” (my own invention but syntactically correct according to ISO 7816-4) being received I’ll respond with the string “Hello, PoS!”:

The 0x9000 at the end of the response is the ISO 7816-4 convention for a status of “Response was OK”.In the case of a “real” EMV® command; if I receive, say, “READ_RECORD_SFI_1_1” (part of the exchange related to “GET PROCESSING OPTIONS”) I respond as shown below:

This command requested data which contained information such as the cardholder’s name and the card number. You can see that I respond with “FLINTSTONE/WILMA.MRS” as the cardholder with a card number (PAN) of “1111 1111 1111 1111”. Here’s part of the output from the “javaemvreader” tool showing that it successfully interpreted this:

You can see that, just for fun, I also set the currency as “East Caribbean Dollar” and somewhere else I set the language as “Esperanto”. It’s interesting to note that it attempts to interpret the PAN which seems to map onto the “Airlines” industry sector and I’ve obviously got the check digit set incorrectly as well.

Ok, this is all good fun! But the serious side is that this demonstrates the basic techniques you’d use if you were to write a real HCE payments application. In that case you’d need to use The EMV Payment Tokenisation Specification and to generate real and secure responses via the “SE service in the cloud”.

There is one more feature I want to point out. It’s a feature that was added in BlackBerry 10 release 10.3. It allows you to register an AID with the NFC service such that, if your HCE application is not running, then it will be automatically launched by the Invocation Framework when a PoS terminal attempts to select that AID. This is intended to allow you to make payments at PoS terminals without having to search for the correct application and launch it manually.

There are certain pre-requisites to be satisfied before this will work:

The device must be running BlackBerry 10 version 3+ — I’ve checked for this in my sample code using conditional compilation as shown below;
The device supports what is called “Feature Set 2” – you can test for this as shown below.

If these pre-requisites check out then you can register the AID as shown below.

This registration is persistent across device restarts so you ought to make sure that you also have the ability to unregister your AID using nfc_hce_unregister_aid().

The screenshots below show that I ran the application on a device that runs BlackBerry OS 10.3 but which supports feature set 1. In this case the “HCE Register AID” and “HCE Unregister AID” buttons appear on the screen, because it’s running 10.3, yet are greyed out, since it’s not feature set 2 capable.

You can also see some of the commands that have been sent to the HCE application and the responses I’ve sent back.

If you’re really interested in what these various EMV® messages actually mean there is a really great site here: http://www.emvlab.org/. It’s run by the Security Group at the University of Cambridge Computer Laboratory and hosts an enormous number of EMV® and banking related tools.

Whilst I’m talking about tools there are some other ones that I use quite frequently when dealing with smart cards:

GPShell – this is probably the “workhorse” of tools used to communicate with smart cards that support the GlobalPlatform It’s quite low level but very powerful. I’ve included a simple GPShell script (“sendApduToDevice.txt”) in the “/scripts” folder of the HostCardEmulation project on GitHub that will send the command “COMMAND_HELLO_POS” I mentioned earlier to the application and elicit the “Hello, PoS!” response.
Pyscard – for all you “Pythonistas” out there you should check out this incredibly useful Python module which allows you to write quite complex Python applications that can communicate with smart cards. For comparison I’ve also included a simple Python script (“py”) in the same “/scripts” folder that does the same as the GPShell script.

See the links in the Resources section at the end of this article for details of these tools and have fun!

Summary

I’ve released V1.0.0 of the hostcardemulation application which I’ve described in this article on GitHub so you can download, review and reuse the full source code – you can find the URLs in the “Resources” section below. I hope this has been interesting and will help set you on your way developing real-world NFC HCE applications for Blackberry 10.

Please feel free to contact myself @jcmrim via Twitter if you need any help on anything NFC or HCE related.