Is Google prohibiting SIM based NFC? How does Android M impact the SIM Model? I’m tired of answering this question so here is the answer to this multifaceted question.
1) Android M
2) MNO Agreements, Google Mandatory Services
3) HCE
Take a look at https://developer.android.com/guide/topics/connectivity/nfc/hce.html. Android technically supports ISO 14443… so technically any OEM or MNO can build a handset with a GSMA SIM based wallet in Android. There is not a technical limitation in Android that would prohibit GSMA SIM Based Wallets. But why would you want to build one?
Google has created a new Google Mandatory Services (GMS) agreement with Android Pay as part of it. Do carriers have to agree? of course not.. but it is a double edge sword, not agreeing to Android M + the new GMS agreement means MNOs/OEMs will not recieve the latest Android updates/capabilities (in app payment, biometrics, …). It is a great big support headache for OEMs and MNOs.. they are left holding the bag on Android support. Some can do it …. Android started out as a free open source software.. and it still is.. but Google’s core services have become much more secure running in SE Linux. Anyone can still use the free open source Android.. but if you want to use Google’s versions there are strings attached. Those services come in the form of OEM and Carrier agreements.
HCE + Tokens is a new construct supported by the card networks. I have many blogs on the topic. Google provides OEM, Banks, MNOs the API to build payment capabilities into the phone for free. A further BIG advantage is that Visa and Mastercard have set up fast “on ramp” services that drastically simplify card provisioning (all at zero cost to everyone). In essence.. this new approach has greatly reduced the complexity of the entire contactless payments process. My GSMA friends HOWL at how unsecure HCE is (compared to hardware/SIM based payments) but this misses the point. HCE + Tokens + Mobile Auth is far more secure then any piece of plastic out there today. See http://blog.starpointllp.com/?p=3638.
See my blog What part of NFC is Dead (The GSMA Part)
On a related note, I just responded to an email on why Samsung Pay is dead
1) Agree that Samsung has new TZ architecture w/ SW SE
2) Agree that Samsung has not sold MNOs
What Samsung still does not get is that their new SW SE will NOT WORK in Android M. Google has also built a SW SE.. that COMPETES with Samsung’s … no one is writting about this. This is the issue beyond the US. Samsung spent quite a bit of effort making this work.. but now Google has defined the SW SE.
Net is that Samsung pay has problems for 3 reasons
1) no MNO support
2) No SW SE in US (OEM Config)
3) no load of their wallet on phone
” ———–Update 8pm From anonymous source
It seems that in the US, Samsung plans to create and certify a new software secure element within the ARM Trustzone architecture that precludes the need for SE Keys, avoids US MNO SE Key Ownership issues (that can’t make MNOs happy) …
This is a great technical approach, but is doesn’t appear that Samsung has bothered to sell US MNOs on the concept (of going around them). Anything US MNOs subsidize they must approve.. Which means no pre-installation, particularly given the new Google relationship outlined below.
—————-”
How annoying is it that Google chose an acronym that already has an established meaning in the mobile world like GSM? Acronyms are a pet peeve of mine, as they generally lead to more confusion and exclusion than is necessary.
May be an internal term only.. I can’t find anything on it in Google..
I think it’s Google Mobile Services, not Google Mandatory Services, though they do seem mandatory… here are some references:
https://developer.motorolasolutions.com/servlet/JiveServlet/previewBody/2210-102-2-2535/Google%20Mobile%20Services%20vs%20AOSP.pdf
http://www.zdnet.com/article/debunking-four-myths-about-android-google-and-open-source/
MNOs could quite easily start issuing SIM cards already enabled for NFC payments using ProxyEMVPay approach, as I have described in one of my earlier blogs
http://letstalkpayments.com/can-mobile-network-operators-regain-relevance-in-the-mobile-payments-space/
No need for TSM role anymore and with very similar ecosystem as Apple Pay. HCE is usable but ProxyEMVPay SIM cards are real Secure Element based solution, not requiring available online / data connection as HCE requires.
Visa and Mastercard have set up fast “on ramp” services that drastically simplify card provisioning (all at zero cost to everyone)
Visa and MasterCard have fees for their tokenisation services, why do you think it is zero cost?
Except the part when you say visa and MasterCard services are “all at zero cost to everyone”… Banks pays. Per each issued token. So it’s not really for free (well certainly not for the banks).
You are correct for Mastercard… my miss. The visa token service is free this year (this year)
” … It seems that in the US, Samsung plans to create and certify a new software secure element within the ARM Trustzone architecture that precludes the need for SE Keys, avoids US MNO SE Key Ownership issues (that can’t make MNOs happy) …”
The ARM Trust Zone might become soon a EAL2+ TEE (Trusted Execution Environment) zone. See https://www.globalplatform.org/mediapressview.asp?id=1123 to know more about it.
ARM is member of GlobalPlatform consortium and it looks like they are pushing into this way. SE is still THE tamper-resistant unique solution but soon it might not be anymore the case.
As I state here (http://intellinium.io/etsi-security-week-june-2226/) after several talks with experts during the ETSI Security Week (http://www.etsi.org/news-events/events/870-security-week), dedicated Secure Element costs probably too much today ((money, performance, power consumption, dev overhead, …) related to what the market can accept for massive rollout of payment, iot or smart city solutions.
Mathieu DESTRIAN
CEO of INTELLINIUM