Hidden Assumptions

Jonathan Seybold said it best in his Computer History Museum interview video, many arguments can be easily demolished by pulling out the hidden assumptions. In our attention span challenged social media era it’s all too easy to believe things at face value. Few people invest time and brain energy to analyze and question arguments to find and examine hidden assumptions.

A reader of this blog might come away thinking I am not a fan of open loop transit fare payments and despise EMV contactless and QR Code payment technology. That would be a mistake. I don’t hate them, everything has its place. I simply don’t agree with ubiquitous assumptions that EMV or QR or open loop are cure alls for every transit fare payment situation that they are praised to be…usually because ‘everybody uses’ bank issued contactless payment cards or smartphone payment QR apps. It’s a one size fits all mentality that blinds people from seeing hidden assumptions. It’s very important to see how all the pieces, seen and unseen, fit together. After all, transit companies and their users have to live with transit infrastructure choices for decades.

In a recent twitter thread Reece Martin thought it would be nice if Canada had a nationwide transit card. This is something Japan has had since 2013 when the Transit IC interoperability scheme was put in place that made the major transit IC cards compatible with each other, but they did this without changing the hardware. The various card architectures were left untouched and linked with system updates, a use-the-same-card backend solution. China on the other hand created a national transit card with the China T-Union • PBOC 2.0 standard that replaced all older transit cards with locally branded T-Union cards, a get-a-new-card hardware solution.

A nationwide Canadian transit card is a great idea but as Samual Muransky answered in the same thread, why bother with ‘obsolete’ dedicated transit cards when everybody uses EMV contactless bank cards and EMV is the new standard. Let’s examine some hidden assumptions at play here.

Assumption #1: Everybody has contactless credit/debit cards
The open assumption here that everybody has bank issued credit or debit payment cards is not the case and varies by country, demographics, age, etc. Most people in some countries do, but even so there will always be people who don’t. Transit cards always have the advantage of being available at station kiosks to anyone with cash.

Assumption #2: because of assumption #1 open loop (credit/debit cards) is better than closed loop (dedicated ticketing) for paying transit fare
The hidden assumption is that open loop covers everything but it does not. Specific transit services such as individual commuter passes, discounted fares for disabled/elderly/children are practically impossible to attach and use with bank payment cards. The best that transit systems and payment networks can do with open loop is fare capping or special discounts when applied universally. The age-old pay ‘x’ times and get one free concept. Open loop works best for occasional transit users.

The limitations of open loop on large complex transit systems like Transport for London is easy to see. Despite a long campaign to eliminate the venerable Oyster transit card and migrate users to EMV open loop, TfL threw in the towel and upgraded the Oyster system recently. To date TfL has not offered a digital version of the closed loop Oyster card. In short, dedicated transit cards will always be with us.

Assumption #3: EMV contactless is the NFC standard
The NFC Forum recognized long ago that credit card companies and transit companies have different needs and objectives. To that end the NCF Forum has 2 basic NFC standards, one for contactless payments (NFC A/B but only A is really used) and one for transit (NFC A-B-F). All NFC devices must support NFC A-B-F for NFC Forum certification.

Assumption #4: EMV contactless for transit is safe and secure
There are many hidden assumptions packed into the words ‘safe and secure’: not everybody agrees on what safe is and what level of security is secure. Things also change depending on the situation and the design. I have covered transit gate reader design in many other posts but recap some basics here.

Steve Jobs famously said that designing a product is a package of choices. I have often said that EMV contactless is supermarket checkout payment technology but that’s not a put down, it’s the truth of what EMVCo were aiming for when they grafted NFC-A to their EMV chip for contactless cards.

