The Weekly #4

August 8, 2021

Pixel 6 Tensor and the secure element

After many years of rumors Google finally unveiled their custom silicon, though details won’t be known until Pixel 6 devices go on sale. Dieter Bohn wrote:

Tensor is an SoC, not a single processor. And so while it’s fair to call it Google-designed, it’s also still unclear which components are Google-made and which are licensed from others. Two things are definitely coming from Google: a mobile TPU for AI operations and a new Titan M2 chip for security. The rest, including the CPU, GPU, and 5G modem, are all still a mystery.

Ever since Pixel 3 models went on sale in Japan with Mobile FeliCa support, inbound Pixel users have been pining for the same global NFC feature that iPhone and Apple Watch have, but it hasn’t happened. Here’s why.

On the NFC hardware side everything has been ready to go on all smartphone hardware for years because NFC A-B-F support is a requirement for NFC certification. The problem has been on the SE side, the black box where all the transaction magic happens. From GlobalPlatform the SE certification organization:

A SE is a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (for example cryptographic keys) in accordance with the rules and security requirements set by well-identified trusted authorities.

There are different form factors of SE: embedded and integrated SEs, SIM/UICC, smart microSD as well as smart cards. SEs exist in different form factors to address the requirements of different business implementations and market needs.

GlobalPlatform Introduction to Secure Elements

SE Wars
In the pre-Apple Pay mobile carrier hardware era, carriers used SE SIM or a embedded Secure Element (eSE) + carrier SIM combo that chained customers to service contracts for the privilege of using mobile payments. This is the classic Osaifu Keitai model pioneered by NTT DOCOMO: an overpriced carrier SIM contract to use mobile payments only with select carrier handsets.

This carrier lock in model is one reason why Mobile FeliCa ended up being ridiculed as ‘galapagos technology’ even though everybody else copied it. This carrier SE SIM hostage situation, i.e. the Mobile Wallet SE Wars, led Apple and Google to follow different strategies to address the problem.

The Apple Pay Way
Apple’s answer of course was Apple Pay. A unique in-house strategy of putting a GlobalPlatform certified Secure Element in Apple Silicon. Most eSE go on the NFC controller, but doing it the Apple in-house way has advantages over a NFC chip vendor bundle: control of the eSE applets and ability to update them and the Apple eSE for new protocols in iOS updates. We saw this in action with the addition of FeliCa in 2016, PBOC in 2017 and MIFARE in 2018. We are seeing it again with the addition of Ultra Wideband (UWB) Touchless in iOS 15.

The Google Pay Way
Google’s answer to the carrier owned SE problem was a convoluted evolution from Google Wallet (2011) to Android Pay (2015) and finally Google Pay (2018). Google’s first salvo was Host Card Emulation (HCE): “NFC card emulation without a hardware secure element” a virtual secure element hosted on Google’s cloud or in an app. Later on Google attempted to do the same for FeliCa with HCE-F.

The HCE strategy was quietly abandoned when Google decided to get into the hardware business and Android Pay turned into Google Pay. Now we have Google Pay running on Google Pixel with its own embedded Secure Element (eSE). With Pixel and Google Pay, Google decided they didn’t want to be the Secure Element provider for every Android OEM out there especially when the Chinese OEMS are all rolling their own eSE based digital wallet services anyway, completely ignoring HCE. Sure, HCE/HCE-F is still there in Android developer documentation but it’s a vestigial relic of the SE wars. From an industry standpoint it’s eSE or nothing now.

Google Pixel models up to now have used vendor bundled eSE + NFC controllers with the Pixel JP models using the Osaifu Keitai software stack. This makes global NFC support more complicated because Google doesn’t ‘own’ the eSE and the software stack, at least not in the Apple sense of making their own all in one solution. As we have seen, Mobile FeliCa is installed on all Pixel 5 models but the Osaifu Keitai stack only loads on JP models.

Will a Tensor SoC that contains a Titan M2 and a custom eSE solve this? It all depends on whether Google goes deep instead of cheap by stripping Google Pay of its dependency on the Osaifu Keitai stack and create their own region free support stack. If so, inbound Pixel 6 users will have the ability to add Suica and other FeliCa cards out of the box.


The PASPY organ transplant

As pointed out previously, the PASPY transit card transition from NFC to QR is not going to be easy. Not only does HIroden have to swap out the basic technology infrastructure, they also have to swap out their IT system integrator partners. The PASPY system was built and is currently managed by NEC with the last server upgrade completed in 2014. A quick look at the system map illustrates the pain points that including swapping out the NFC reader infrastructure in trolleys and buses and replacing it with QR readers with mobile connectivity, a requirement because of central processing. There will also be a lot of pain for wide area commuters because going QR means cutting the cross compatibility cord with ICOCA, Suica, etc.

