What Google thinks about NFC is important

A couple of people asked yesterday about the comments from Google concerning “card emulation” in Android phones. The twitterverse had noticed these remarks from Nick Pelly, the Android lead for NFC, concerning the lack of API support for NFC card emulation.

The problem is that the hardware out there today, you know, if you buy an NFC controller, it typically is only going to be able to emulate one of those RF-level technologies. So as an application developer, you don’t know which — when it’s getting deployed to a phone, which one is on the phone. So I guess until we see the industry standardize around maybe one RF-level technology or until we see NFC controllers able to support multiple of those

[From Google raises concerns over the viability of NFC card emulation mode for mobile payments • NFC World]

At first I just thought… wow, that’s smart. If Android phones won’t allow ISO 14443 card emulation (which is part of the NFC standard) then that means that Visa and MasterCard won’t be able to use them for payments, thus locking them out of the POS terminals that Google is developing for retailers. As I thought about it, however, and actually read what Nick had said, I realised that I couldn’t understand his comments, since phones are perfectly capable of dispatching to different applications depending on which card they read, so I thought I’d go and ask a couple of the world’s leading experts on implementing secure NFC applications in mobile phones. Fortunately Stuart Fiske and Neil Livingston both work for Consult Hyperion, so it was easy to find them. They told me…

We know that NXP and Inside Secure NFC controller devices support A, B, B’ and Mifare, all on the same chipset. GP provides mechanisms to manage protocol conflicts, etc., when multiple applets relying on incompatible protocols are trying to be active on the interface at the same time.

I thought this must be true, since I had in my office a Nokia handset with NFC that supports both contactless EMV transactions and contactless Oyster (ie, MiFare) transactions and it worked perfectly. I read a little further, and once again became confused. Due to my lack of experience, I was unable to determine what this means:

Typically, the hardware is set up to do card emulation through the secure element. Right now, we don’t have any APIs to talk to the secure element. And we think that we probably won’t be getting APIs to do that anytime in the near future in the SDK.

There are a bunch of different reasons. Again, the secure element is a very limited resource. It can’t hold a large amount of data in there. And if we open it up to any third-party application, there’s going to be a huge resource contention over the secure element.

Additionally, to talk to the secure elements, even from applications on the phone, you need to authenticate yourself properly.

And if you improperly authenticate yourself a certain number of times, there are secure elements out there that will physically destroy themselves and can never be recovered. So that’s something that we really think would be a bad experience for users

[From Google raises concerns over the viability of NFC card emulation mode for mobile payments • NFC World]

I have absolutely no idea what he’s talking about. I have never heard of a handset secure element (SE) that will physically destroy itself if authentication fails. I’ve checked the SmartMX data sheet this morning and I can’t see any such logic.

If I put the wrong PIN into an EMV application in the secure element three times, it will lock and then require an over-the-air PIN unlock from the application issuer, but that’s a good thing. It’s certainly true that there’s a problem with secure applications controlling the screen and keyboard during authentication, but that’s because the Nexus doesn’t have any form of trusted execution mode and this is a well-known and well-understood (at least it’s well-known and well-understood by Consult Hyperion) constraint that feeds into the kind of risk analysis that we do for organisations who are thinking about developing transactional applications. The authentication itself is done within the SE, naturally, but you may have a virus that’s capturing the PIN, for example.

Meanwhile, I was thinking about the SE more. If I buy a Nexus S, how would an application provider request a Security Domain (SD) from Google? How would it be provisioned? Is Google building a Trusted Service Manager (TSM) to sell such a service? I haven’t got a clue. The guys told me (these are edited highlights, by the way)…

In J2ME, it’s typically the SE issuer (ie, Google, in this instance) that decides who can access the SE from apps in the phone, and sets up the access conditions on the SE to manage this (the ACF file). Essentially, what we need the Android stack to do is deliver what J2ME (and it’s JSRs) have been doing for several years now. That is, include APIs that provide the app with a mechanism to access an applet in the SE, and for Android to interact with the SE to manage access condition verification. You can’t block the SE if you can’t access it!…

…These comments from Google make it sound like Google won’t be doing anything with card emulation any time soon. If that’s the case, then what’s with all these stories about Google trialling contactless card payments in SF with MasterCard and Citibank, uing Verifone and Ingenico POS terminals? These POS terminals implement 14443 to read contactless cards, and I doubt that Google are going to develop custom terminals that implement P2P ISO 18000 instead. But who knows – it would be cool if they did…

