Tuesday, December 23, 2014

A Watershed Moment for the Payments Industry

article-2160143-13A24E0B000005DC-373_964x587.jpg

Did you see the news? If you blinked, you might have missed it but its importance has ramifications throughout the payments industry.


Last Friday, Royal Bank of Canada (RBC) became the first North American bank to launch a pure Cloud Based Payments (CBP) solution utilizing Host Card Emulation (HCE) technology. Kudos to RBC! Read their release here.


An important aspect of the announcement is that the Canadian debit organization Interac was included with it’s Flash for Cloud Based Payments. Interac’s Flash seems to have beaten all other payments networks and their specifications to the punch by bringing a working solution to the market.


From our perspective, this marks the beginning of an anticipatory shift by financial institutions away from analog payments into digital. The shift will accelerate over the next several years as many financial institutions look for more effective ways to engage customers and distribute products to an ever more mobile and demanding consumer base. Juniper Research estimates mobile retail purchases to eclipse $700B annually by 2017. This transformation will not only impact the way banks engage with customers, but will drive what kinds of financial products and services are developed and how they are offered to customers throughout an ever evolving environment.


We’ve heard these predictions before, why now?


The payments industry ecosystem is at an inflection point. The meteoric rate at which innovation is happening foretells of much needed change and the necessity for more adaptive business models.


Enter CBP and HCE.


The concept of CBP and HCE did not exist until SimplyTapp introduced them in August 2012.  CBP is the framework for storing payment credentials in a virtual Secure Element (SE) in the cloud while HCE provides the path of getting those credentials from the cardholder’s mobile phone to the retailer’s Point of Sale (POS). Groundbreaking as that was, it only represented the first of several enablers that were needed before widespread adoption could take place within the industry. The next step that was needed occurred nearly one year later with the inclusion of HCE inside Android 4.4 (KitKat) in September 2013 which provided developers with a proven, widely distributed platform to build wallets and mobile banking applications. Earlier this year at Mobile World Congress in Barcelona, Visa and MasterCard gave their much needed support and endorsement for CBP and HCE providing immediate legitimacy and freeing up issuing banks for innovation. Only one critical requirement remained in order to drive adoption of this technology. A forward-looking bank needed to take the initiative and roll-out a live implementation with real data and real transactions. RBC’s announcement last week fulfilled that requirement.


NFC-Infrastructure.jpg

With each of these key enablers firmly in place, the stage is set for mobile payment proliferation. Each day, consumers are expecting to do more with their mobile devices than ever before. The emergence of groundbreaking core technology and services, including the launch of Apple Pay, reveals a new and largely unmet demand for point-of-sale mobile purchases. More and more consumers will come to rely upon customer-centric financial institutions to help them conduct secure and convenient mobile purchases.


Being the first at anything is never easy. It requires vision, a smart assessment of the path ahead and a resolve to overcome any obstacles discovered along the way. For those who are willing, the rewards greatly outweigh the risks. We applaud RBC’s and Interac’s industry leadership and focus on the customer. And we join them in ushering a new year full of innovation.


Agree? Disagree? Let us know what you think.

Friday, October 10, 2014

The Absolute Simplest HCE "Pay" Application Enablement


Most of the code below relates to GUI messaging,  but this Android app is full HCE for a Cloud Based Payments card.  It is a total of 201 lines of code including comments, and line spaces. It is a single class application for simplicity.
The goal is to show that the libraries for managing CBP on the mobile app are lightweight for developers to use.
The libs are designed to be placed into ANY application that may want to enable CBP.  The one below is about the simplest integration.
The full application is called SimplestTapp and can be downloaded and tested here:
http://wiki.simplytapp.com/home/self-driven-hce-pilot/make-a-payment-card/simplytapp-s-vcbp-changelog/software-dev-kits/mobile-sdk

it also may be good to view this help resource for creating and managing the card perso and lifecycle in the cloud:
http://wiki.simplytapp.com/home/using-admin-api-console

The core of the card download and enablement is really contained in this section.  This section instantiates a VirtualCard that will be loaded from the remote server.  In order to instantiate the CBP card, you will see that there are some required credential information because a request will be made to the CBP server to retrieve the card that will be used.
The data in the snippet is sample data only.

