Issuers … give HCE a shot now

Imagine expanding your existing bank mobile app to do card emulation.. with NO TOLL to the TSM or carrier.. you are in complete control. A project which should be sub $1M AND NO CONTRACTS!!

The only current dependency is Android 4.4 with an NFC or HCE capable handsets.. with over 40 new OEMs  handsets shipping in next few months.

I’ll fill this blog out in more detail, but here are the key actions

  1. mobile app development
  2. workout how your static signing keys can be deployed. SimplyTapp has solution in place (https://www.simplytapp.com/)
  3. Test with legacy embedded handsets and new OEMs to establish your test pool
  4. Create a new consumer registration service where virtual keys are provisioned to application (again SimplyTapp has this)

Google’s phones are ringing off the hook. Retailers, loyalty providers, Banks are all working to leverage this new approach. The Android team can help you with the APIs.. but recommend you get in touch w/ SimplyTapp today

(I have no current relationship with SimplyTapp… but think it is something that makes sense as hardware evolves to software)

– Tom

 

Advertisements

12 thoughts on “Issuers … give HCE a shot now

  1. Who needs HCE (or even normal SE-based NFC) if there is no retail infrastructure?.. All dressed up and nowhere to go…

    MA said (twice!) today at Cartes in Paris that they are firmly committed to SE-based solutions… Top French and Dutch banks said they will look into HCE, but don’t expect it to be fully certified for… 5-7 years…

    Even for CP e-comm you need cloud EMV reader (we are preparing a demo with a major bank and a card network).

    If and when HCE is fully adopted, it does indeed represent a cleaner and simpler route. IF (!!) it proves to be sufficiently secure…

    • Every issuer in the country should be working on this. Let’s just say the race is on. There is going to be no issue from the networks around certification.

      • Derrick, read “HCE & Security” section of this document by G itself: http://developer.android.com/guide/topics/connectivity/nfc/hce.html#HceSecurity

        Then extrapolate that to the fact that any hole in OS security (i.e. a matter of time) would potentially expose the whole installed user base. Recall how quickly G Wallet was cracked when it first came out…

        “The core remaining piece is where you get the data from that you’re sending back to the NFC reader. ” That “piece” (called security) is “remaining” for a good reason…

        All HCE announcements were about bypassing MNOs and TSMs, not about “great technical solution”. Why nobody paid that much attention to HCE when it was offered just by BB, SimplyTapp and BellID? The “Google effect”. Call it “clout”, I call it “hype”.

        Why not simply store mag stripe data in the app and display it via QR – every POS supports that (and Starbucks showed it kind of works)?.. Apart from NFC interface, HCE approach is no different from that of MCX – who got Gemalto on board – think why (although Gemalto’s role is not clear).

        Google is a great company, but to think that they (or SimplyTapp or Bell ID) single-handedly miraculously solved the task of making s/w secure without h/w is naive… IMHO. I’d be glad to be proved wrong…

  2. Alexander,

    The security has many layers. The first layer is in encrypting the data in the virtual SEs and placing controls on how an application can communicate with it using keys, and then further encrypting the credentials that leverage dynamic data like EMV does today.

    This is no different than the TSM controlled SE except made slightly easier to interact with. Thinking just because the was SE on the SIM or being physically separate made it that much more secure.

    So assuming someone can capture the data, it will likely be encrypted including values that dynamically change, not to mention dynamic values issuers will place into the ARQ as discretionary data at the time of transactions, think GPS locations. The most US issuers will be online only to auth on EMV. This further limits the use case for the compromised data, if they were even able to defeat the first layers of security.

    The most meaningful layer of security will be in the dynamic updating of not just the dynamic values used in EMV, but the actual credentials in real-time via the bank’s mobile app that make anything you are capturing worthless in mere moments as the app is always connected and required to be used to conduct the payment.

    Static payment credentials are planned to be phased out. Dynamic tokenization of payment credentials is the future. EMV, TCH Secure Cloud, Etc… are all moving this direction.

    Now, in the event that every layer fails, in that extremely rare case, issuers will manage the risks using the tools they have already developed in their fraud shoppes to monitor, and detect.

    Imagine the savings alone on never having to issue a new piece of plastic, whether due to fraud or expiration. You just update credentials, the cost savings alone would dwarf any unlikely fraud losses.

    • Derrick,

      I can see your point.

      And I agree with you re dynamic values. However, security in that respect is not about the content (i.e. the values themselves), but “clonability” and accessibility of those dynamic values. If a mobile virus on my phone can access my dynamic credentials and use them (in a fully encrypted form) via a “virtual clone” of my phone, changing those parameters even every second won’t help much.

      A classic “man in the middle” attack where you do not need to read the underlying data, just use it when needed.

      GPS and other parameters of the so called “mobile fingerprint” can be spoofed/copied/replayed.

      As for the savings, the figures I’ve heard from the large banks re EMV cards are $3-5 max. Their overdraft or late payment fees are up to ten times more… Yes, a saving is a saving, but the “been counter” perspective does not always make sense. There is no doubt that updating s/w parameters is cheaper than issuing a piece of plastic. But could it be the case of “free cheese”?..

      • Here are some things to consider on the risk for cloning as it relates to physical retail payments with mobile devices using HCE/NFC, but are not exclusive to HCE.

        Location and DateTime based data are critically important as part of the risk mitigation strategies employed by issuers today.

        In a transaction there will be several of each conveyed to the issuer either as elements in the authorization process or in near-realtime made available to the issuers fraud management systems.

        Location Data
        1. Current Transaction – Terminal Location
        2. Current Transaction – Datetime
        3. Previous Transaction – Terminal Location
        4. Previous Transaction – Datetime
        5. Cardholder Demographics – Residence Location

        1-4 are typically employed to calculate distance and speed and determine if the second transaction is even possible and set various after action items.This item aren’t used exclusively mind you but typically employed successfully in combating the cloning of mag stripe cards. So the fraudster, for any given compromise will sometimes get his first transaction to work before the card is closed. 5 is supplemental data that with location trending is used not just on a per transaction to per transaction check is used so that transactions physically occurring somewhere else, like Europe are denied or blocked immediately after.

        Now with the mobile device, making a payment using the bank’s mobile banking app to effect payment with HCE/NFC will have additional information before, during, and after.

        6. GPS Location During Current Purchase
        7. Active GPS Location Reported Live from Mobile Device

        If the fraudster has a constant feed of the cloned credentials and spoofs everything perfectly, the terminal location and 6 – GPS location will not match or be close enough and the transaction will decline. The fraudster would have to have done all this and then be in the same vicinity as the actual cardholder.

        7 is gravy. Imagine both the fraudsters app and the cardholders app reporting locations at the same time. How fast do you think those credentials get blocked.

      • Thank you for the detailed explanation, Derrick. The fraud management system you described seems to be “card data” agnostic. If location-based defense works well (not to mention dynamic credentials), why bother with HCE in the first place?.. (or NFC for that matter – QRs are more ubiquitous for now)

        “Location velocity” check is indeed an effective tool, if implemented well at both ends. As for 6-7, GSP can be spoofed. Also, outside the US, many low-value c/less EMV transactions are offline.

        As for “fraudster […] will sometimes get his first transaction to work before the card is closed” – compare $20-30 loss for a given account with $3-4 cost of eSE…

        That’s before we open the e-commerce can of worms…

  3. Alexander,

    It is indeed card data agnostic. The question isn’t why bother with HCE or NFC but rather why not.

    For issuers with EMV apps, all they have to do is update their mobile banking apps to provision the eligible devices and boom anywhere EMV/NFC is accepted it will work. The part that people may have missed, HCE allows the banks mobile banking app to be a reader too, think P2P or merchant acceptance.

    HCE isn’t even really about NFC, HCE is storage of credentials, the mobile banking apps are about provisioning and dynamic updating of the credentials, and the communications channel is anything the device can leverage and the terminal can accept, with one significant added caveat.

    The communications channel must afford the ability for rapid two-way communications, the back and forth exchange of private-public key pairs to protect the credentials in transit. This is reason enough that QR fails, even aligning infrared between a mobile device and a terminal would be more effective.

    EMV has been adopted generally worldwide and is being slowly rolled out in the US. EMV/NFC is being pushed and adopted and it works with the infrastructures that have been built or are being built rapidly in the US. These infrastructures are built for EMV but are not locked into only EMV. They are being built to enable tokenization or dynamic credentialing for all kinds of payments. This includes e-commerce, which includes using a mobile device to hit an online retailer.

    If I was a betting man today, I would tell you that NFC or some form of it will likely win out with BLE or some other form of short range radio tech coming second. A lot has already been invested by the parties in the industry, and I see more and more tablets and mobile devices, that will be coming with NFC radios, being used as terminals.

    • Derrick, you touched an interesting point that shows where we see things differently. HCE is about attempting to secure “NFC chipset OS” channel, NOT about credentials storage (that’s what that “HCE and security” section of Google’s doc explain).

      G are saying HCE is agnostic as to where the data is coming from, i.e. where the credentials are stored. You cannot store anything *securely* in a phone’s (open) memory.

      If the proposed implementation does not require secure storage because of dynamic values, speed (?? – how does that help?!), etc – that’s another matter, but it’s not EMV as far as the current specs are concerned.

      Surely, the card schemes MIGHT amend specs, let’s wait and see.

      It’s not about NFC vs BLE vs QR, those are just comm channels. It’s about SE vs NOSE. Adapting NOSE requires significant changes to the current (standard) EMV flow. That will take time…

      • Alexander,

        HCE is about unlocking the NFC radio for use by mobile apps specifically but the larger implication and the reason for doing so grants the ability for mobile apps to provisions credential, while in general memory, “securely” for storage and updating. This is not the same as downloading a pdf to general memory.

        The question really is, is it secure enough and does it protect what is meant to be protected? My answer and what I am seeing from the networks is yes and it is secure storage. It is every bit as secure as physical SE leveraging TSMs and protects the funds held by issuers for consumers from fraud.

        The card association aren’t going to amend specs. The ones we already have work, and are acceptable. That is the beauty here. Specs defined. EMV apps exist. Provisioning is standardize. Control and security delegated. We are cruising to deployment from multiple issuers. Think a couple months max.

        EMV is a specification for credentials and how they are transmitted. HCE allows the storage of EMV credentials and then their transmission via NFC. The only thing stopping most issuers from doing this before was the toll and control that the MNOs were exerting. HCE is exactly about removing their control and giving to any mobile app.

        Perhaps this will help. A consumer can have multiple mobile banking apps that provision virtual SEs with their bank’s EMV credentials. Lets say Chase and BofA are loaded to the device. Chase’s app can use or control or transmit BofA’s credentials and vice versa. The consumer will open the Chase app to activate their Chase credentials for use, with mobile devices they don’t need to be constantly transmitting the way NFC via Chip Cards do.

        There is a flow difference when a physical SE versus a virtual SE is used, but it is only internal to the mobile device. The merchant terminal will never know the difference or care. The transaction flow continues to operate the same as a standard EMV transaction otherwise.

  4. Edit for this… to add NOT below

    Perhaps this will help. A consumer can have multiple mobile banking apps that provision virtual SEs with their bank’s EMV credentials. Lets say Chase and BofA are loaded to the device. Chase’s app can NOT use or control or transmit BofA’s credentials and vice versa. The consumer will open the Chase app to activate their Chase credentials for use, with mobile devices they don’t need to be constantly transmitting the way NFC via Chip Cards do.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s