Tag: Pixel 3

Pixel 4 goes cheap instead of deep

As I tweeted earlier today, the updated Pixel Phone Help hardware pages tell the whole story: if you purchased your Pixel 4, 3a or 3 phone in Japan, a FeliCa chip is located in the same area as the NFC.

This is a little misleading because as FeliCa Dude pointed out in tweets, the Pixel 3 uses the global NFC PN81B ‘all in one chip’ from NXP. There is no separate ‘FeliCa chip’:

All the Pixel 3 devices have an eSE…A teardown of the global edition Pixel 3 XL (G013C) reveals a <NXP> PN81B.

FeliCa Dude

Pixel 4 teardowns will certainly reveal a PN81B or similar all in one NFC chip from NXP. Google could have gone global NFC with Pixel 4 and given Android users everywhere access to Google Pay Suica. Unfortunately Google went cheap instead of deep, sticking with the same Pixel 3 policy of only buying FeliCa keys for JP Pixel models.

Why is Google turning off FeliCa on Pixel models outside of Japan? I doubt it is a licensing restriction because the whole point of NXP PN81 is having all the global NFC licensing pieces, NFC A-B-F/EMV/FeliCa/MIFARE, all on one chip, all ready to go. It could have something to do with Google Pay Japan. For Apple Pay Japan, Apple licensed all the necessary technology and built it into their own Apple Pay.

Instead of that approach Google Pay Japan is a kind of candy wrapper around the existing ‘Osaifu Keitai’ software from Docomo and FeliCa Networks, and all of the existing Osaifu Keitai apps from Mobile Suica to iD to QUICPay. That’s why having a ‘Osaifu Keitai’ Android device is a requirement for using Google Pay Japan. Perhaps Google is content in candy wrapping things instead of retooling it all as basic Google Pay functionality and letting Android OEMs benefit from that.

Whatever the reason, the moral of this story is that Google Pay Suica will not be a transit option for inbound Android users during the 2020 Tokyo Olympics. Unfortunately, the Android equivalent of the global NFC iPhone has yet to appear.

UPDATE
Pixel 4/4a all have the same NFC hardware and Mobile FeliCa software, but non-JP models block Mobile FeliCa apps from running.

Pixel 3 Global NFC Evolution

Reader feedback and discussion from my earlier post analyzing the fuzzy state of iPhone 7 FeliCa and its possible support of Apple Pay Octopus, resulted in some interesting discussion about the Pixel 3 Japanese FeliCa model. From FeliCa Dude’s epic Reddit Octopus on iPhone 7 post:


<reader comment> Regarding the Pixel though, are you sure that the non-Japanese Pixel 3 models even have an eSE <embedded secure element>? I was under the impression that these were HCE <host card emulation> only.

<Felica Dude answer> All the Pixel 3 devices have an eSE, but it might not be able to be enabled by the end-user, and even if it is possible, it won’t be provisioned. A teardown of the global edition Pixel 3 XL (G013C) reveals a <NXP> PN81B.

The NXP PN81 announced in February is all-in-one off the shelf global NFC chip that includes both the frontend NFC A-B-F hardware and the necessary embedded secure element (eSE) + keys for EMV, FeliCa and MIFARE. The odd thing is that the Google Pixel 3 Japanese model apparently doesn’t use the PN81 for FeliCa, and has a separate FeliCa chip sitting in the fingerprint sensor assembly inside the back case.

Google Pixel 3 JP SKU iFixit teardowns do not exist but I did run across an interesting article from the Keitai Watch site showing a Pixel 3 JP SKU being taken apart for repair at an iCracked repair shop.

Just for kicks, I called the iCracked shop and asked about repairing a faulty FeliCa Pixel 3 device. The Pixel 3 repair technician explained that a FeliCa chip replacement was not expensive because it is not on the motherboard, “it’s attached to the fingerprint sensor assembly.” Look carefully at the picture from Keitai Watch piece and you can see the back case with fingerprint sensor assembly that the technician was referring to.

Disassembled Pixel 3 JP model from Keitai Watch