The AsyncTask is used because the load() method makes network calls and can't be run on the UI thread.

        // Create a card with data from AdminApi console
        // See wiki for help:
        // http://wiki.simplytapp.com/home/using-admin-api-console
        //
        // Values are found within your AdminApi Console. Click Get APP
        // Credentials.
        //
        // card agent code hash is found inside the Issuer Entity portion of the
        // web portal
        //
        final VirtualCard card = VirtualCardBuilder
                .cardId("5901")
                .mobileAppConsumerKey(
                        "oJmqoey7I97FBOZQDXoH0A9RbM7BciXbD8CHZDMU")
                .mobileAppConsumerSecret(
                        "ugTD5dGjBUEC1pyzxjMNtw6k9TUocGtY4plta9he")
                .walletAccessToken("O15F4jG3PcwC44NpkfEqv1ZD7tjNo5NhGpHHFEax")
                .walletTokenSecret("Ur504iPQn2lxgsS5fVBycf2zK9uuSglppvn2mBa3")
                .cardAgentCodeHash("aa4185c2364048447a38aa02499a9897")
                .context(this).build();

        // now load the card...
        // this requires network connectivity and is blocking
        // so we must use AsyncTask to avoid running this in UI thread
        //
        new AsyncTask() {
            @Override
            protected Void doInBackground(Void... params) {
                try {
                    myActivity.postUi("=================================="
                            + "\n" + "=====Loading Card From Server====="
                            + "\n" + "=================================="
                            + "\n");
                    card.load();
                } catch (IOException ex) {
                    Log.e(TAG, "Failed to load", ex);
                }
                return (Void) null;
            }
        }.execute();

 Once the VirtualCard successfully loads, it has a mind of it's own and will perform all activities related to making a successful payment when requested to do so.  For this, the feedback mechanism from the card to the mobile application is a messaging interface and should be defined in a block similar to the one below.  You will notice that the block below is responsible for handling feedback from the card and also notifying the card to activate after it was successfully created:

    // define the message default card message handler
    // and set it in the lib
    static {
        VirtualCardMessaging virtualCardMessenger = new VirtualCardMessaging() {
            @Override
            public void virtualCardMessage(VirtualCardMessaging.Message message) {
                switch (message.getCode()) {
                case VirtualCardMessaging.CARD_CREATION_COMPLETED:
                    try {
                        // when card is created, then activate the card agent,
                        // then connect it to the ApduService,
                        // then ask the user if they want this app the default
                        // app
                        // for servicing the reader
                        message.getVirtualCard().activate();
                        ApduService.setVirtualCard(message.getVirtualCard());
                        myActivity.postUi("========================"
                                + "\n"
                                + "=====Card Created======="
                                + "\n"
                                + "========================"
                                + "\n"
                                + "==Card Id: "
                                + message.getVirtualCard().getVirtualCardId()
                                + "\n"
                                + "==Num: "
                                + message.getVirtualCard()
                                        .getVirtualCardNumber()
                                + "\n"
                                + "==Card Exp: "
                                + message.getVirtualCard()
                                        .getVirtualCardExpDate() + "\n"
                                + "==Card Type: "
                                + message.getVirtualCard().getVirtualCardType()
                                + "\n" + "==Card Logo: "
                                + message.getVirtualCard().getVirtualCardLogo()
                                + "\n");
                        myActivity.postUi("========================" + "\n"
                                + "=====Card Activating====" + "\n"
                                + "========================" + "\n");
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                    break;
                case VirtualCardMessaging.CARD_ACTIVATE_COMPLETED:
                    myActivity.postUi("========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "=====Card Activated=====" + "\n"
                            + "=====Ready To Tap=======" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n");
                    break;
                case VirtualCardMessaging.TRANSACTION_ENDED:
                    myActivity.postUi("========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "===Ready To Tap Again====" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n");
                    break;
                default:
                    break;
                }

                // log the message
                Log.d(TAG,
                        message.getMessage() + " cardId="
                                + message.getVirtualCardId() + " code="
                                + message.getCode());
                myActivity.postUi(message.getMessage() + " cardId="
                        + message.getVirtualCardId() + " code="
                        + message.getCode() + "\n");
            }

        };

        // set the default messenger
        VirtualCard.setDefaultVirtualCardMessaging(virtualCardMessenger);
    }


You will notice above that the messaging loop is logging all messages from the card and printing them to the screen of the app and the debugger.  This can give you an idea of the events the card notifies the app.  As far as API requests to the card from the app, the VirtualCard library contains many methods.  Here is the JavaDoc:
http://simplytapp.github.io/android/virtualcard/doc/

Full activity class code for this example:

package com.simplytapp.example.simplesttapp;

import java.io.IOException;

import com.simplytapp.virtualcard.ApduService;
import com.simplytapp.virtualcard.VirtualCard;
import com.simplytapp.virtualcard.VirtualCardBuilder;
import com.simplytapp.virtualcard.VirtualCardMessaging;

import android.app.Activity;
import android.content.ComponentName;
import android.content.Intent;
import android.nfc.NfcAdapter;
import android.nfc.cardemulation.CardEmulation;
import android.os.AsyncTask;
import android.os.Bundle;
import android.text.method.ScrollingMovementMethod;
import android.util.Log;
import android.widget.TextView;

public class MainActivity extends Activity {
    private static final String TAG = MainActivity.class.getSimpleName();
    private static MainActivity myActivity = null;
    private TextView tv = null;

    // this method posts strings to the textview box in the UI thread
    private void postUi(final String t) {
        new Runnable() {
            public void run() {
                runOnUiThread(new Runnable() {
                    public void run() {
                        tv.append(t);
                        if (tv.getLayout() != null) {
                            // auto-scroll vertically
                            final int scrollAmount = tv.getLayout().getLineTop(
                                    tv.getLineCount())
                                    - tv.getHeight();
                            // if there is no need to scroll, scrollAmount will
                            // be <=0
                            if (scrollAmount > 0)
                                tv.scrollTo(0, scrollAmount);
                            else
                                tv.scrollTo(0, 0);
                        }
                    }
                });
            }
        }.run();
    }

    // define the message default card message handler
    // and set it in the lib
    static {
        VirtualCardMessaging virtualCardMessenger = new VirtualCardMessaging() {
            @Override
            public void virtualCardMessage(VirtualCardMessaging.Message message) {
                switch (message.getCode()) {
                case VirtualCardMessaging.CARD_CREATION_COMPLETED:
                    try {
                        // when card is created, then activate the card agent,
                        // then connect it to the ApduService,
                        // then ask the user if they want this app the default
                        // app
                        // for servicing the reader
                        message.getVirtualCard().activate();
                        ApduService.setVirtualCard(message.getVirtualCard());
                        myActivity.postUi("========================"
                                + "\n"
                                + "=====Card Created======="
                                + "\n"
                                + "========================"
                                + "\n"
                                + "==Card Id: "
                                + message.getVirtualCard().getVirtualCardId()
                                + "\n"
                                + "==Num: "
                                + message.getVirtualCard()
                                        .getVirtualCardNumber()
                                + "\n"
                                + "==Card Exp: "
                                + message.getVirtualCard()
                                        .getVirtualCardExpDate() + "\n"
                                + "==Card Type: "
                                + message.getVirtualCard().getVirtualCardType()
                                + "\n" + "==Card Logo: "
                                + message.getVirtualCard().getVirtualCardLogo()
                                + "\n");
                        myActivity.postUi("========================" + "\n"
                                + "=====Card Activating====" + "\n"
                                + "========================" + "\n");
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                    break;
                case VirtualCardMessaging.CARD_ACTIVATE_COMPLETED:
                    myActivity.postUi("========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "=====Card Activated=====" + "\n"
                            + "=====Ready To Tap=======" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n");
                    break;
                case VirtualCardMessaging.TRANSACTION_ENDED:
                    myActivity.postUi("========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "===Ready To Tap Again====" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n"
                            + "========================" + "\n");
                    break;
                default:
                    break;
                }

                // log the message
                Log.d(TAG,
                        message.getMessage() + " cardId="
                                + message.getVirtualCardId() + " code="
                                + message.getCode());
                myActivity.postUi(message.getMessage() + " cardId="
                        + message.getVirtualCardId() + " code="
                        + message.getCode() + "\n");
            }

        };

        // set the default messenger
        VirtualCard.setDefaultVirtualCardMessaging(virtualCardMessenger);
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        myActivity = this;
        tv = (TextView) findViewById(R.id.textView1);
        tv.setMovementMethod(new ScrollingMovementMethod());

        // try to set this app as the default HCE application app
        CardEmulation cardEmulationManager = CardEmulation
                .getInstance(NfcAdapter.getDefaultAdapter(this));
        ComponentName paymentServiceComponent = new ComponentName(
                getApplicationContext(), ApduService.class.getCanonicalName());

        if (!cardEmulationManager.isDefaultServiceForCategory(
                paymentServiceComponent, CardEmulation.CATEGORY_PAYMENT)) {
            Intent intent = new Intent(CardEmulation.ACTION_CHANGE_DEFAULT);
            intent.putExtra(CardEmulation.EXTRA_CATEGORY,
                    CardEmulation.CATEGORY_PAYMENT);
            intent.putExtra(CardEmulation.EXTRA_SERVICE_COMPONENT,
                    paymentServiceComponent);
            startActivityForResult(intent, 0);
        }

        // Create a card with data from AdminApi console
        // See wiki for help:
        // http://wiki.simplytapp.com/home/using-admin-api-console
        //
        // Values are found within your AdminApi Console. Click Get APP
        // Credentials.
        //
        // card agent code hash is found inside the Issuer Entity portion of the
        // web portal
        //
        final VirtualCard card = VirtualCardBuilder
                .cardId("5901")
                .mobileAppConsumerKey(
                        "oJmqoey7I97FBOZQDXoH0A9RbM7BciXbD8CHZDMU")
                .mobileAppConsumerSecret(
                        "ugTD5dGjBUEC1pyzxjMNtw6k9TUocGtY4plta9he")
                .walletAccessToken("O15F4jG3PcwC44NpkfEqv1ZD7tjNo5NhGpHHFEax")
                .walletTokenSecret("Ur504iPQn2lxgsS5fVBycf2zK9uuSglppvn2mBa3")
                .cardAgentCodeHash("aa4185c2364048447a38aa02499a9897")
                .context(this).build();

        // now load the card...
        // this requires network connectivity and is blocking
        // so we must use AsyncTask to avoid running this in UI thread
        //
        new AsyncTask() {
            @Override
            protected Void doInBackground(Void... params) {
                try {
                    myActivity.postUi("=================================="
                            + "\n" + "=====Loading Card From Server====="
                            + "\n" + "=================================="
                            + "\n");
                    card.load();
                } catch (IOException ex) {
                    Log.e(TAG, "Failed to load", ex);
                }
                return (Void) null;
            }
        }.execute();

    }

}

Friday, October 3, 2014

Cryptogram calculation clarity for CBP



This is the key concept and change between EMV and what is required for CBP cryptograms.
Effectively the cryptogram in the CBP payment is created half in the cloud and then the other half when you tap the phone.

The reason for this is because the network connectivity may not allow a scenario like the left side of the diagram below as the UN would get cut off from transmitting from the POS to the calculation space, or it would be subject to network latency and create a "Tap and Hover" effect that would be an awful user experience.

The CBP cryptogram allows all components to be used as before and exposes a "relay threat" only to the android app after the SUK is received, but not to the POS terminal.   It also allows the Phase 2 calculation to happen independent of cloud availability at tap time.  The Phase 1 calculation and delivery to the phone from the cloud is expected to be preformed prior to tapping the phone, but not during the tap itself.

The thought is to offset the relay threat with in app security and sensor rich android OS.

It becomes a net neutral from a security standpoint really, IMO.


Sunday, September 21, 2014

Asia-The New Frontier for Contactless Payments


Asia is pivotal to the future of mobile contactless payments. The region has the numbers, and the markets are mostly EMV compliant or in the process. Some have moved further down the path of contactless than many others across the rest of the world. Veterans of the payments space will recollect the early pioneers of mobile payments came from this region. There is a quiet confidence in innovation centered around consumer aspirations, cashless evolution and new strategic paths. 


NFC via HCE is important for the future of cashless Asia. This region consists largely of dense urban ecosystems where footfalls are high, queues are long, security is highly desired and the need to keep moving is critical. Contactless modes allow ease of payments(tap, no signature below a limit), a strong sense of security (I don’t hand over my card) and speed of throughput (smaller queues at checkout).
Host Card Emulation enables contactless transactions across devices and carrier networks, allowing issuers to take control of the payment process and brand, and invest in growing their market. It enables banks to shift issuance towards real time, virtual and customized offerings without spending a fortune. Customers and banks are able to interact to control spend and credit exposure. Transforming transactions for the mass affluent by offering them the security of a physical tap via mobile with the scale and ease of a digital backend is the core appeal of HCE.  SimplyTapp brought HCE to the world in 2012 and has since worked with key stakeholders to make it universally available. For issuers in emerging and mature Asia, SimplyTapp offers a highly flexible, lean and cost-effective solution that can launch services in a few weeks. Beyond the solution, we have committed ourselves to helping issuers, networks and regulators build innovation frameworks to take digital transactions to the masses. At the 5th Asian Smart Card Conference in Bangkok, we look forward to enriching conversations that help move mobile contactless transactions in this region to the next level. Talk to us. We are committed to Asia. 

-Kaustuv Ghosh runs the Asia business for SimplyTapp. He is based in Singapore and is available at kaustuv.ghosh@simplytapp.com. Reach out to Kaustuv or to info@simplytapp.com to discuss how SimplyTapp can help you launch mobile contactless payments rapidly and cost effectively. 

Thursday, September 11, 2014

Apple Pay and Android payment eco-systems


It is important to understand what tokenization means in the context of the introduction by Apple on Tuesday.  The word "tokenization" can sound very general, complex, and unknown the way it is being used in payments today.  I think many use the term without really understanding the important details of the concept.  I sort of relate it to when i pick up my 4 year old daughter from sunday school class, I will ask her what she learned, and she knows that if she answers "God", that she is right.

So the point of this blog is to try to understand what tokens are, and how they are used to solve something in payments.  The mis-understood rule of tokens is that people think they change from transaction to transaction, but in reality the cryptogram changes but the token properties (tPAN and tUDK) don't:
  • A token may be created once for the life of a credential (card).  

This is easiest to understand with the Apple Pay use case.  The secure element on the phone is programmed at the factory when the iPhone is built to support many different card standards.  At the time when the token data needs to get programmed into the device, Apple requests a token for that device from the card networks.  The networks need to keep track of the token because they need to know how to translate that token into iTunes identity for processing the iTunes selected card during transactions with the payment acceptor.

But the important piece is that this token is a static identifier for the life of the card that was programmed.

A diagram describing this process for iPhone is here:   


Because Android is not a vertically owned stack similar to apple, it is really hard to distinguish who owns the SIM, or SE, or UICC that is on the particular phone.  Because of the ownership argument over the last few years, the idea of HCE was launched to push the ownership of the SE to the cloud so that it could be leveraged on any Android phone from the cloud.  But the important concept that has gotten lost with the Apple announcement is that the concept of "tokenization"  as Apple Pay uses is still the exact plan for tokenization in the android space.  With HCE enabled, however, the equivalent of the one time token "Apple ID" that lives in the iPhone SE, is actually located virtually in the cloud with a bank, or third party vendor like SimplyTapp:



======================AND STOP===================

THE TOKEN HAS NOW BEEN CREATED!!
THE TOKEN REQUESTER CAN USE THIS TOKEN FOR
ALL TRANSACTIONS ON THAT CARD GOING FORWARD
WITHOUT REQUESTING ANOTHER TOKEN FROM THE SERVICE
AGAIN FOR THE LIFE OF THAT CARD IT REPRESENTS

THIS CAN BE TREATED ON PAR WITH TYPICAL PLASTIC CARD
PERSONALIZATION SERVICES TODAY

ONLY WHEN THE TOKEN IS ACQUIRED BY THE MERCHANT
DOES THE NETWORK NEED TO VERIFY THE TOKEN AND ALSO
TRANSLATE THE TOKEN BACK TO THE CARD IT REPRESENTS
SO THAT THE BANK CAN PROCESS IT FOR APPROVAL AS
USUAL

SO ONE TOKEN AND RELATED DATA CAN BE USED FOR
MULTIPLE TRANSACTIONS

==================================================
ok, i think i'm done hammering that characteristic of a token. :)

Another very important thing to understand about transactions using tokens is to understand that the data format of a tokenized transaction is EXACTLY the same as the data format of a non-tokenized transaction from the Point of Sale perspective.  The same basic elements exist and are exchanged from the phone to the POS:
non-tokenized:
1) Personal Account Number
2)  Expiration Date
3)  Service Code
4)  Issuer Discretionary Data
5)  Cryptogram

