Why all the fuss about HCE?

[Dave Birch] First things first. Why is everyone in our cozy corner of the transactions treehouse asking about Host-Based Card Emulation, HCE, all of a sudden? HCE is quite simple: it means using the NFC interface on a device (a PC, a mobile phone, a car, whatever) to allow the device to be a contactless card so that you can make a payment (or present a ticket, show an ID card or a million other things). If you want to make your phone be, for example, your Barclays debit card then you have to overcome two problems: first of all, the phone has to store some security information and secondly the phone has to be able to send this information through NFC. Until recently, both of these things were difficult.

• The security keys on your debit card are very valuable, which is why they are stored in a high security tamper-resistant chip on your debit card, so if you wanted to put them in a phone you had to put them in the high security tamper-resistant chip that talks to the NFC interface on your phone: the secure element (SE). Either the operator SE on the SIM card or the manufacturer SE in the handset.
• Even if you did want to take the risk and put your security keys in the handset, the terminal couldn’t talk to them because when you tap your phone against a contactless terminal in Marks & Sparks, the data is sent to the SE and not to your app.

Now, you could get round this by patching Android using the CyanogenMod variant as SimplyTapp have done, or by using any Blackberry 10 phone. And, indeed, that’s what we’ve been doing for the last two years when, for a variety of (legitimate) reasons to do with testing, prototyping, demonstrations and just showing off, we’ve loaded the keys into the handset to execute payment transactions without using the SE. In an operational service, however, you wouldn’t want to load quite the same security information into your mobile phone as you have in your chip and PIN card (because, as noted, the chip on the chip and PIN card is secure and your mobile phone isn’t). What you can do, though, is load “limited” versions of the security information into your mobile phone. Information that can only be used for a day, or for transaction, or in a specific merchant or whatever. Let’s call that information a “token”.

The mobile phone security environment is very different from the card security environment. The payment application in your card contains the security keys that must be kept secret for the lifetime of the card, even in the face of an attacker with huge resources and unlimited physical access to the card. The payment application in your mobile phone contains keys that need only live for the lifetime of the token and need only withstand software attacks.

This generic class of solution (which we started calling NO Secure Element, or NOSE, transactions) was well-known to our clients because we showed it to them and started working with some of them. In February of this year, Bankinter in Spain became the first European issuer to announce an operational NOSE-style service, which we commented on at the time.

All NFC-enabled digital wallets require access to a secure element on the device

[From Visa’s plan to spur NFC mobile wallet adoption may hit a snag | Mobile World Congress – CNET Reviews]

This is not true, but it has been taken as read by the industry. Hence I was surprised that one announcement didn’t attract more attention.

Spanish banking group Bankinter has developed an NFC payments solution that works without a secure element.

[From Bankinter develops NFC payments service that eliminates need for secure elements • NFC World]

This is huge

[From Did anyone notice? There was just an NFC earthquake]

So why now? After all, Consult Hyperion has been writing HCE software since 2007 without much fuss. In fact, here is a video of an HCE EMV transaction recorded almost exactly six years ago!

Well, as we told our clients, the new version of Android includes HCE so, with apologies to our friends at Blackberry, this now makes NOSE mainstream. In fact,

A detailed guide to Android 4.4 KitKat’s support for Host Card Emulation (HCE), which enables NFC payments and other secure services to be delivered without the use of a secure element, is now available on the Android Developers website.

[From Google posts HCE guide • NFC World]

So why is this a big deal?

And a representative of MasterCard, James Anderson, said he believed host-card emulation might help break the logjam now blocking rollouts of NFC. Sometimes called software emulation or “secure element in the cloud,” host-based card emulation–known by the abbreviation HCE–also could potentially use the trusted execution environment in place of secure elements, say some observers.

[From SPECIAL REPORT: Google Backs Host-Card Emulation, but Visa and MasterCard Could Hold Keys to Success – BayPay Members Blogs]