This presents a very strange situation. All Pixel 3 SKUs have the FeliCa ready PN81 chip but don’t use it, while Pixel 3 Japan SKUs might have another separate FeliCa chip attached to the back case finger sensor assemble. Google alludes to this on the Pixel 3 support page: If you purchased your Pixel 3 or Pixel 3a phone in Japan, a FeliCa chip is located in the same area as the NFC. There is also the recent batch of Pixel 3a Japan SKUs with bad FeliCa chips, but reports of bad NFC (EMV) Pixel 3a international SKUs have not surfaced; this also suggests a separate FeliCa chip. Why have two FeliCa chips in a device when one will do?

My take is different from FeliCa Dude: the Pixel 3 does not use the PN81 eSE or ‘pie in the sky’ HCE for anything. Instead, Google Pixel 3 uses the Titan M chip Secure Enclave as the virtual eSE for EMV and MIFARE, similar to what Apple does with the A/S Series Secure Enclave. Titan M FeliCa support was either not ready, or Google wanted to test the Japanese market before making a custom hardware commitment.

The point of all this is that Google has laid the foundation for a global NFC Pixel 4 made possible by a custom Google chip. The Titan M is Google’s answer to Apple’s A/S Series Secure Enclave that can host any kind of virtual embedded secure element for any kind of transaction technology, from EMV to PBOC.

I might be wrong, but even if my virtual eSE on Titan M take is incorrect, taken all together with the NXP PN81 development, I think Pixel 4 will finally be the global NFC Android device that many have hoped for.

UPDATE: extensive testing by FeliCa Dude did not support my eSE on Titan theory. The chip in question is the FPC1075 chip interface between the fingerprint sensor and the SPI bus. Pixel 4 is not global NFC, which says it all and knocks everything back to square one: there is no separate FeliCa chip, it’s a NXP PN81 chip all the way. Google hardware support page wording is very misleading, nothing more.

Apple Pay Octopus and the Pixel 4 Global NFC Question

Apple Pay Octopus on iOS 13 this fall puts Pixel 4 and Google Pay in an awkward market position. Pixel 3 is a success in the Japanese market because of the inclusion of a dedicated FeliCa chip in Japanese models. Non-JP Pixel 3 models have a global NFC ready NXP PN81 chip but FeliCa is not activated for some reason, inbound users cannot use Google Pay Suica, or anything else, in Japan.

The question for Pixel 4 is this: will Google Pay use all the features of the NXP PN81 chip, or go with a custom implementation of FeliCa on their own chip for a global NFC device along with an enhanced Google Pay that seamlessly incorporates and builds on Osaifu Keitai software (killing off JP carrier Osaifu-Keitai SIM nonsense for good) instead of simply candy wrapping it, like they do for Pixel 3 JP Google Pay.

If Google goes with the first choice, Google Pay Octopus becomes a future possibility. It would also force other Android smartphone manufacturers to follow suit.

If Google keeps that same Pixel 3 arrangement they have for Pixel 4, a separate hardware model for Japan, Google Pay Octopus becomes a murky proposition. More of the same would be a shame. I hope Google does the smart thing and the right thing: global NFC on all devices is the way to go.

10/16 UPDATE: We have an answer: Pixel 4 is not global NFC, FeliCa support is restricted to JP models, the same story as Pixel 3. Google did the cheap thing again and chose not to buy FeliCa keys for all Pixel 4 models.

HCE Secure Element in the Cloud is pie in the sky

Stefan Heaton’s blog piece “The reason Mobile myki isn’t available on iPhone… yet” is all the proof you need that Google inspired endless nonsense and confusion with Android Pay Host Card Emulation (HCE). This was shortly after the NFC “secure element” wars were over, with the mobile carrier locked SIM card secure element losing out to the embedded secure element (eSE) on smartphone NFC chip. Google’s network connection dependent HCE secure element in the cloud strategy for Android seemed like it would solve everything and free NFC from the evil clutches of mobile carrier SIM lock-in contracts and the cost of eSE hardware. Except that it didn’t. It’s eSE or nothing now.

So why is Heaton spouting HCE support nonsense for MIFARE myki on Apple Pay when Android myki doesn’t even use HCE? He incompetently confuses HCE as a hardware secure element when HCE actually means a virtual secure element hosted in the cloud or in an app. People who should know better have been sowing confusion ever since.