tokenized:
1) Tokenized Personal Account Number
2)  Expiration Date
3)  Service Code
4)  Issuer Discretionary Data
5)  Cryptogram

because the data format that is exchanged between the phone and the POS is identical in both cases, the tokenized version still has the ability to include dynamic transactional data by using a Cryptogram to do so (adding the "one time number for each transaction" that Tim Cook preached about)

Keep in mind for cryptogram creation and cryptogram validation, there does not need to be a run-time link between the validator and the tokenized card (this is obvious by the apple deployment of a hardened secure element on the phone).

So understanding how tokenized or non-tokenized cryptograms are created and validated is important.  By the way,  the algorithm is identical for tokenized or non-tokenized.  The "tokenized" part of the features is actually out of the scope of cryptogram calculation / validation.

Cryptogram creation requirements:
1) card creation time, the token issuer authority (card network) contains an issuer master key for a "tokenized" BIN.  The master key for the "tokenized" bin is used to create a "tokenized" Unique Derived Key (tUDK) and "tokenized" Personal Account Number (tPAN) for each "tokenized" card when a Token Requestor requests a token on behalf of a card issuer.

2) Also at card creation time, this new "tokenized" UDK and "tokenized" PAN are delivered back to the Token Requestor

3) Now from a token requestor perspective, it is business as usual for tokenized card personalization.  This data is injected to the tokenized card just like a non-tokenized card.

