The Weekly #2

July 27, 2021

The ‘Apple Pay is a monopoly’ soap opera continues

ZDNet reports Australian Parliamentary Joint Committee on Corporations and Financial Services hearings that are focused on, yet again, forcing Apple to ‘open up’ their NFC chip. Actually they should be talking about the secure element in Apple Silicon because that’s what Apple devices use and it’s not just about NFC anymore, it’s Ultra Wideband too.

The Apple Pay monopoly debate isn’t new and isn’t about being ‘open’, it’s about banks getting what they want from politicians. What I found interesting was the back and forth between Apple and Google regarding the hardware embedded secure element (eSE) vs. the virtual secure element in the cloud Host Card Emulation (HCE), a topic that confuses many ‘experts’.

Google is playing both ends here because they have different flavors of Google Pay for different kinds of Android devices. Google Pixel Google Pay uses eSE while everybody else use HCE Google Pay. One very important thing not mentioned in tech blog coverage is that Samsung Galaxy and the Chinese smartphones (Huawei, OPPO, Xiaomi) all use a custom eSE with their own XX-Pay. In other words, everybody on the Android side outside of low end junk is doing exactly what Apple Pay is doing.

Host Card Emulation (HCE) is a less secure implementation, which was adopted by Android … Apple did not implement HCE because doing so would lead to less security on Apple devices.

Our payments apps are immensely secure…we would refute the suggestion our HCE environment is in any way insecure … I would argue the user experience on Google Pay is equal to that of Apple Pay.

Let’s see what GlobalPlatform has to say about HCE:

HCE solutions can be a great option for issuers to get to market cost-effectively for their Android customers. However, they aren’t without their complexities. Rooted in the NFC device OS, HCE apps can be more vulnerable than the ‘Giant Pays’.

So HCE security is up to the payment app, shitty app = shitty security without Apple Pay Secure Intent. The whole HCE debate is nonsense, like FeliCa Dude says it’s eSE or nothing. If the committee thinks that HCE means open and good, they are showing their incompetence.

Apple Pay Wallet has a very simple rule: any card that loads a Java Card applet into the secure element has to reside in Wallet. Any card or developer that wants to loads applets and use the secure element has to have a PassKit Secure Element Certificate Pass. This is covered by NDA but a company called PassKit (not Apple) gives us an idea what Apple’s NFC/Secure Element Pass guidelines are:

Apple care a great deal about the user experience. Before granting NFC certificate access they will ensure that you have the necessary hardware, software and capabilities to develop or deploy an ecosystem that is going to deliver an experience consistent with their guidelines.

Yeah, the end to end user experience, the whole reason behind the success of Apple Pay. Banks don’t want to be told they need to improve their ecosystem for a better user experience, and they don’t want to pay a transaction cut to Apple that they are used to keeping for themselves. What else is new?

The whole ‘Apple Pay is a monopoly’ soap opera is overrated.

PASPY transit IC card migrating to QR

After thinking out loud recently about dumping their PASPY transit IC card in favor of a QR Code smartphone app, Hiroshima Electric Railway Co. Ltd (Hiroden) CEO Masao Mukuda announced that Hiroden would indeed junk NFC and migrate to a QR Code app over an unspecified period of time. Running their own transit IC card is too expensive, so old folks, school children and everybody else will have to use smartphone to ride Hiroden light rail trains in Hiroshima.

PASPY is just the tip of the iceberg. There are many transit IC cards out there with the same problem: fixed infrastructure costs supporting a small region transit IC card and declining ridership. Add the COVID crisis that has decimated public transit use and you have a business crisis. All the small transit cards outside of the Transit IC card standard (the pink box) are in the same boat: they can only be used in their respective regions, they don’t have e-money functions, they don’t have the resources to go mobile.

This is exactly the problem JR East is addressing with their 2 in 1 Suica MaaS soution. JR East hosts the hardware, the local operator issues a ‘localized’ Suica that offers both special local MaaS services (discounts and extras, etc.) and seamlessly plugs into the larger Suica and Transit IC map.

Suica 2 in 1 region cards are the keystone of JR East’s MaaS strategy

Unfortunately PASPY is in the JR West region which doesn’t have anything similar to the JR East MaaS program. It would be a perfect solution: customers would get a new card that works just like it does now but works everywhere with e-money and ICOCA benefits, Hiroden is freed from the costs of hosting and issuing their own card.

QR is not going to be the salvation that Hiroden hopes it will be. QR isolates Hiroden from the wider transit IC network of Mobile Suica, PASMO, ICOCA. Even if Hiroden gets rid of their card issuing business cost, they still have to host a system to run the QR Code app and manage accounts. The real rub is that instead of anybody buying an IC card out of a machine, Users will have to sign up for the app or buy a QR paper ticket. They also have to worry about where and how their account data is stored. My prediction: it’s going to be a messy money losing transition.

Heraiza down but not out

Poor little Heraiza, one of my favorite Japanese YouTubers, has been copyright claim ‘hacked’ from a fake account pretending to be Dentsu and now has 2 bogus strikes against her YouTube account. As an independent 17 year old high school student with 150,000 followers, she doesn’t have the resources of a YouTuber managment agency like UUUM, who she likes to badmouth (and I won’t put it past UUUM using fake accounts to take her out). Dentsu or whoever the real copyright holder is has confirmed to her that her content does not violate said copyrights.

Hopefully she’ll get it all worked out and unlock all her previous videos, though YouTube being YouTube, if they don’t like you they ban you…AND keep your ad revenue. In her most recent post about one of her favorite YouTubers having their account hijacked, she has her confidence back. Good thing, in these dark times we all need to laugh.

Have a good week and enjoy the Olympics.

Secure Intent and the Secure Element

Undistracted John Gruber on Secure Intent on Apple Devices. A interesting dive into spoof proof secure intent: “a physical link—from a physical button to the Secure Enclave…used to confirm user intent during Apple Pay transactions,” and how it plays out on Apple devices with Face ID and Touch ID. He makes a good case for multi-sensor biometric authentication. What interests me most however is the secure intent mention in Apple Pay component security Secure Enclave section:

On Apple Watch, the device must be unlocked, and the user must double-click the side button. The double-click is detected and passed directly to the Secure Element or Secure Enclave, where available, without going through the Application Processor.

Apple doesn’t spell it out but this is confirmation that a GlobalPlatform licensed Embedded Secure Element is simply part of every Apple Silicon package, and for all Secure Intent purposes indistinguishable from the Secure Enclave. If push comes to shove over governments trying to force Apple to ‘open up’ the NFC chip, the counter argument will be that the NFC chip is open for Core NFC purposes but the Secure Element cannot be open because it’s part of the Secure Enclave on proprietary Apple Silicon.

Given that Apple added the Secure Intent section to Apple Platform Security very recently, expect to hear more at WWDC21 in connection with secure payments and UWB.

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.