If I had an Australian dollar for every online complaint of Mobile myki, the mobile version of Public Transport Victoria’s (PTV) myki transit card in the Melbourne region, I could probably purchase a nice bit of property there. Reddit forums regularly erupt with mobile myki mind melting nonsense, invariably bashing Apple for refusing to put myki in Apple Pay because Apple ‘doesn’t support HCE’ or because they charge a ‘30% commission’. Neither of them true. myki is MIFARE which has never used HCE and Apple Wallet already supports lots of MIFARE transit cards.
The whole HCE thing is a straw man anyway: embedded secure elements (eSE) are standard on NFC smartphone chips these days. The reason why Île-de-France Mobilités (IDFM) chose HCE for Smart Navigo on Android for example, had nothing to do with Android devices lacking an eSE, it was simply that IDFM didn’t want to deal with Android manufacturer ‘gatekeepers’. Imagine the nightmare of asking every Android manufacture to issue firmware updates for older devices to support Calypso on the eSE. There was no chance in hell they would listen or do it for free, so IDFM and Calypso spent a lot of time and money creating a special HCE version of Calypso, that doesn’t support Express Transit Mode, just for Android (but not for Samsung Pay devices which use native eSE and support Express Transit Mode).
Why IDFM and Calyspso did this is all you need to know about the chaotic mess that is Android NFC. When Smart Navigo comes to Apple Wallet later this year, it will run on iPhone 8/Apple Watch 3 and later without a hitch in full Express Transit Mode glory because firmware, eSE and software are upgraded in a single iOS update. That’s the advantage of having a good gatekeeper who’s on the job.
As for the 30% commission straw man, Apple Pay doesn’t ‘charge a commission’ for using transit cards, they only take a negotiated commission when a credit card is used to add money to the transit card. Why PTV and Apple haven’t reached an agreement yet is a mystery, but judging from myki user complaints, the mobile myki backend system might not be up to Apple’s user experience high-bar. And the myki system is about to get much more complicated: PTV is hitting the reset button.
Open loop envy PTV has Opal open loop envy and want EMV contactless cards to replace most of myki. This is certainly doable but there is the issue of the native MIFARE myki already on mobile. Oyster and Opal cards are MIFARE too but those systems added EMV contactless support as the foundation for ‘mobile’, relegating MIFARE as legacy plastic. By doing this they offloaded the card issuing operation to VISA/Mastercard/AMEX card issuers, who already have digital card systems in place and agreements with digital wallet operators. myki having come this far with mobile however is going to be a real juggling act, can PVT, or whoever wins the service contract, keep all the service balls in the air while going forward?
There is also the problem of Express Transit Mode support. Look carefully at Apple Express Transit Mode small print and you’ll notice that mobile EMV and mobile MIFARE transit card Express Transit Mode don’t coexist on the same system. It’s one or the other, never both. I suspect a smart Express Mode that chooses the right transit card for the job depends on smart modern transit gate reader hardware with the latest firmware and updated backend software. Getting the latest, greatest transit gates/readers installed takes time and money. Mostly money. Buckle up myki users, it’s going to be a bumpy ride to mobile transit card nirvana.
Ahh springtime, flowers and the annual Apple Platform Security (APS) update. This year’s version has many Apple Pay housekeeping changes. Previous versions put everything Apple Pay in a single section. In keeping with Apple spinning out iOS 15 Wallet app as a separate identity, Wallet has its own separate section now, covering all the things Jennifer Bailey unveiled at WWDC21: hotel-home-office keys and ID in Wallet. The Apple Pay section adds a new category for Tap to Pay on iPhone with some interesting bits.
The Tap to Pay on iPhone servers manage the setup and provisioning of the payment kernels in the device. The servers also monitor the security of the Tap to Pay on iPhone devices in a manner compatible with to the Contactless Payments on COTS (CPoC) standard from the Payment Card Industry Security Standards Council (PCI SSC) and are PCI DSS compliant.
The Tap to Pay on iPhone server emits decryption keys to the Payment Service Provider after validation of the integrity and authenticity of the data, and after verifying that the card read was within 60 seconds of the card read on the device.
What’s interesting to me is that Tap to Pay on iPhone servers are providing a seamless payment reader experience in the same way that Apple Pay servers provide a seamless pay experience. It just works, from setup to use, the same tight integration allows payment service providers to focus on POS app development and forget about the hardware because Apple Pay takes care of everything. As Junya Suzuki tweeted recently, a lot of payment reader hardware is suddenly junk compared to what iPhone is providing with tight mobile integration and Tap to Pay servers on the backend. Now with Tap to Pay apps on the horizon, good thing that iOS 15 Wallet expanded the secure element max to 16 ain’t it?
Speaking of Wallet, this separate section covers all things “access credential” related (hotel-corporate-home-car-student ID) with App Clips suggested for provisioning multifamily home keys. Transit now includes eMoney cards (or is it e-Money, Apple seems confused about it just like Express Mode vs Express Transit) and IDs in Wallet is covered in detail. There is also an intriguing iOS 15.4 Wallet security tweak:
In iOS 15.4 or later, when a user double-clicks the side button on an iPhone with Face ID or double-clicks the Home button on an iPhone with Touch ID, their passes and access key details aren’t displayed until they authenticate to the device. Either Face ID, Touch ID, or passcode authentication is required before pass specific information including hotel booking details are displayed in Apple Wallet.
It sounds almost exactly what we already do with regular Apple Pay cards. Perhaps keys and passes only show a generic icon and checkmark with Express Mode with the double-click + authentication required for show details…it’s not very clear.
The whole security expert thing reminds me of what my uncle the doctor (who ran a medical research lab at Columbia University) used to say about his disdain for pharmaceutical companies, “They don’t want to cure you, they just want to keep ‘treating’ you with their medicines.” Human nature never changes. The gist is that EMV Express Transit Mode will always be a thorn in Apple Pay’s side because the security is up to the card companies.
The document is worth your time is you have any interest in Apple Pay and Wallet.
(The) Digital Markets Act will…require companies designated as gatekeepers to ensure effective interoperability with hardware and software features they use themselves in their ecosystems. This includes access to NFC for mobile payments.
Today’s case addresses a conduct by Apple that has been ongoing since Apple Pay was first rolled out in 2015 <sic, 2014 actually>. This conduct may have distorted competition on the mobile wallets market in Europe. It prevented emergence of new and innovative competition that could have challenged Apple.
Both pieces miss important context surrounding the debate however…and with this issue context is all, especially how Apple Pay is playing out in other global markets. Most of what follows I’ve covered in earlier posts but hope to pull the various issues together in one post. Yet again, we kickoff with an updated Apple Pay diagram.
The so called Apple ‘NFC chip’ is not a chip at all but a hardware/software sandwich. The Apple Pay ecosystem described in iOS Security is a collection of tightly integrated polished pieces: Secure Element, Secure Enclave, NFC Controller, Wallet and Apple Pay Servers, all wrapped into a slick, easy to use UI with a final security wall of ‘secure intent’, a double-click side button hot-wired to the Secure Element. This approach has been so successful that people divide mobile payments history into pre-Apple Pay and post-Apple Pay eras.
Apple Pay has a very simple rule: any card that loads a Java Card applet into their embedded secure element (eSE) has to reside in Wallet app. The maximum number depends on how many Java Card applets it can hold at any one time, the previous limit was 12, the iOS 15 Wallet limit is 16 cards. Developers have two ways to access iPhone NFC: 1) Core NFC framework for NFC operations that don’t use the secure element, 2) Secure Element pass certificates for NFC operations that need secure element transactions (payments, keys, ID, passes). Any developer who wants to run applets in the eSE has to apply for a PassKit NFC/Secure Element Pass Certificate. This is covered by NDA but a company called PassKit (not Apple) gives us an idea what Apple’s 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.
The end to end user experience, the whole reason behind the success of Apple Pay. But this gatekeeping is what riles banks and financial service providers who want to load their applets into the secure element without the Apple Pay gatekeeping, without the Apple Pay ecosystem and without the Apple Pay commission. They want to do their own transactions with their own app for free. This is what the EU Commission means when Vestager says: “Evidence on our file indicates that some developers did not go ahead with their plans as they were not able to to (sic) reach iPhone users.” It should read: when they were not able to reach iPhone users for free. Either the developer didn’t apply for a Secure Element Pass, didn’t pass the certification process, balked at Apple’s certification conditions, or couldn’t agree on Apple Pay commission rates.
Secure element gatekeeping is not new, it is an essential part of the secure element system:
A Secure Element (SE) is a microprocessor chip which can store sensitive data and run secure apps such as payment. It acts as a vault, protecting what’s inside the SE (applications and data) from malware attacks that are typical in the host (i.e. the device operating system). Secure Elements handle all sorts of applications that are vital to our modern digital lives…
Mobile Payments Here, the Secure Element securely stores card/cardholder data and manages the reading of encrypted data. During a payment transaction it acts like a contactless payment card using industry standard technology to help authorize a transaction. The Secure Element could either be embedded in the phone or embedded in your SIM card.
Lifecycle management It’s crucial that SE-embedded devices are secure throughout their lifecycle. That’s why Secure Elements need to have an end-to-end security strategy. It’s no use developing a robust security solution for a device which becomes obsolete after a period of use. This is why Secured Elements can be updated continuously to counter new threats.
Few people, especially a PayPal or EU Commission vice president, discuss the crucial secure element lifecycle management aspect. It’s not convenient for them to say the secure element ‘gatekeeper’ is responsible for keeping it secure. Far more convenient for their arguments to omit this, portray gatekeeping as unnecessary and gatekeepers as evil. In the end however, Apple has to maintain secure element updates from the various licensed secure element providers (EMV,FeliCa Networks, MIFARE, and so on) if secure payments are going to work at all This is what people who say, ‘it’s my device, we should be able to use NFC how we want,’ do not understand.
People also forget that nothing is free, you get what you pay for. With Apple Pay as gatekeeper, users get simplicity, innovation and feature updates. Simplicity: users get NFC they can use out of the box without Android-like NFC complexity such as secure element positions and obscure express mode settings.
Innovation: Apple Pay has features like Global NFC. iPhone and Apple Watch are the only smart devices that come with FeliCa built in as standard to use in Hong Kong or Japan, while Android limits functionality by market region. It’s astounding that Android, not even Google Pixel Android, has matched this basic functionality yet. We’re seeing more innovation as Ultra Wide Band (UWB) extends Wallet functionality to include ‘Touchless’ car keys and eventually, UWB enhanced automatic card selection as you approach the reader; more helpful than you might think.
Japan is key to understanding what’s really going on in the Apple Pay monopoly debate. Japan was the first market with an established mobile payment platform in place, long before mobile EMV contactless payments took off in Europe. iPhone also has a much larger marketshare in Japan than it does in Europe. It’s a shame people pass up the opportunity to learn from the successes and failures here.
So what’s the EU Committee vision for ‘open NFC’? I think it’s a rehash of the secure element wars when carriers locked mobile payment services to SIM contracts. In 2013 Google incorporated SimplyTapp HCE (Host Card Emulation ‘secure element in the cloud’) technology as a NFC ‘workaround’ to ‘free’ NFC from the evil clutches of mobile carriers. Sound familiar? Android NFC has never been right since.
How little things change, swap ‘evil mobile carriers’ for ‘evil Apple’ and you have the same self serving ‘open’ vs ‘closed’ NFC chip nonsense that people are debating today. FeliCa Dude, the ultimate industry insider who has experienced it all, said it best: ‘It’s all eSE or nothing now.’
And yet we now have Île-de-France Mobilités (IDFM) turning back the clock, circumventing the eSE on NFC equipped Android devices and going all in with HCE for IDFM’s Smart Navigo service for Android. To me this says all you need to know what European priorities are regarding the ‘open NFC’ model: eliminate eSE gatekeepers by forcing the less secure network dependent HCE as a required option. Good luck with that. From a transit perspective, based on Mobile Suica user experiences, I don’t think HCE Smart Navigo will be a smooth ride.
The EU Committee ‘open NFC’ vision might look ideal…to Apple Pay competitors. Regular users however, will have to deal with the ugly reality of multiple NFC apps, multiple NFC secure element modes and clashing updates that cancel out NFC services. Apple Silicon eSE space is limited to 16 cards. If that sounds like a lot now, wait until you have credit cards, transit cards, home, car and office keys and ID installed along with ‘open’ NFC apps wanting their own eSE space too. Services will be squeezed out forcing the user to intervene. If the EU Committee thinks this environment fosters competition and innovation while growing mobile payment use, dream on.
Japanese tech journalist Junya Suzuki has covered NFC mobile payment developments in Europe, America and Japan for over 2 decades. He doesn’t think the EU is playing an even hand here, in his opinion Samsung and Huawei would never face the scrutiny that Apple now faces. In typical European cultural fashion, EU motives pay lip service to fair open markets while playing an underhanded game of chess to make Apple do what EU banking interests want Apple to do. In other words, a double standard.
What does Apple need to do? I’ve always said that Apple needs to make the Secure Element Pass application process as transparent as possible. Keeping the blackbox NDA process as it is now makes Apple Pay a target, increasingly difficult to defend the status quo. Secure Element access on the level of Core NFC is a long shot, the very definition of a secure element means there has to be a developer certification process similar to EMVCo, FeliCa Networks, MIFARE, Calypso Networks Association, etc., that protects the privacy and business interests of all parties. But it would be great if there is a middle way where Apple can securely open things up for iPhone as a digital wallet, and iPhone as a payment terminal. We’ll see if Apple has anything to say about the subject at WWDC22.
That was quick. When I made the above table for mobile wallet chokepoint, there was no indication we’d get EMV confirmation so quickly. Many were quick to applaud sanctions against Russia to stop the war with Ukraine, and while stopping war is always the right thing to do, hurting citizens is never the right thing to do. Turning off basic digital wallet services should give people pause. What is easily done in one place can be easily done anywhere.
It’s also not clear cut how it is being done. Is Apple turning off select Russian bank services in Wallet or turning off select payment applets in the Apple Pay secure element, or turning off Wallet for Russian Apple ID users? Most likely the first but there’s no way to be sure and there is no way that Apple or Google will ever tell us.
Long lines at Moscow Metro transit gates are not so clear cut either. Open loop isn’t standard on all transit gates, most them being Troika transit card only, and according to a Twitter follower, physical Troika card only, not Google Pay/Samsung Pay Troika which only rolled out recently. If so this suggests the (so far only one) picture of long lines could be due to Troika system issues instead of Apple Pay/Google Pay/Samsung Pay, hacking, or something else.
VISA and mastercard soon followed and cut their services in Russia. Many people in Japan noted how easily all this happened and expressed their distrust, saying they would think twice about using digital wallet services from Apple and Google. Many also noted the importance of Japan having it’s own FeliCa technology and FeliCa based e-Money payment network
The value of non-EMV native payment networks controlled and operated by native companies should be clear to everyone by this point. Always, always have a backup plan. One thing is certain, warfare that attacks basic public service infrastructure like transit and digital wallets, far and away from any front line, is the new ugly reality.
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.
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
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.
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.
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.
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.