4) A LUK is created PRIOR to transaction time:
   a)  Tokenized UDK in the card + ATC used to create the tokenized LUK (AKA Session Key, or one time use key)
   b) this LUK can be exposed to the mobile device (in apple case, the calculation of the LUK or similar key can be created inside the SE of the mobile device)

5) At transaction time, the cryptogram is created:
   a)  Tokenized LUK + terminal UN (POS data) used to create final cryptogram returned to the POS for processing

Have a look at how the Apple Pay system works during payment time:


And obviously, the mirror transactional sequence for the Android environment:

You will notice that the net result from the reader perspective is identical in both cases; "Tokenized Data" as described above.  The Android app and cloud based secure element, however, must work together throughout the life of the app on the phone to produce this result.


What tokens solve!:

Legacy Processing:  The main thing, in my eyes, that tokenization solves is the backend processing changes.  The HCE side of the equation requires, for some card networks, new Cryptogram calculation specifications to be processed because the cryptogram calculation process is forced to be changed.  i.e. intro to CVN 43!

Believe it or not, this is probably the biggest driver for tokenization because it is faster to build the tokenization engine and allow it to validate and convert the new cryptogram to an older version than it is to go into the old old old old (say it one more time...old) processing houses that are running Commodor 64, pascal, and big tape drives and get them to update the cryptographic algorithms on the HSM.  So, both VISA and mastercard can just as easy validate the CVN 43 CBP cryptogram just before the service de-tokenizes it.