The mobile connection means a mobile operator has to be involved to make it work. The likely IT system candidate here is the same one behind all the QR transit systems in Japan so far: SoftBank backed QUADRAC. The PASPY QR replacement is expected to be closed loop, similar to the QR + smartphone app closed loop system being tested by Nankai. Too bad JR West can’t come to the rescue with a localized version of the Suica 2 in 1 Region Affiliate Transit Card, but that’s another story for another time.


To eSIM or not to eSIM

eSIMs are great in theory, unfortunately the current reality for Japanese customers is less than ideal even thought the Japanese Ministry of Internal Affairs and Communications (MIC) is promoting them over traditional physical carrier SIMS and issued eSIM guidance. In addition to this carrier SIM locked devices will not be allowed from October. Of the big three carrier budget brands: NTT DOCOMO (ahamo), au KDDI (povo), SoftBank (LINEMO), only LINEMO and povo offer eSIM options. DOCOMO says they are thinking about it but for now ahamo is a physical SIM service because DOCOMO says eSIMS are not as secure as physical SIMS.

A recent article by Masao Sano outlined the eSIM situation in Japan and current obstacles for customers. The online signup process and device setup isn’t always smooth going and first time customers sometimes have to deal with unlocking their carrier device, APN settings, network authentication codes, profile installations and so-on. The eSIM process needs to be easier and user friendly. The good news is that unlocked carrier phones will be standard soon along with better eSIM option plans and migration setup. Once ahamo adds an eSIM option the next step will be taking it mainstream for major brand carrier contracts.


Apple Music finally sorts Japanese artist names correctly

Congratulations Naoko! You and all your fellow Japanese artists on Apple Music were finally liberated from the # sorting section and now live in 五十音 (Gojūon) splendor in iOS Music App. A very long wait though wasn’t it? Six years!

Seriously though I wonder what took Apple so long to fix most, but not all, of their Japanese music metadata mess. Not a moment too soon as the old reliable iTunes Match service seems to be on its last legs and the macOS Music app replacement for the old reliable iTunes app is completely useless for organizing a digital music collection: Apple Music and iCloud Music library have a mind of their own.

Truth be told, I had more fun collecting and listening to music on iTunes + iPod than discovering music on Apple Music + iPhone. For some strange reason, less is sometimes more.


The Weekly will be taking a summer break the weeks of August 9 and 16 and resume the week of September 1. Take care and enjoy the rest of the summer.

Fun with Android NFC settings…not

XIANYOU’s blog post outlining adventures getting Xiaomi Redmi Note 8 NFC to work correctly, is an excellent reminder that Apple Pay does a great service by hiding NFC setting nonsense from iPhone customers. I mean really, is it the user’s job to figure out the ‘secure element position’? Bottoms up. The essential thing is that Google Pay doesn’t play out of the box:

As it turns out, this was because the default NFC processing behavior configuration on the phone was not one that Google Pay supported on my Redmi Note 8 Pro (or at this moment, possibly any non-Pixel 3+ phones).

This is exactly the situation I predicted back when Android Pay became Google Pay. Google doesn’t want to support non-Pixel embedded secure element devices: eSE for Google, HCE for everybody else. It’s going to get real interesting when Google starts shipping Pixel with custom Google silicon, rumored for Pixel 6, along with those Mobile FeliCa multiple secure element domain functions.

Are Google Pixel 5 and Fitbit up to the Global NFC Challenge? (Update: Pixel 5 not)

It’s that time of year again to think about FeliCa support on the Google Pixel platform as Pixel 5 approaches. Ever since Pixel 3 things have been the stuck in a rut: the same global NFC (A-B-F) chip and Mobile FeliCa is in all Pixel models, but only Osaifu Keitai apps launch and run on Japanese SKUs. No Suica for you if you don’t have one of those.

I used to think that Google was going cheap instead of deep. Google is cheap here actually, and lazy, but there are some other reasons. It goes back to the problem many people had with Google Pay Japan FeliCa support to begin with: it’s only a UI candy coating on top of the aging Osaifu Keitai stack and apps. Instead of doing a true top to bottom Google Pay global NFC solution like Apple did, Google Pay Japan FeliCa support is just surfing on the Osaifu Keitai board. And of course the Android Pay HCE-F thing is long since dead, it’s eSE or nothing now.

One problem is this: Osaifu Keitai is a domestic platform, Osaifu Keitai apps (Suica, etc.) are domestic apps. The various Osaifu Keitai partners and developers don’t want to deal with the extra expense of multi-lingual localization and support. Neither does Google, hence the logjam.

Google’s recent purchase of Fitbit might be the agent of change that finally changes the situation. The Osaifu Keitai model doesn’t extend to wearables. Google Pay has to come up with something new to replace Fitbit Pay, something that works across paired devices seamlessly if Google Pay Suica is to exist on a Fitbit smartwatch paired with Pixel.