Because of wide deployment with no direct control, the original EMV contactless spec had a latency window to work reliably even with crappy network installations, and the slow speed has sometimes been cited as a security risk. NFC-A (MIFARE and EMV) transaction speeds are rated for a theoretical 250ms but are usually 500ms on open loop transit gates. Suica is always 200ms, often faster. The speed gap is due to gate reader design, the network lag of centralized processing vs local stored value processing, and the different RF communication distances for NFC-A and NFC-F. JR East presentation slides explain the transaction speed differences.

  • Japanese station gates are designed to be capable of 60 passengers per minute. To do this the conditions are:
    • Processing time of fare transaction has to be within 200ms
    • RF communication distance is 85mm for physical cards and smartphones
  • European station gates are designed to be capable of 30 passengers per minute:
    • The processing time takes 500ms
    • RF communication distance is 20mm for physical cards, 40mm for smartphones
016l
Presentation slide from the NFC Forum Japan meeting, July 2016
018l
Presentation slide from the NFC Forum Japan meeting, July 2016

The Suica transaction starts from the 85mm mark while MIFARE and EMV contactless cards start at the 20mm mark. Because of the greater RF communication distance Suica transactions start much earlier as the card travels toward the reader tap area. It you look closely at the 2nd slide you can see that smartphones have a slightly earlier EMV/MIFARE RF transaction starting at the 40mm mark (the 1.1A/m boundary) due to the larger smartphone antenna, physical EMV cards with smaller antennas are limited to 20mm. This is why smartphones seem faster than physical cards on NFC-A gates. Suica physical cards have a larger antenna and the same RF transaction distance as smartphones.

NFC-A transaction speed is slower because it has to be on top of the reader before it can start. This is also the limitation with optical based QR and bar codes, the transaction only starts when the smartphone screen is close enough to the reader for an error free scan. Transit gates using these technologies are not designed for smooth walk through flow.

The speed difference is clearly seen on the Nankai VISA Touch open loop gates: the transaction starts when the card is physically on top of the reader:

Here is Suica style transit gate for comparison:

One of the smart things Nankai is doing in the test phase (limited to a few key stations) is keeping EMV/QR gates separate from standard FeliCa gates. This is practical. Regular users go through the faster regular gates, the occasional open loop or QR users go through slower EMV/QR gates. Keeping different readers separate and clearly marked helps keep walk flow smooth and crowding down at busier stations. The Nankai program has been put on pause for another year due to the collapse of inbound travelers in the COVID pandemic. It’s a trial run as Osaka area transit gear up for an anticipated inbound travel boom in connection with Expo 2025, that may, or may not pan out.

The Nankai VISA Touch gates are designed for physical cards, Apple Pay works but without Express Transit. That’s a plus as Apple Pay EMV Express Transit on TfL and other open loop systems (OMNY) has come under scrutiny for a potential security risk with VISA cards that allows ‘scammers’ (in lab settings) to make non-transit charges to Apple Pay VISA cards via Express Mode, something that is not supposed to be possible.

Timur Yunusov, a senior security expert at Positive Technologies…said a lack of offline data authentication allows this exploit, even though there are EMVCo specifications covering these transactions.

“The only problem is that now big companies like MasterCard, Visa and AMEX don’t need to follow these standards when we talk about NFC payments – these companies diverged in the early 2010s, and everyone is now doing what they want here,” he said.

Security researcher: Flaw in Apple Pay, Samsung Pay and Google Pay makes fraud easy for thieves, Techepublic

In other words, Apple removing Apple Pay bio-authentication to promote EMV Express Mode for open loop transit puts Apple Pay at the mercy of lax card network payment operation practices who don’t follow their own rules. Not that it’s a real problem in the field but accidents do happen, such as this incident on Vancouver BC TransLink that a reader forwarded:

Just a moment ago, I nearly got dinged on my CC while sitting on a high seat near a door which is where one of the validators are located. The validator picked it up from the backside rather than the front side where the tap area is located. Also, somehow, my iPhone authorized the transaction when I only want to return to the home screen instead.

If the open-loop was implemented in a way where the card must be pre authorized before the card can be tapped at a validator, it wouldn’t get me in a situation where I need to deal with customer service to dispute some charges. Good thing this time, transaction was declined so nothing related to this charge showed up in my account.