Firewalling Transactions:  When a token is created, it is implied that the tokenization engine will always have to de-tokenize prior to processing the transaction,  with that, obviously coves verification of the token.  This is a perfect opportunity to build in transaction processing rules for that token such as:
1)  Card present only transactions (this token must ALWAYS contain a cryptogram with it)
2)  Use this token at ONLY these particular merchant IDs
3)  This token is ONLY valid for transactions within a 90 day period!

Translating to Card On File:  Major wins for Apple, Google, Amazon, and anyone else who has scores of cards on file buried in their datacenter.  Not only does tokenization allow you to translate to an existing bank account.  As displayed by Apple, it also allows you to translate a token to an account that may then represent one of many Cards On File for a particular google, amazon, or apple account.  Potentially this allows lower than Card Not Present rates for internet based transactions.

Tuesday, July 1, 2014

Host Card Emulation Series: HCE Virtual Card Life Cycle Management

HCE has introduced a new and powerful way to create, issue and manage virtual cards stored in the cloud. The value of HCE is clear but with that recognition comes a great deal of other questions. One of the most common questions is that surrounding virtual card life cycle management. This blog post will discuss one tools made available by SimplyTapp to manage your virtual card in the cloud in the SimplyTapp system.


SimplyTapp offers STBridge as tool to manage card life cycle. STBridge allows an issuer to connect to a virtual card instance in the SimplyTapp cloud.