Including, for example, me. Although I should note, rather nerdishly, that SE-in-the-cloud and NOSE are, strictly speaking, different solutions. But never mind. James is a very smart guy, and if he thinks HCE might break the “logjam”, I take him seriously.

But it is far from certain how it will all work. One of the reasons why banks weren’t that keen on the SIM-based SE in the first place was that it meant that someone else (ie, the mobile operators) controlled the channel. Why would they dump SIM-based SE under operator control for a handset-based Trusted Execution Environment (TEE) under handset manufacturer control when they can have a cloud-based SE under their own control? From their point of view, being at the mercy of Apple or Google is no different to being at the mercy of Vodafone or Telefonica. A more likely scenario is that the TEE is used for secure authentication (perhaps inside a FIDO framework) by HCE apps in the handset. Then, much like Apple’s use of the fingerprint sensor for purchasing on iTunes, the TEE would provide added security and convenience, but apps could still work without it (maybe you would have to type a longer password, or answer a question and give a voice response to something, or whatever, instead of PIN entry or fingerprint touch.

While the schemes have yet to give any definitive ruling on NoSE (No Secure Element) payments with EMV (and remember, there is already the live service with Bankinter in Spain), it is unlikely they will rule against it. As Karen Webster noted with characteristic accuracy in her comments on the topic, their is an under-the-hood synergy with tokenisation, since the limited use or special security keys that I talked about above are, in fact, tokens. Therefore, what it makes sense for the schemes to do is integrate HCE into their tokenisation roadmap and — and I’m saying this only as an informed observer, not using any “inside information” — set out basic security requirements that will be needed for certification. This can clearly be done: I already have a PingIt app on my iPhone that gives direct access to my bank account. If it is possible to find countermeasures that give the right risk analysis balance for that app, it is possible to find countermeasures for a Visa, MasterCard, Amex or Discover app with API interfaces to retailer apps.

This ail radically reduces the cost of development, deployment and use, as it’s goodbye to the Trusted Service Manager (TSM) and the operator’s “apartment model” of renting SIM space.

[From NFC aftershocks]

So having said all of this, let’s get back the basic question: what does NFC change? In the UK, where there are lots of contactless payment terminals and lots of Android mobile phones, it means that banks, retailers, transport operators, games companies and other can add NFC to their apps and make for a more attractive customer experience. It means that mobile operators will have to work harder to add value to their NFC propositions if they are to recover their investment in SIM-based SEs and TSMs. A place to start, and I will be talking about this at the Samsung Developer Day 2013 next week, will be to add convenience to apps and then add security. Let me give you a hypothetical example: I’ve written before that I like the PayPayl Here app, but I’d like it more with added NFC sparkle.

Yes it is better than NFC is, but it’s not better than NFC could be.

[From Back in the real world (well, West London)]

I meant that apps could use NFC for convenience, not for security, so for a customer with an iPhone, they can run the PayPal app, select the merchant and then check in to PayPal Here and pay. It will all work perfectly. A customer with a Samsung S4 could just tap. But because of HCE apps can use now use NFC for security too. They can load payment scheme applications, yes, but also ID cards and travel tickets and corporate access and event management and and and…

A retailer and a bank, for example, might integrate payments via HCE into the retailers own app, bringing together Bluetooth Low Energy (BLE) and NFC to provide a seamless customer experience. You walk into the store and get personalised attention through the app – which now knows which shelf you are standing front of – and the app downloads a payment token from the bank via mobile, wifi, BLE or whatever. When you’ve finished shopping you tap and pay at the unmodified POS terminal using that same retailer app which now feeds the bank token to the POS across the NFC interface. An HCE/NFC/BLE world seems rather attractive from a consumer experience perspective.

NFC just got a lot more interesting again.

These are personal opinions and should not be misunderstood as representing the opinions of 
Consult Hyperion or any of its clients or suppliers