Smartphone users be careful around the backside of Vancouver BC TransLink pole readers

And then there is data privacy, a far larger and long term problem is how open loop transit user data is stored and used. Apple always says they don’t know what Apple Pay users are doing as the data stays private. Fair enough, but the same doesn’t apply to the bank card companies. Open loop payment platforms in Japan, like stera transit, love to promote the customer data reporting services they provide to transit companies.

Plastic transit IC cards are basically private, they have a card number but nothing else. Credit/debit cards have your entire profile coming along with your open loop use and stera report a subset of this in their reports. And where is this data stored? In Japan, in Korea, somewhere else, wherever stera has a data sub-contractor? Payment transaction companies have been burned, repeatedly, when caught storing Japanese card transaction data outside of Japan…but they keep doing it again when everybody’s back is turned. This problem isn’t going away because of flimsy laws, lax industry practices and last but not least: personal data is a valuable commodity.

There is also the aspect of the price of cost effectiveness. When data processing stays in the country of origin, that means local employment and tax revenue feeds the national economy. When data processing goes outside the country, those are lost. This kind of discussion never takes place when it comes to transaction data processing, which it should, especially when publicly funded transit operators are involved.

Open loop is only part of a larger picture
Canadian transit would certainly benefit from a Japanese transit IC system approach with compatibility on the backend, or even the China T-Union approach of a national card spec that is locally branded but works everywhere.

To come back to the beginning, my point isn’t about slamming EMV or QR open loop transit, just the assumptions that they solve everything. They have their place in intelligently designed fare systems but only constitute part of the larger transit fare system picture. And as I have pointed out many times, card companies have little interest in improving the EMV standard for transit needs. They want to capture transit fare business without investing. The focus will always be the supermarket checkout lane that EMV was designed for.

There will always be a risk involved when ignoring the hidden assumptions of EMV open loop as a one size fits all solution. Dedicated transit cards will always be necessary. Every transit system is unique and deserves the best solution for the transit company and the riders they serve.


Related post: USA Transit Fare System Evolution

Mobile FeliCa evolution: FeliCa without the FeliCa chip

Mobile FeliCa is a Java Card applet on a secure element (SE). If the right applet is present with the right keys, and the CLF (contactless front-end) is configured to route Type F frames to the SE, you can enable Mobile FeliCa on any SE.

FeliCa Dude

FeliCa Dude did his annual public service of posting Mobile FeliCa details for the latest Pixel 6 devices. There wasn’t any change from Pixel 5, so no global NFC Pixel for inbound visitors. Nevertheless it’s a good opportunity to review some important recent developments that have taken place behind the scenes on the Android Mobile FeliCa side and examine some possible future scenarios. Android users don’t see any difference, but things have changed a lot under the hood.

All smartphones are required to have NFC A-B-F support for NFC certification. All smartphones can read and write all types of NFC, however the software that supports Secure Element transactions is another story. Android vendors usually only preinstall EMV and MIFARE, not Mobile FeliCa, except for Google Pixel. The chart outlines Mobile FeliCa on Google Pixel developments based on information from FeliCa Dude. Mobile FeliCa v4 has a lot of changes, listed below by version.

Mobile FeliCa 4.0 (Pixel 4) freed Android device manufacturers from having to use embedded secure element + NFC chips from the FeliCa Networks supply chain. Any FAST certified secure element will do, from NXP, STMicroelectronics, Thales, and other NFC chipset providers. Mobile FeliCa is pre-installed on all Pixel 4 and later models but only enabled for JP models. Other Android manufacturers selling Mobile FeliCa capable devices in Japan are likely doing the same. This development has resulted in a number of inexpensive Osaifu-Keitai SIM-Free smartphones released by Chinese manufacturers recently that are selling well. Hopefully it will have wider implications for inexpensive global NFC Android devices with pre-installed, and enabled, Mobile FeliCa. There are lots of people in Hong Kong who would buy one to use Octopus.