STBridge is used to communicate APDUs, and other GP commands, to a specific virtual card residing in the cloud platform. STBridge supports standard GPJ shell commands.

STBridge packaged as an executable jar (STBridge) and can be executed in the following format:

java -jar STBridge.jar -ck consumer_key -cs consumer_secret -at access_token_to_card -ts access_token_secret [-s jcsh_script_to_run

STBridge Paramater list:

-ck the issuer consumer key
-cs the issuer consumer secret
-at the card access token
-ts the card access token secret

There are various ways for obtaining the parameters from a virtual card in cloud needed to execute STBridge.
This example we are we are working with a previously create virtual card.

Managing An Active Card

Appending scripts to the STBridge.jar executable file allows one to manage card life cycle. The following are examples of how to manage card life cycle.

Card is personalized by running a personalization (perso) script.
After perso script is executed, the card is in activated state.

Post card personalization, you can connect to card and  run any various card management scripts. Activating an activated card does nothing and deactivating a deactivated card does not change the state of the card, but scripts will execute.
The following are examples of executing card management scripts on a  active virtual card in the cloud.

Deactivate Card.

vcbp_deactivate_card.jcsh is script to deactivate the card. 
After running the script, the card agent is disabled from performing contact-less transactions.  







Activate card

vcbp_activate_card.jcsh is script to activate the card again. 
After running the script, the card agent is enabled to perform contact-less transactions. 

Terminate card

vcbp_terminate_card.jcsh is script to terminate the card.
 After running the script, the card agent is disabled from performing contact-less transaction. The card agent does not load anymore after refreshing/restarting the wallet. This is like a kill switch, the state cannot be changed from terminated.  

Running vcbp_terminate_card script updates the card state in the database to "dead". 
Once a card is terminated it is marked as dead and can not be recovered to active state from  the data base.

The complete STBridge tutorial can be found at:  http://wiki.simplytapp.com/utilities-resources/stbridge/stbridge-guide

Wednesday, April 16, 2014

Host Card Emulation Series: Google Cloud Messaging

Notifications can be an integral part of securing cloud based payment transactions.  Most mobile OS platforms support notification resources that can be leveraged by the platform developers for different reasons.  In the case of cloud based payments, notifications can be used to help secure and enforce authentic transactions at the POS.

The only relevant mobile OS platform at the time of this publication that supports payments that are accepted by existing mainstream acquirers is the AOSP or Android.  HCE (Host Card Emulation) was released inside Android 4.4 last October, so this blog post will focus on using Google Cloud Messaging or GCM.

An overview of the GCM architecture:

As you can see above the GCM and mobile device form an independent channel from the application itself.  This is done because Android OS manages registration of any particular application and therefore managing the communication with that registration which includes OS and device level security precautions.  

For a third party system to send a notification using GCM, the system follows step (a) above and that notification message is expected to be delivered using GCM channels, that is it.

This architecture can be used as a security measure to protect data that is ultimately relayed to a POS from a mobile application.  This simple diagram can indicate how payment transactional data can be protected using 2 different delivery channels
As you see above, the message that is to be delivered to the mobile application is split and actually delivered over 2 different channels.  So now with contactless or EMV (Cloud Based) credentials, payment information can be protected by these means:

1)  Dynamic Transaction Data:  each transaction data delivered to the POS is dynamic or changing from transaction to transaction so that a single transaction data can't be used more than one time