There is something new this time around that didn’t exist, or at least didn’t exist as a marketed developer product back in 2018: Mobile FeliCa Platform and Mobile FeliCa Cloud for supporting all kinds of Mobile FeliCa services worldwide. This arrangement got us Suica on Garmin Pay.

Taken together I think there is a better chance Google will go deep instead of cheap, hopefully sooner than later. Google Pay Suica and Google Pay PASMO on Pixel and Fitbit devices from anywhere would be a very welcome development.

Update: Not labeled on diagram

Pixel 5 was announced and FeliCa support is still limited to JP models, more cheap instead of deep. Pixel support pages (screenshots) list FeliCa support in the ‘Not labeled on diagram’ section with Osaifu Keitai links and this new bit: “To use FeliCa on Pixel 4 and later Pixel phones you’ll need 4 apps that should automatically open during setup.” This is the enablement step that Google blocks on non-JP Pixel models. The strange thing is that Mobile FeliCa is hiding in plain sight on all Pixel models, if Google wanted to they could allow enablement remotely.

This confirms the FeliCa situation won’t change for Pixel until Google builds their own Google Pay replacement for Osaifu Keitai software instead of candy wrapping it. It all comes down to what Google wants to do regarding Suica support on Fitbit. Something will have to change in Google Pay if they want to do that.

Special warning to Hong Kong Octopus users: don’t buy a Pixel device for using the Octopus Mobile SIM. FeliCa Dude reported that Google purposely crippled Pixel 4 SWP support for products like Octopus Mobile SIM and this is the case for Pixel 5 as well. Only use officially supported devices for Octopus Mobile SIM.

Next Up for Octopus: Google Pay or something else?

Apple Pay Octopus launch day was a big success, so successful that Octopus apologized for their servers buckling under the demand. What’s next for Octopus, Google Pay? There are some possibilities but when it comes to Android there is the matter of the Secure Element (SE), where it resides and what transaction protocols are supported.

From the NFC hardware angle everything has been ready to go on all smartphone hardware for years, NFC A-B-F is required for NFC certification. The problem has been on the SE side, the black box where all the transaction magic happens. From GlobalPlatform the SE certification organization:

A SE is a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (for example cryptographic keys) in accordance with the rules and security requirements set by well-identified trusted authorities.

There are different form factors of SE: embedded and integrated SEs, SIM/UICC, smart microSD as well as smart cards. SEs exist in different form factors to address the requirements of different business implementations and market needs.

GlobalPlatform Introduction to Secure Elements

SE Wars and Google HCE ‘SE Pie in the Sky’
In the pre-Apple Pay mobile carrier hardware era, carriers used SE SIM or embedded Secure Elements (eSE) + SIM combos that chained customers to service contracts for the privilege of using mobile payments. This is the classic Osaifu Keitai textbook maneuver pioneered by NTT Docomo: leave those pesky SIM Free whiners in the cold world of plastic cards and hard cash, or crippled digital wallets until they give up and buy an overpriced carrier SIM.

This brain dead approach is one reason why Mobile FeliCa ended up being ridiculed as ‘galapagos technology’ even though everybody copied it with inferior crappy me-too products. This carrier SE hostage situation, i.e. the Mobile Wallet SE Wars, led Apple and Google to follow different strategies to address the problem.

The Apple Pay Way
Apple’s answer of course was Apple Pay. A unique in house strategy of putting a GlobalPlatform certified Secure Element in their A Series/S Series chips then building it out from there. Most eSE go on the NFC controller, but doing it the Apple in-house way has advantages over a NFC chip vendor bundle: control of the eSE applets and ability to update them and the Apple eSE for new protocols in iOS updates. We saw this in action with the addition of FeliCa in 2016, PBOC in 2017 and MIFARE in 2018. We may even see the addition of Ultra Wideband (UWB) Touchless in iOS 14.

What iOS 14 could look like with QR and UWB support

The Google Pay Way
Google’s answer to the carrier owned SE problem was the more convoluted evolution from Google Wallet (2011) to Android Pay (2015) and finally Google Pay (2018). Google first salvo was Host Card Emulation (HCE): “NFC card emulation without a secure element” hosted on Google’s cloud. Later on Google attempted to do the same for FeliCa with HCE-F.

But then something happened that put an end to all this: Google decided to get into the hardware business. And now we have Google Pay and Google Pixel with it’s own embedded Secure Element (eSE). With Pixel, Google decided they didn’t want to be the Secure Element cloud provider for every Android OEM out there especially when the Chinese OEMS are all rolling their own eSE based digital wallet services anyway, completely ignoring HCE. Sure, HCE/HCE-F is still there in the Android developer documentation but it’s a dying vestigial relic of the SE wars.