…Perhaps the Android stack doesn’t need to implement card emulation mode if the underlying hardware implements it, i.e. if the NFC controller and SE together support 14443 and card emulation mode, then they can talk to the reader via the antenna independent of the Android stack. The stack needs to provide an access API to allow phone apps to access applets over the contact interface (if there is one, e.g. SIM), or the wired interface for embedded, or via the SD interface….

…So perhaps there is no need for a card emulation stack in Android after all? But we still need ot be able to switch the PN544 into card emulation mode and an SE access API supporting a decent access control mechanism…

That’s the actual problem, then. Developers can get to the SE interface but they can’t do anything with it (eg, load a payment card into it).

As of the 2.3.3 release of Gingerbread the Secure Element functionality has been enabled (but the API Hidden). You can confirm that there is a Secure Element (SmartMX) in the Nexus S just by looking at the debug log using adb logcat and switching on NFC via settings… That said I’m assuming that the keys etc are controlled by Google so actually doing anything with the embedded SE will be difficult/impossible at the moment.

[From Secure Element – SmartMX – seek-for-android | Google Groups]

What has happened is that Google used an NXP NFC stack when building the Android operating system image for the Nexus S, but switched off the card emulation using compiler switches. (There’s nothing to stop you, by the way, from recompiling the stack with those switches set to allow card emulation.) My interim conclusion is, then, that I have no idea what is going on. I don’t understand what Google mean and I don’t see how they can stop anyone from accessing secure elements. Sure, they can stop you for doing anything with the embedded SE (theirs) by not giving out any keys, but if there’s a UICC SE (from the operator) you can access that and if there’s an external SE (eg, a DeviceFidelity SD card) you can access that. If there’s no Google Android API elements for any of these, someone else can simply add their own.

After all, Google ordered the Nexus S with embedded secure chips, the PN65 from NXP Semiconductors, which can store applications. The NFC controllers in the phones also support applications for card emulation on SIM cards.

[From Card Emulation Expected Soon Despite Doubts from Google Engineers | NFC Times – Near Field Communication and all contactless technology.]

Indeed. So why the fuss? What does it matter whether Google want to provide card emulation APIs or not? The things is that Google’s opinions about NFC have taken on more and more significance recently as it has become clear that whatever mobile operators and banks may think about NFC, Google thinks that it is important and will drive it into the marketplace.

Google has obviously made a decision that NFC is an opening into something more interesting and lucrative than transforming a phone into a payment card– advertising and marketing opportunities at the point of sale – the physical point of sale. And, it has done a deal with VeriFone that takes the economic sting away from the merchants who need to buy into their vision to make it work – and who have by and large turned their noses up at NFC up to this point. Layer on top of that their Google Checkout asset and their newly launched One-Pass wallet application and you have the makings of an interesting new payments player.

[From Google Takes on NFC, Will They Crack the Code? at The Catalyst Code]

Karen is, as usual, spot on with this analysis. But I’m not so sure about this…

What’s amazing is that Google was the first to connect all of these dots

[From Google Takes on NFC, Will They Crack the Code? at The Catalyst Code]

This doesn’t seem amazing to me, because I’ve been involved in numerous attempts to develop mobile proximity payments for banks and operators. A month before the Google announcement, I wrote on Quora that “I’m sure [loyalty and rewards] will be Google’s strategy too. Payments are not an interesting enough application to persuade people to go out an get an NFC phone.” Years ago, I made a presentation (I think at NFC World but I can’t find it!) in which I said that no consumers will go into retail outlets and buy an NFC phone because of payments. They will buy the NFC phone so that they can read tags, swap Facebook profiles or (now, it seems) play proximity Angry Birds. But once they have that handset, then we need to make it easy and attractive for them to use it for payments.

Incidentally, Dean Bubley, who is in my opinion one of the very best analysts out there, called these non-payment applications “valueless” in a twitter exchange. He’s referring to things like “0-click” checkins and similar.

Starting tomorrow, just tap your NFC-enabled phone (most newer Android devices have it) against the poster, it’ll check you in with foursquare

[From Experimenting with NFC check-ins for Google I/O | Foursquare Blog]

I’m convinced that valueless is the wrong word. If Google (or Apple) or whoever track where you are via mobile location and then send you special offers, it’s creepy. But if you reach out tap when you enter the shop, or restaurant, or hotel, or office, that’s what advertising folk label “a call to action” that gives them permission to send you things, to steer you, to deliver added value. That’s what retailers will pay for—they’ll get the payments part for free—and that’s why the ecosystem will deliver real value..