Mobile FeliCa 4.1 (Pixel 5/Pixel 6) introduced multiple secure element domains. This allows the device manufacturer to ‘own’ the eSE and load or delete Java Card applets. FeliCa Dude thinks that multiple secure element domains (MSED) might play a part in the MIC digital My Number Card due to launch on Osaifu Keitai devices in 2022 (now delayed until April 2023). My Number card uses NFC-B but MSED allows the Mobile FeliCa secure element to host it anyway, an interesting development.

Mobile FeliCa 4.2 or 5.0? The next version of Mobile FeliCa (MF) will hopefully support FeliCa SD2 next generation features that shipped in November 2020, features that power Suica 2 in 1 Region Affiliate Transit Cards launched in March 2022. These cards need to be on mobile for future MaaS service plans outlined by JR East which cannot happen until SD2 features are added.

The improvements in MF 4.1 certainly give Android device manufacturers the ability to update it over the air but don’t hold your breath. Standard industry practice to date has been ‘buy a new device to get new features’. Apple has been somewhat better in this regard: MIFARE support was added in iOS 12 for Student ID cards and iOS 15 fixed some Calypso bugs on ‌iPhone‌ XR/XS and ‌iPhone‌ SE.

An old FeliCa Dude Reddit post comment regarding Asus smartphones illustrates the pre-MF 4.0 situation: “any phone that lists ‘NFC’ compliance must support Type F (FeliCa), but as there is no Osaifu-Keitai secure element <aka Mobile FeliCa secure element>, you will be limited to reading and potentially charging physical cards: you cannot use the phone as a card itself.”

That was then, this is now.

People assume FeliCa support requires a FeliCa chip but this is not true. The evolution of hardware independent preinstalled Mobile FeliCa 4.x is very clear: the ‘FeliCa chip’ from Sony/FeliCa Networks requirement is long dead and gone. Manufacturers like Xiaomi may claim they make special models and add FeliCa chips just for the Japanese market, but that’s just marketing BS: they run Mobile FeliCa on the same NXP or Thales NFC chipsets they use everywhere.

Modern smartphones supporting FeliCa don’t have a FeliCa chip, everything from EMV to FeliCa and MIFARE runs on any GlobalPlatform certified secure element on any Android device. The key issue is not hardware anymore, it is what gets preinstalled and what does not. EMV is the default preinstall on all NFC secure elements. In the case of Google Pixel 4 and later Mobile FeliCa is preinstalled in all models but disabled on non-JP models (some people have succeeded in activating Mobile FeliCa via rooting). This is likely the same scenario for other Android manufacturers who ship Mobile FeliCa capable devices in Japan as they source the same NFC chipsets from NXP or Thales that Google does.

Hopefully the sum of recent Mobile FeliCa v4 developments, along with Garmin Suica, Fitbit Suica and WearOS Suica support, indicate that Mobile FeliCa Osaifu Keitai services will, eventually, become standard on Android devices as they have been on all iOS and watchOS devices since 2017.

Last updated 2023-04-01

Ignore NFC reader logos, advice for using Apple Pay in Japan

After the October 21 launch of Apple Pay WAON and Apple Pay nanaco e-Money cards, I updated my Apple Pay Japan chart. All I did was add WAON and nanaco logos to the official payment logos listed on the Apple Pay JP page (still not updated as of November 19):

After posting the update chart a reader asked a very good question: why not add the FeliCa reader logo as that is what you’ll often see on NFC readers in Japan. To which I say: ignore reader logos in Japan. Why? Because the reader physical compatibility mark that indicates the antenna location has nothing to do with what payments actually work at checkout. Apple isn’t doing anybody a favor listing the EMV logo in the Apple Pay Japan lineup. It only confuses users.

Let’s play that game again, the ‘which logo is the official NFC logo’ game. Choose:

The correct answer is #2, the NFC Forum logo. The reader physical compatibility mark for EMV is #1, FeliCa is #3. But you never see the NFC Forum logo on NFC readers, what you see is usually something like this:

