Host card emulation (HCE) was invented back in 2012. It was supposed to do for NFC on Android what Apple Pay has done for NFC in the iOS ecosystem. But it’s taken longer, a lot longer, for a robust Android-based NFC capability to get deployed. In this conversation with HCE inventor Doug Yeager, CEO of SimplyTapp, we review how HCE works, what it requires, and take a look at why it’s taken so long to gain momentum. The good news is that momentum is increasing with a growing set of HCE technology providers pushing it forward and, it appears, a pipeline of HCE-based apps on the way.
Read the transcript below the jump.
Payments on Fire 23
SimplyTapp
George: Welcome to another of Glenbrook’s Payments on Fire podcasts. I’m George Peabody and my guest today is Doug Yeager, who is CEO of SimplyTapp, the inventor of host card emulation, the backbone of what powers NFC security in the Android world. So welcome, Doug, glad to have you here.
Doug: Great to be here, George. Thanks for having me.
George: Thanks for coming on. So look, as I told you at the beginning of our call, I’m the Android holdout at Glenbrook, so being able to use my MotoX for payments is important, and host card emulation (HCE) is the technique that is going to make that happen and I gather is already making that happen, is that right?
Doug: Yes, it’s starting to in some places. Unlike the iOS ecosystem, there’s a lot of options on Android, so getting alignment from the card issuers to the ploy is always going to take a little bit longer, but definitely getting there. I think we’re going to see some commercial launches real soon. Few people know this, but Google Wallet was actually a kitkat launch, they leveraged this card emulation really out of the gate. So, they’ve had their commercial launch where you could tap and pay.
George: My Google Wallet is powered by host card emulation. So let’s just go back to basics for a second. So host card emulation (HCE), how does it work? My understanding, and I think I understand a fair amount about it, unlike iOS and some of the classical NFC deployment mechanisms, it doesn’t rely on hardware in the same way. It doesn’t rely on the storage of payment card credentials in a secure element that is stored in hardware on my handset and protected. What you’ve done is something different.
Doug: That’s right. So, it’s important to know why or the reason and rationale behind why host card emulation exists. Primary reason is, with Android, hardware dependencies can pose a problem, because Android, being an open operating system, you have a lot of players involved. You have the MNOs in one corner, you have the OEM’s in another corner, and then you the specification delivers and operating system delivers, Google and others. If the total application relies on more than one of those parties, it’s really problematic from the market business standpoint. The idea of host card emulation is to remove any hardware dependencies on a mobile phone, but still be able to deliver payment credentials to all those existing point of sale terminals that are here in the marketplace.
George: What that tells me, is that we’re using the NFC radio that’s in the handset, and that talks to the good old contactless interface to the point of sale terminal.
Doug: That’s correct.
George: So, baby-step us through what PAN, what card number, what token is being transmitted across that radio link, and then, what else is going on in terms of card numbers?
Doug: Great. So, in host card emulation, before their tokenization or rules around it, essentially was defined as emulating a card, and the data that was traversing the HCE channel could in fact be identical to the data that traversing from a plastic EMV card or the data coming out of your iPhone 6, really no difference. The technology is not limited for what kind of data it can deliver.
George: And where was that data store?
Doug: Sure, great question. So, with that exposure with what started to define a new category of security specifications, and these were launched in February after Kitkat on both card networks by Mastercard and Visa. They introduced this new architecture we’re about to talk about called cloud-based payments. Effectively saying, “Hey, we’re ok using that HCE or NFC radio channel to transport data. What we really have to figure out is where do we store the sensitive keys that have, in fact, generated that data that will be transferred.” That’s really where the change is, it’s between something like iPhone 6 and the Android platform. The iPhone 6, they have the luxury of being able to store and generate that data in the secure element on the phone. In the Android world, because like I mentioned, removing the hardware dependency or the secure element from the equation is important, you have to figure out, where am I going to store and generate this data that will be transmitting across the phone to the point of sale terminal. That really has been defined by the community, i.e. the card brands to be a cloud based payment instrument. So, George, if you think about it like this, you have your card master key, which is this sensitive nugget that goes in that secure element on the iPhone 6, where is the most secure place to store that very sensitive thing that will generate all my transactions to the life of this card in the Android world. It has been kind of defined and agreed to that that would be the cloud environment.
George: And who is generating that key?
Doug: That would be the responsibility of the cloud service that would be connected to the host card emulation applications that are on the phone.
George: Is that SimplyTapp?
Doug: SimplyTapp is definitely one. We have other competitors that are similar to us, I can name them: Bell ID has a system that does very similar stuff, Sequent Software is in the space, Carta Worldwide, and of course, we have the big competitors like Mastercard and Visa who have the vaults that generate this data. I expect Gemalto and G&D will also get into this business. So, there’s a number of choices there if you’re a card issuer, and in fact, if you want to do it yourself, there’s rules and specification that will enable you to build it yourself.
George: So, the encryption key is stored in the cloud. What about the card numbers and now we’ve got EMV code tokenization?
Doug: Great. I think you’ve gotta address tokenization, let’s call it card present payment data. First, understand that because essentially I’m going to get to the argument that the card numbers themselves are relatively benign. So the 16 digits that everyone is worried about and the expiration dates that connect to the 16 digits and the HCE and NFC world are relatively benign. The reason that they’re benign is, if you were to even pass it in the clear, write them down on a piece of paper as you saw them coming out of a NFC radio, there’s no real threat factor; because, if you took those numbers and went to amazon.com, for example, and tried to make an internet purchase, they would effectively fail. They would fail because of what people are calling tokenization. What that means, essentially, is if I have a pan, that 16 digit number that everyone is so concerned about, and my backend authorization can indicate pay, that is a special kind of 16 digit number that also requires cryptographic information with it. Well, as a person snooping the NFC radio, I will only be able to relay those static 16 digits, I won’t be able to relay the cryptographic information, because it’s already been used. So those are really the rules around the new security model that people have labeled tokenization.
George: And that really comports with how the EMV card works.
Doug: Yes, very much so. I think the key is that in the past, there’s been this idea of a card that you have in your wallet, it’s got a chip on it, has 1 pan on the front with an expiration date that a lot of people use for internet shopping, and sometimes there has been the idea that that same exact pan number was inside the chip card and that you had a choice. Either you could use the pan number for card not present or for in fact, card present. That option has gone away; there is no option to do that anymore. Now, it’s a requirement that the pan number inside the chip must in fact be different so you can track it, relative to the pan printed on the front of the card.
George: Of course that has some complications with product returns, depending upon how the merchant works.
Doug: Tokenization platforms are supposed to manage that translation between the tokenized pan and the card number that is backing that transaction. So even though the return process, that mapping takes place.
George: From what you’re seeing out in nature, how’s that working out?
Doug: I don’t know. That’s a great question. This would be a question for the iOS guys. They have the most experience now in this space, I assume they wouldn’t have launched the product unless that was navigatable. I’m sure they thought about that ahead of time. But in fact they’re using the card networks TSP services that would ultimately perform the mapping back to the bank.
George: So, those are the network tokenization providers.
Doug: That’s right.
George: When I don’t have connectivity from my mobile handset to the network, and I’m at the back of Best Buy somewhere and the mobile reception is bad, take me through that process.
Doug: This is really a core difference between generating a cryptogram from an iPhone 6 device and generating a cryptogram from now the HCE or cloud based payments scenario. Real early on, SimplyTapp realized this. Three years ago we introduced host card emulation, one of our first tests was simply duplicate an exact secure element transaction, the only difference being the secure element was in a server a long way away. We thought, “hey this would be a good idea, lets make it so that when I present my phone to the point of sale terminal, I open up a real time connection over a network and trick the point of sale into making a really long request back to my secure element in the cloud”, and we did this. It’s physically possible. What you ultimately have, is a tap and hover experience which is awful. So, technically you could solve the problem, and we realized real early on that from the user experience standpoint it’s just not going to work. It went beyond that simple test, it goes to other tests where there’s no connectivity at all and then you can’t say, oh sorry user you can’t make a payment.
So, what happened, ultimately, we have some really critical IP in this area, time will tell how it all plays out, but effectively, you had to introduce this idea of a temporary cryptographic key. It’s kind of like an intermediary step between a card master key and a cryptogram. So, the idea is, you calculate the cryptogram in 2 steps. You have part of a calculation happen in the cloud that is not time dependent and can migrate itself to the phone over the course of 8, 12, 24 hours not at tap time. Then you have that, what I would say, a lower risk key on the phone, it’s not a card master key, you can’t continue to reproduce cryptograms out of it, but you can create 1 or a few cryptograms from this temporary key, and it’s residing on the phone and it’s vulnerable to all the things that may attack Android phone, but the industry has said, “hey, that’s a much lower risk and we’re ok with that”. So that key is kind of residing on the phone and available at all times, locally, to complete the cryptogram transaction when you tap the phone.
George: You’re assembling a good cryptogram and then flowing it through and it gets to the issuers backend and it makes an authorization decision based on that and all of its other risk parameters.
Doug: That’s right. So they justify this by using this risk mitigation tactic.
George: How’s that working out?
Doug: There’s not enough data out there, so I would probably argue long-term, there’s much lower hanging fruit from a security standpoint than transactional security, that’s what we’re talking about here, like what’s happening during a transaction, what are the card data I’m moving through that transaction, someone trying to act a cryptogram, those are all pretty high, I mean you wouldn’t want to go after…
George: High effort for the fraudster that doesn’t scale.
Doug: If I’m a fraudster, I’m going to do what I did to Apple Pay. I’m going to do social engineering and I’m going to hijack someone’s card from the beginning and go make payments. That’s what I’m going to do. I think that’s where people like to talk about the transactional level fraud a lot, but realistically, I don’t really see it as an impact. It’s a big talking point, because it’s a core difference between secure element and cloud based payments, people like to really highlight it, but we’re kind of missing this big torpedo hole of really onboarding and provisioning in my mind.
George: That’s always an issue regardless of the payment mechanism of that onboarding process, being a weak spot. So, Doug, tell me about how HCE, what’s the uptake? The question rattling around in my mind, is why haven’t I seen a bunch of issuers payment enable their mobile banking app? It’s such an obvious thing to do, why doesn’t every Android user have that now?
Doug: On the inside, there’s lots and lots of activity, lots of projects being scoped out and designed and built. My answer to that question is really time. The reason is, we have a virtual launch thats pretty imminent and this one particular issue, what it basically does once a year APK updates. Now that’s just their nature, so they will release mobile banking on a certain pre-fixed schedule, and for them to make an exception for a payment instrument is just not a high enough priority.
George: They did it for Apple Pay.
Doug: Well, they didn’t. They handed over everything to Apple, and Apple actually did it. What we’re talking about on Android, I think, is the option to either be in the aggregated wallet, like the past on the Android system, now Android Pay Wallet, or you have the opportunity to actually just like remote check capture is available inside mobile banking, you can update your mobile banking app to now also do the payments component.
George: That’s a combination that makes all kinds of sense to me, just from a brand reinforcement. It keeps the bank’s’ brand and value in front of the card holders.
Doug: Absolutely. Obviously, that would be the vendor play, that would be the SimplyTapp’s, the Bell ID’s, the Sequent’s are really pushing towards keep your brand at home, make this feature inside of mobile banking, versus an aggregated system like Wallet or now the Android Pay app.
George: You mentioned something about doing work beyond transactional security. Are there some other places where SimplyTapp is active? Other use cases?
Doug: We try to stay out of the provisioning component because we’re working with banks to implement this into their mobile banking, a provision and component is really native in that mobile banking app. So our argument would be, instead of trying to push tokenization to somebody’s third party, you’ve already got this bottled up and very secure in your own bubble app for provisioning you already know your customer. Don’t create this security poll by handing this to another third party, which is what happened and where the fraud is coming from, keep it local, keep the brand in your customer’s eyes, and allow them to make payments. We wouldn’t really try and solve the problem ourselves, we would have our customer solve the problem by effectively not aggregating their cards with other banks.
George: So what I think I heard you say, because you already know them and you already have a relationship with mobile banking, you can push provision, and just make it a “hey, would you like to make payments with your mobile banking app.”
Doug: Yeah, it’s real simple. So think about it, mobile banking gets to eyeballs a week roughly from their users, it’s very simple to throw a notification up on the next update that says “Your app is now updated. Your phone is one of the types that can pay your favorite stores with, check this box if you want to do that.” It’s pretty much that easy, and they’re off and rolling, versus the red path, green path, blue path, whatever that was for iOS, and trying to simulate that in the Android world in some sort of aggregated system.
George: So, Doug, we’re about out of time, but besides those apps to show up, what should we be looking for when we start saying HCE is permanent?
Doug: I think the rollout is going to be really important and critical, Apple’s done a great job of introducing tap and pay to the general consumer, and how I work with my phone. I think over the next 12 to 24 months you’ll see kind of a dual rollout, you’ll have some coming out on Android Pay, but I don’t think anyone will launch on Android Pay without an Apple alternative for mobile banking. So you’ll kind of have a mishmash of Android, where lots of apps have the ability to pay. That’s why they built the tap and pay menu. iOS doesn’t have a tap and pay menu, it’s Passbook, that’s it. In Android you’ve got the operating system that allows you to select your favorite app to pay with and that could be Capital One’s banking app or that could be Android Pay or maybe Royal Bank or somebody like that.
George: So I wonder if I install an app, does it have the ability to change that default setting.
Doug: It does.
George: Good, that’s exactly where I was headed.
Doug: It actually throws a dialogue up that says “this is your default payment app, do you want this to be?” and they can bug you as often as it wants. If it bugs you too much, you’ll probably throw the app away, but it’s the same idea. Is it Chrome, or is it going to be IE?
George: I love the free market tactic, it can be great, but it can also be very annoying.
Doug: Android does a really great job of that, that’s the primary difference between Android and iOS. iOS provides a really good experience for you, but there’s no options. On Android, it lets the market decide. That’s kind of the space we’re in right now.
George: Well, great. Doug, thanks very much. It’s been really interesting and thanks for the explanation of HCE.
Doug: Absolutely. Thanks, George.