2)  2 Channel Delivery:  each dynamic transaction data above is split and delivered to the mobile device using SSL as one channel and GCM as a separate channel


Using GCM with SimplyTapp Platform

The example below provides a hands-on approach to accomplishing these tasks on the SimplyTapp platform.  The platform has Notification messaging built into it so that you do not have to concern yourself with the technical details of delivering messages over the network.  The interface abstracts the complexity and simply offers a "send to agent" api taking a single message as a string from the card applet service api framework.  This message has a known destination of the matching card agent for the card applet service.  The SimplyTapp platform handles all the routing and delivery to the proper place.

First things first, After downloading the IssuerSdk, unpack it, and go into IssuerSdkBundle and edit CardAgentTesterApp/build.gradle directory and make sure the agentToTest flag is uncommented for "CardAgent-GCM":

//
//  Swap the line below if you wish to test CardAgent-PayPass or
//  CardAgent-VisaMSD-SwipeYours instead of the CardAgent directory's code
// 
//def agentToTest = "CardAgent"
//def agentToTest = "CardAgent-PayPass"
//def agentToTest = "CardAgent-VisaMSD-SwipeYours"
def agentToTest = "CardAgent-GCM"


then build for eclipse:
> gradle eclipse

CardApplet service:

Import CardApplet-GCM into eclipse as a java project.  In the CardApplet.java file look at the code:

private short ATC = 0;