The EMV mark on the reader tap area does not mean the store accepts EMV contactless…always check the payment acceptance marks.

The Panasonic reader shown above has both EMV and FeliCa logos on the tap area. The store has also attached a card that displays what payments are accepted, in this case both EMV (VISA, mastercard) and FeliCa (iD, Suica•PASMO, WAON, nanaco) are accepted. Looks good right? Not really. The EMV and FeliCa marks are the physical compatibility mark that indicate the antenna location. However, most people assume the physical compatibility mark mean the reader works for all payments…which it does not. Some stores with an EMV physical compatibility marked reader don’t support EMV, and vice versa: FeliCa is supported on the reader but not the POS checkout.

What to do? Let’s see…the NFC Forum is responsible for basic certification of all NFC devices so let’s put their logo on reader instead. Oh wait, can’t do that because people will think it’s a Nespresso machine instead of an NFC reader:

This slide says it all regarding NFC Forum efforts as an industry promotion org

Time for a new NFC logo.

It might seem like a good idea to separate NFC hardware from the payment services that run on top of the hardware. The reality is, it’s impossible to do because all-in-one NFC chips do it all. The NFC Forum could spend a ton of money creating a new NFC logo that can be used everywhere…but what’s the point? Nobody will use it even if they do.

NFC readers come in all kind of shapes and sizes for all kinds of end uses, from supermarket checkout, to transit gates, and vending machines, and much more. If nothing else remember this: the physical compatibility mark is there to indicate the antenna location and show you where to tap, that’s all it’s there for. It can be anything. It should match the service it’s intended to fulfill.

Are Chinese manufactured PAX NFC readers a security risk?

Probably not, but the FBI Raids Chinese Point-of-Sale Giant PAX Technology report from Krebs on Security has some thrilling bits:

“FBI and MI5 are conducting an intensive investigation into PAX,” the source said. “A major US payment processor began asking questions about network packets originating from PAX terminals and were not given any good answers.”

The source said two major financial providers — one in the United States and one in the United Kingdom — had already begun pulling PAX terminals from their payment infrastructure, a claim that was verified by two different sources.

“My sources say that there is tech proof of the way that the terminals were used in attack ops,” the source said. “The packet sizes don’t match the payment data they should be sending, nor does it correlate with telemetry these devices might display if they were updating their software. PAX is now claiming that the investigation is racially and politically motivated.”

Krebs on Security

FBI, MI5, unnamed sources? Sounds like a spy novel. The original Jacksonville WOKV report is down to earth local news reporting with the official statement from the FBI: “The FBI Jacksonville Division, in partnership with Homeland Security Investigations, Customs and Border Protection, Department of Commerce, and Naval Criminal Investigative Services, and with the support of the Jacksonville Sheriff’s Office, is executing a court-authorized search at this location in furtherance of a federal investigation. We are not aware of any physical threat to the surrounding community related to this search. The investigation remains active and ongoing and no additional information can be confirmed at this time.”

PAX NFC terminals and POS systems support EMV, FeliCa and MIFARE protocols and are used extensively in Japan in nationwide POS systems such as FamiMart and Doutor Coffee chains. However it’s important to remember that each protocol has a hardware certification process, for EMVCo, for FeliCa Networks and for MIFARE. Card companies also have their own hardware security and certification. And even though the story sounds scary, we don’t know what ‘major financial provider’ POS systems are pulling PAX readers*, what hardware models are involved and what kind of POS software they run (provided by PAX? Developed in-house?), or what exactly the FBI are investigating.

That said, this is much more real and interesting than the silly Apple Pay EMV Express Transit VISA security scare story pushed by the BBC, mindlessly repeated by tech sites and dubious ‘security experts’ who scare people into buying their ‘services’. The so-called Apple Pay EMV Express Transit VISA exploit was just a lab experiment, this is happening in the field. The PAX story won’t get much press however because it does’t have ‘Apple Pay’ in the headline. At least not yet…I’m sure some media hack out there will come up with one, something like ‘Apple Pay sends your personal payment data to China’. Only then will people start paying attention.