But Google Pixel depends on vendor bundled eSE + NFC controllers and the Osaifu Keitai software stack. This makes global NFC support more complicated because Google doesn’t ‘own’ the eSE and the software stack, at least not in the Apple sense of making their own all in one design. This is one reason why Pixel 3/4 only support FeliCa in Japanese models even though all worldwide models have the same NFC A-B-F hardware.

The end result of all this is the Android market is a very fragmented landscape, there are no global NFC Android smartphones: a device that supports EMV, FeliCa, MIFARE, PBOC out of the box in one globally available package.

Google Pay Octopus and the Android Global NFC Installed Base
Back to our original question, can Google Pay Octopus happen? We already have Google Pay Suica right? Let’s assume that Octopus Cards Limited (OCL) has everything in place for it to happen. Here we run into the problem just described: there are’t any global NFC Android smartphones available globally. Samsung sells them in Japan and Hong Kong, Google only sells them in Japan along with Huawei, Oppo, Sharp, etc.

For OCL this means the potential Google Pay installed base that can support Hong Kong Octopus consists of Samsung Galaxy smartphones that are already using Smart Octopus in Samsung Pay; not exactly a business opportunity worth the support expense. Even if Google Pixel 5 goes deep instead of cheap, Hong Kong would have a potential Octopus non-Samsung Android device, but that’s only one new device not an installed base. I only see Google Pay Octopus happening if Google localizes all the necessary Osaifu Keitai software and foots the entire support expense.

There is a way forward however for OCL: Garmin Pay Suica. The same Garmin APAC models that support Suica can also support Octopus, the recharge backend is entirely Google Pay. Garmin smartwatches work with any Android 5 and higher smartphone, a much larger installed base that bypasses the fragmented Android problem. Garmin Pay Octopus would offer Android users a way in, who want to use Octopus on a mobile device but who don’t want to use Samsung or Apple devices.

The conclusion: forget Google Pay Octopus for the time being. Hong Kong is a golden opportunity for Gamin Pay Octopus….if Garmin can get Garmin Pay clearance from Hong Kong authorities and banks, and cut a deal with OCL. It’s certainly in Octopus’ best interest for OCL to help turn the negotiation wheels. It’s also in Google’s interest as Google Pay would supply the recharge backend as it does for Garmin Suica. Big hurdles all, but I hope it happens.


Update

There’s another possibility besides Garmin Pay or Google Pay: Huawei Pay Octopus is said to be launching before the end of 2020. Huawei has shipped FeliCa capable smartphones for the Japan market since June 2018. From a hardware perspective Huawei Pay Octopus support is ready to roll and Huawei has the deep pocket resources to build their own support stack without using Osaifu Keitai apps, just like Apple and Samsung have done. It makes sense in light of Google Pixel refusing to support global NFC, and gives Octopus Cards Limited a second digital wallet platform in the all-over-the-place global NFC support reality of the Android world.

The Self Checkout Barcode Reader Dilemma

Reach out and touch is not something we want to be doing right now. Along with wrangling face masks and Face ID iPhone Apple Pay in the Covid-19 era, we also face another hurdle: self checkout barcode readers. Any volunteers out there who like fondling public plastic? I didn’t think so.

Convenience store self checkout all have the same deal: scan with barcode reader, tap some choices on the checkout touchscreen, scan a rewards card and pay with Apple Pay Suica, etc. The stationary barcode readers at JR East station NewDays are slightly better but you still have the touchscreen to deal with.

Barcode app and plastic variety reward cards were already a pain in the ass before all the fun started and are worse now. Apple VAS and Google Pay Smart Tap for NFC contactless reward cards has been in place for some time but uptake in Japan has been slow and small. So far only 3 contactless NFC point cards exist: Docomo dPOINT, T-Point and PONTA, and only 2 places use them: LAWSON (dPOINT and PONTA) and Tsutaya (T-Point). Part of the problem is that VAS/Smart Tap support depends on 2 factors: the reader and the POS system.

Most modern NFC readers support Apple and Google protocols but POS system support is another matter. Pre-packaged POS system providers like AirPay and J-Mups that are popular with smaller merchants don’t support them yet. This means that only big retailers with deep POS development resources like LAWSON (Mitsubishi Corp group) have added NFC contactless reward card support so far.

Apple Pay Japan supports dPOINT and PONTA cards but there are subtle differences: PONTA card requires Face/Touch ID authentication, dPOINT does not. I have not fully tested dPOINT for point payment but suspect authentication is not required for getting points but required for paying with points. One hopes that with the Covid-19 crisis in full swing, retailers and card empires (JRE Card, etc.) have the incentive to provide customers with the safest contactless experience for both payments and reward cards.

dPoint card can be accessed without Face/Touch ID, PONTA requires authentication