public void process(APDU apdu) {
  // Good practice: Return 9000 on SELECT
  if (selectingApplet()) {
    //no perso required for this card, so enable on first select
    Calendar exp = Calendar.getInstance();
    exp.set(Calendar.YEAR, 2014);
    exp.set(Calendar.MONTH, 4);
    try {
      setStatePersonalized("5413123456784800", exp, """");
    } catch (IOException e) {
    }
    return;
  }

  byte[] buf = apdu.getBuffer();
  switch (buf[ISO7816.OFFSET_INS]) {
  case (byte) 0x01:  //command to send a message via GCM
    short len = apdu.setIncomingAndReceive();
    //convert bytes to ASCII
    byte[] bytes = new byte[len];
    Util.arrayCopy(apdu.getBuffer(), (short)5, bytes, (short)0, len);
    String msg = "";
    try {
      msg = new String(bytes, "UTF-8");
      //echo back the Google Cloud Messaging Notification
      this.sendToAgent("Applet Message No.: "+ATC+"\nData: " + msg);
      ATC++;
    } catch (IOException e) {
    }
    break;
  default:
    // good practice: If you don't know the INStruction, say so:
    ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
  }
}

The code above in the applet is pretty simple.  upon select, it switches the state of the card to personalized if it isn't personalized already.  Also it supports only one command (0x01) that is a simple echo of an incoming data message to the GCM service.  The key method to send a message via GCM is :

sentToAgent("this is a string destined to my agent over GCM");

An IOException() may be thrown in the event that the card agent has not yet been loaded by the mobile application.


CardAgent:

Import the CardAgent-GCM into eclipse as a java project.  In the CardAgent.java file look at the code:

@Override
public void messageFromRemoteCard(String msg)
{
  try {
    //post the message to the app, get the response back to message approval
    postMessage("GCM message from applet:\n"+msg+"\n\nTry Again?"truenull);
  } catch (IOException e) {
  }

}

when the card agent receives a message from the GCM server, this method posts the message to the mobile application.

the next code effectively collects a message from the application user and relays that message to the remote card applet service :

public void post()
{
  //post a message to the app, get a response back to message approval with approval data
  //the message must be less than 32 bytes as defined by the 32
  ApprovalData.StringData stringData = new ApprovalData.StringData((short)0,(short)32);
  ApprovalData approvalData = new ApprovalData(stringData);
  try {
    postMessage("Enter A GCM Message"false, approvalData);
  } catch (IOException e) {
  }
}

@Override
public void messageApproval(boolean approval, ApprovalData approvalData)
{
  if(approvalData!=null && approvalData.getApprovalData()!=null)
  {
    ApprovalData.StringData data = (ApprovalData.StringData)approvalData.getApprovalData();
    if(data!=null && data.getAnswer()!=null)
    {
      byte[] msg = data.getAnswer().getBytes();
      try {
        connect();
      } catch (IOException e) {
      }
      try {
        TransceiveData batchCommands = new TransceiveData(TransceiveData.NFC_CHANNEL);
        batchCommands.setTimeout((short) 5000);

        // In this example we just pack a single APDU command to send a message after card reset
        // and select of applet
        batchCommands.packCardReset(false);
        // select applet
        byte[] apduData = new byte[10];
        apduData[0] = 0x00;
        apduData[1] = (byte)0xa4;
        apduData[2] = 0x04;
        apduData[3] = 0x00;
        apduData[4] = 0x05;
        apduData[5] = 0x00;
        apduData[6] = 0x01;
        apduData[7] = 0x02;
        apduData[8] = 0x03;
        apduData[9] = 0x04;
        batchCommands.packApdu(apduData, false);
        //send message to applet to relay over GCM
        short len = (short)msg.length;
        apduData = new byte[5+len];
        apduData[0] = 0x00;
        apduData[1] = 0x01;
        apduData[2] = 0x00;
        apduData[3] = 0x00;
        apduData[4] = (byte)len;
        System.arraycopy(msg, 0, apduData, 5, msg.length);
        batchCommands.packApdu(apduData, true);  //make sure this completes before disconnecting
        transceive(batchCommands);
      } catch (IOException e) {
      }
      try {
        disconnect();
      } catch (IOException e) {
      }
    }
  }
  else if(approval)
    post();
}

@Override
public void create() {
  post();

}

the transceive function sends apdu commands to the card applet service for processing and the payload of the second APDU indicates the message to send in ascii format from  data.getAnswer().getBytes();


Running a test:

Now, let's try it out.  Import CardAgentTesterApp into eclipse as an android project.  After import is completed, browse to the com.simplytapp.config.Constants.java file and adjust the contents to match your PC settings that are running the CardApplet simulator when you start the card applet:

package com.simplytapp.config;

public class Constants {

    /*setup to communicate to the remoteSE simulator
     * make sure that you have the IsserSdk simulator 
     * running in order for the cardAgent to connect to it.
     * It is important that if you are using the same eclipse
     * client to run the SESDK as this card agent project that
     * you run the SESDK NOT in debug mode as it can tend to
     * slow the response from the SESDK down to non-realistic
     * latencies.  anyway, adjust the ipaddress and port 
     * for the running SESDK below accordingly for your environment
     */
  //address of a running SE simulator
  final public static String ip="192.168.1.66"
  //port address of a running SE simulator
  final public static int port=3000;            


}

Also, make sure your mobile device has WIFI on and is connected to your internal network so that it can reach the simulator config as defined above.

Next, you start the CardApplet project inside eclipse which will prompt you to enter commands in the command window.  First highlight the project "CardApplet-GCM" and click the debug button.  You may have to select the main class for the project.  if so select "com.simplytapp.cardwrapper.CardWrapper".  You should see this in the command window:

# SimplyTapp simulator running on port 3000
# gpjNG connected on port 3000
# Connected to card NFC interface
# using gpjNG!
# type: help
# to get started
#
Found card in terminal: SimplyTapp
ATR: 3B 00 
>

at the command prompt enter:

>/card
ATR: 3B 00 
Command  APDU: 00 A4 04 00 07 A0 00 00 01 51 00 00 
Response APDU: 6F 0F 84 08 A0 00 00 01 51 00 00 A5 04 9F 65 01 FF 90 00 
(16 ms)
Successfully selected Security Domain GP211 A0 00 00 01 51 00 00 
>auth
Command  APDU: 80 50 00 00 08 F4 AA A8 1A ED CB 4C 84 
Response APDU: 00 00 00 00 00 00 00 00 00 00 FF 02 00 00 6C 55 44 79 7A 91 94 AC C7 A2 F3 8D E7 1B 90 00 
(27 ms)
Command  APDU: 84 82 00 00 10 10 2F AA 11 12 B3 0C 93 52 3C 41 C3 46 65 5C 92 
Response APDU: 90 00 
(6 ms)
>install -i 0001020304 |com.st |CardApplet
Command  APDU: 80 E6 0C 00 1E 06 63 6F 6D 2E 73 74 0A 43 61 72 64 41 70 70 6C 65 74 05 00 01 02 03 04 01 00 02 C9 00 00 
Response APDU: 00 90 00 
(17 ms)
>exit-shell
exiting shell, leaving port open

this installs the new applet as AID 0001020304 which is the proper AID for this demo.  after installation you will see that we exit-shell which will leave the simulator running and ready to connect up to the card on the port 3000 as shown above in this configuration.

after the simulator is running the card applet service, you can then run the card applet tester app on your device.  

Once the app starts, you should get a prompt like this:  


After clicking the "Ok" button, the text will go to the card agent which will connect to the remote card applet and send the message to the remote card applet.  The card applet will then, in turn, add the message counter information setup in the example code to the message and send the message to GCM for delivery back to the card agent in the mobile application.  So you should end up seeing a full circle message delivery and notification from your mobile device that looks like this:


This test can be repeated as long as you like and it's only purpose is to demonstrate how to use GCM to transport information from the remote card applet service to its card agent.