*UPDATE 2021-11-03
Bloomberg reports FIS Worldpay (also based in Jacksonville next door to PAX…interesting eh?) is pulling PAX NFC readers from client systems and replacing them with Verifone and Ingenico NFC readers. FIS said, “While we have no evidence that data running through PAX POS devices has been compromised, we have been working directly with clients to replace those devices with other options at no cost to them and with as little disruption to their business as possible.” No evidence but Worldpay is replacing PAX readers anyway…based on what exactly, heresy?

PAX NFC readers comprise less than 5% of Worldpay client POS installations so we’re not talking big numbers. Meanwhile PAX has issued a long winded statement (PAX Technology announcement and resumption of trading) addressing and refuting the security risk claims from Krebs and FIS saying it’s only a geolocation feature. We don’t know which PAX reader models are involved but I suspect they are Android based. That’s the problem with all those crappy Android OS based POS+NFC all in one terminals: not only do they have lousy Android performance, they have all the Android security risks too. Dedicated hardware is way better, performance-wise and security-wise.

Global NFC Google Pay will never happen

Let me rephrase that: Global NFC Google Pay will never happen because it depends on the device’s ability to run Osaifu Keitai apps.

To which I’ll add: because Google can’t be bothered building their own software stack in Android OS Google Pay that replaces Osaifu Keitai.

Osaifu Keitai is a smartphone only software stack that has not and can not be updated for the smart wearables era. This shortcoming is driving some interesting solutions, discussed in a recent Reddit thread lamenting that Pixel went cheap instead of deep…again.

Does the US version of the Pixel 6 Pro have FeLiCa / NFC-F?
This is the #1 reason I haven’t been able to move away from iPhones… I almost pre-ordered a 6 Pro today, but this is too much of a deal for me. Does anyone know if the US model will finally be compatible with FeLiCa (sic)?

Comment:
All Pixels sold in Japan since the 3 have Mobile FeLiCa NFC-F. However, Google Pay makes limited use of it. Unlike Apple Pay, Google’s implementation is limited to just a few apps in Japan. They are going to need to do a top-to-bottom overhaul of Google Pay to make this available worldwide. Not this year. But maybe as they integrate Fitbit and produce a watch, that might be the kick they need to make it work.

Reddit

Mobile FeliCa is installed and runs on Pixel models worldwide, however Pixel blocks the Osaifu Keitai stack from running except for Japanese models. Despite this stalemate on the Android side, we’ve seen a number of smart wearables with Mobile Suica released over the past year from Garmin and Fitbit. We’re also seeing signs that Suica support is coming to Wear OS. From a reader:

Suica appears to finally be coming to Google Pay for Wear OS. There’s strings like “FeatureRolloutsModule_ProvideSuicaSupportedonWearValueFactory,” “WearSuicaCard,” and “WearSuicaProvisioning” in the newest APK.

Wear OS, Garmin and Fitbit do without Osaifu Keitai by using Mobile Suica Lite which runs on Mobile FeliCa Cloud. This is fine for wearables but it does leave a service gap, Osaifu Keitai devices gets the full array of FeliCa services but wearables get a subset. This begs the question, what is the future of Osaifu Keitai when it’s limited to smartphones? Apple does without it which is why both iPhone and Apple Watch seamlessly deliver the same full set of Wallet services.

Only when Google does a top to bottom overhaul of Google Pay that replaces its current dependence on Osaifu Keitai can Global NFC Google Pay ever happen and allow Google to deliver a Pixel family of devices from smartphone to wearables, that truly rival Apple, feature for feature. We need that.

Google’s previous effort, the ill-fated Android Pay HCE NFC-F, along with cheap over deep premium Pixel devices, doesn’t instill confidence that Google cares about getting it right.