myki is MIFARE which has never used HCE. HCE is an EMV payment solution for credit cards on Android devices without a hardware secure element. Ditto for FeliCa, which Google Pay users outside Japan assumed would work for Suica until they found out HCE-F is fakeware that nobody uses, not even Google, and lost their minds. As FeliCa Dude pointed out, “HCE-F is not useful for card emulation…because the API has been needlessly crippled.” Good luck with that.

What nobody has said, and I think it’s worth pointing out, is that the Android Pay to Google Pay shift was also a break with HCE and Google pretending to provide a ‘free’ secure element strategy for all Android licensees (ahem, see Google’s “Android Ready SE” alliance).

Google is now focused on Pixel hardware and their own Google Pay eSE strategy, all other Android licensees and manufacturers be dammed to find their own solutions for MIFARE, FeliCa, Calypso and so on. I guarantee you that, in time, Google will be doing most, if not all, of the same security hoops that Apple does for Google Pay on the Google Pixel platform.

So yes, Apple does limit NFC Secure Element (in Apple Silicon) access with PassKit NFC certificates. But Apple Pay MIFARE is real MIFARE used around the world, and Apple Pay FeliCa is real FeliCa. Public Transport Victoria (PTV) can apply for a myki card PassKit NFC certificate just like any developer. And for goodness sake Stefan, stop writing sentences that confuse Express Mode payment cards (EMV credit/debit cards) with regular Express Mode transit cards (FeliCa, MIFARE, PBOC). Suica is not a credit card and emulating EMV at a transit gate doesn’t automatically make a credit card into an Apple Pay Suica transit card, not by a long shot. If your aim is promoting open loop over closed loop, that’s one thing. Either way, your LinkedIn blog post is not doing your LinkedIn resume any favor.

Related: How much does Smart Navigo HCE suck?

More Apple Pay Octopus

UPDATE: Apple Pay Octopus is coming with iOS 13

Note: For simplicity and convenience I have migrated and merged older Octopus related posts here. All new Octopus related developments will be posted separately.

I assumed the Octopus Coming to Apple Pay post would be ignored in the end of year rush period. However the timing perfectly coincided with an Octopus Cards Limited press conference where the CEO demurred any Octopus tie-up with Apple and the post got much more attention than I ever anticipated. Obviously there are lots of iPhone users in Hong Kong who want Apple Pay Octopus. A few readers were confused by the situation and asked for some clarification.

First of all the source who correctly predicted last years Smart Octopus on Samsung Pay launch tipped me about the Apple Pay launch. That in itself was enough for me but here’s the thing: if Octopus Cards Limited (OCL) is really serious about expanding Octopus use on mobile platforms, taking the next step of getting Octopus on Apple Pay is the only way to achieve that.

Digital Wallets like Apple Pay and Samsung Pay are the most tightly integrated NFC software and hardware digital wallet platforms out there with integrated FeliCa, but Apple is the only one to implement the necessary Secure Element on their own A Series/S Series hardware with FeliCa Networks keys, and sell the package globally. All the major NFC technologies are standard on Apple Pay: NFC A-B-F, EMV, FeliCa, MIFARE, VAS.

Octopus on Google Pay might look nice on paper but it can’t achieve anything of scale yet because of the highly fragmented nature of Android: to date hardware manufacturers have yet to produce an answer to Apple’s global FeliCa iPhone and Apple Watch, even though everybody’s smartphone has a NFC A-B-F chip. Not even Google has pulled it off. Huawei says they are planning to add global Felica but it will take time.

OCL is playing coy because majority shareholder Hong Kong MTR has added QR Codes and EMV contactless to the transit gate mix removing the exclusive Octopus Card franchise, but the technology and market politics don’t mesh. On one hand you have a fast, established and ‘open’ in-house contactless payment system (as in anybody can buy a plastic Octopus card and ride) basically run by public transit companies. On the other hand you have slow and ‘closed’ contactless payment systems (as in only people with certified credit cards and bank accounts can ride) run by major outside credit/debit network companies chipping off money from both customers and transit companies.

In this context putting Octopus on Apple Pay isn’t just adding a card to a digital wallet platform, it is also a statement of who ultimately controls, operates and benefits from the public transit gates. It’s more about market politics than technology, in other words another battle in the contactless payment turf wars. The outcome will be fascinating to watch but determines whether Octopus will remain a great transit payment platform for Hong Kong with a future, or not.

Update
It looks like we’ll have to wait a while longer for Octopus on Apple Pay.