Image: “Stock Exchange Graph” courtesy of “cooldesign” / FreeDigitalPhotos.net
Introduction
This short note is a direct follow-up from my previous post on Host Card Emulation (HCE) so it would be a good idea to read that first; even if you have read it previously it might be worth refreshing your memory; you can find it here — I’ll wait whilst you read it …
… good, you’re back!
So, now you should have an appreciation for HCE and its significance in the mobile payments space. In that previous article, I had also described a sample application that I had written that responded to commands that were representative of those that would be issued by a typical PoS terminal and how the HCE application should respond to these.
In a sense, this was not quite a “real-world” example since the commands were generated by another application that simulated a real PoS terminal. Well, our BlackBerry NFC Development team did have access to a real PoS terminal, a ViVOpay™ 4500, and were kind enough to extend my application to respond to commands sent from this real device (this should not be interpreted as an endorsement, real or implied, of this device by BlackBerry. It’s simply that this one was available and on-hand to experiment with at the time. Other PoS terminals from other manufacturers are equally applicable here). This post describes the additional features that were added to the application to allow it to respond and identify itself as either a MasterCard™ or Visa™ card.
The Modified BlackBerry 10 HCE Application
The original tool I used to simulate a PoS terminal, “javaemvreader” (https://code.google.com/p/javaemvreader/), took a fairly crude and brute force approach to determining what cards were being emulated by the HCE application. The ViVOpay 4500, and other commercial terminals, take a much more efficient approach by checking for the presence of the “Proximity Payment System Environment (PPSE)” applet which has a well-known AID. This applet’s primary role is to inform the PoS terminal of the AIDs of the payment applets available on the card. This is a reflection of the efficiency needed in the real-world to avoid having to spend too much time with the card (or NFC handset) connected to the reader.
For a more seamless experience the HCE application registers the AID of the PPSE applet so it will be launched when presented to the PoS terminal which then attempts to select the PPSE applet.
The processing of the SELECT of the PPSE AID has also been improved rather than just responding with a static response:
The “appendFCI()” method builds the response dynamically using whatever AID (MasterCard™ or Visa™) we’ve decided to emulate. In a real-world context this would be equivalent to the user selecting the payment method as in a Wallet Application.
It’s instructive to see the typical pattern that is used to do this. EMV™ uses Type Length Value (TLV) encoding for almost all of its structured data in commands and responses and this is achieved in the HCE application by the utility class BerTLV as you can see below. BER stands for Basic Encoding Rules and is one of a number of encoding rule sets (BER, DER, …) that have their history in concrete encodings of ASN.1 data structures.
Once we’ve told the PoS terminal of the Credit Card AIDs that the HCE application supports and their preference order the PoS terminal will SELECT the AID we’ve identified, that is the card in our wallet that we want to use as the payment instrument. If we had chosen, say, a Visa™ Debit Card then our HCE application might handle that something like this:
If we reject the request from the PoS terminal than that’s the end of the interaction; if we indicate that the application supports this card type the PoS terminal will next send a GET_PROCESSING_OPTIONS command. Part of the response to the SELECT is an optional object called a PDOL (Processing Options Data Object List); this is a list of tags and lengths of the associated data elements that the card ( our HCE Application ) requests the PoS terminal to provide.
Different card schemes have different options on this command so we look for the one specific to Visa™ as shown below:
The data supplied in a GET_PROCESSING_OPTIONS command by the PoS terminal must match the data elements requested in the original PDOL. At this point the card ( our HCE application ) has in its possession the information it needs from the PoS terminal to move onto the task of performing a transaction but the terminal doesn’t. In response to GET_PROCESSING_OPTIONS we respond with a list of functions that need to be performed when processing the transaction as well as a list of files that the PoS terminal needs to read from the card ( our HCE application ) in order to allow the terminal to proceed with processing an actual transaction.
This is followed by a series of READ_RECORD commands from the PoS terminal. EMV™ itself does not specify the specific file names where these data are located, which is why they are identified in the GET_PROCESSING_OPTIONS response, and they are generally different for each card scheme type.
In the real world the next step would be to perform a transaction itself, have the card identify how the transaction should be processed and authenticated. We’ve stopped at this point in this simple example since it’s sufficient to demonstrate how a real world commercial PoS terminal communicates with an HCE application in a BlackBerry 10 device.
If you’re really interested in what the various EMV® messages and data structures 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.
Summary
I’ve released V1.1.0 of the hostcardemulation application which I’ve described in this article and which has the additional support for the ViVOpay 4500 terminal 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.
another application that simulated a real PoS terminal. Well, our BlackBerry NFC Development team did have access to a real PoS terminal, a ViVOpay™ 4500, and were kind enough to extend my application to respond to commands sent from this real device (this should not be interpreted as an endorsement, real or implied, of this device by BlackBerry. It’s simply that this one was available and on-hand to experiment with at the time. Other PoS terminals from other manufacturers are equally applicable here). This post describes the additional features that were added to the application to allow it to respond and identify itself as either a MasterCard™ or Visa™ card.
The processing of the SELECT of the PPSE AID has also been improved rather than just responding with a static response:
