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.
Mark Gurman and Jillian Deutsch at Bloomberg also did everybody a favor unmasking PayPal as one of the instigators behind the EU Commission Apple Pay investigation. Yes, that PayPal…the financial service that snuffs out user accounts whose politics they don’t like, or worse just seizes their money.
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.
NFC has been on Android far longer than iPhone, and ‘open NFC’ at that, but is far less successful capturing mobile payment users than Apple Pay. This is because Android device manufactures made the classic mistake of taking the ‘let’s take awesome NFC technology and figure out how we’re going to market it’ approach. Jennifer Bailey’s Apple Pay team choose the hyper focused Steve Jobs approach of starting with the customer experience and building backwards while asking: “what incredible benefits can we give the customer, where can we take the customer?” That choice made all the difference.
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.
The user finally got his Mobile Suica to work right on Android after turning off the ‘No NFC while locked’ option.
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.
And the lesson? Apple Pay changed everything in the Japanese payments market, a catalyst that opened up competition and payment choices, for everybody. All boats rose together. It’s one of the most vibrant payment markets that Apple Pay operates in.
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.
Recommended reading: Ruimin Yang’s wonderful overview, “Apple Pay monopoly, are we really comparing ‘Apples’ with ‘Apples?” examines the Apple Pay system architecture, how it compares to other digital wallet platforms, (Google Pay, Samsung Pay) and what ‘open vs closed’ means in the ‘Apple Pay is a monopoly’ debate.
After a long gestation, and a COVID related delay, the mighty swipe MetroCard replacement finally shipped. The OMNY card: a white-label EMV bank payment card using the mastercard payment network, not a MIFARE or FeliCa smartcard like San Fransisco Clipper or Tokyo Suica. MetroCard missed the transit smartcard revolution of the late 1990’s, so MTA and their ticketing system management company Cubic Transportation Systems went all in with a new CUBIC designed system built using EMV payment network processing i.e. ‘open loop payment‘ regular EMV contactless credit/debit cards for mainstream transit fare use, and dedicated white-label EMV prepaid debit transit cards that replace MetroCard, relegated to a backup role for users who cannot use regular credit/debit cards for transit.
OMNY is envisioned and designed as a ‘one size fits all’ approach where bank card EMV payment networks (VISA, mastercard, American Express, etc.) are promoted as transit tickets since everybody supposedly already use bank cards for all daily life purchases. The addition of fare capping, basically a OMNY closed loop card feature for open loop, further encourages regular credit/debit card use and reduces the need for issuing OMNY card. And rest assured, MTA very much wants to get out of the card issuing business…good luck with that.
What is OMNY card? OMNY card is a private branded ‘white-label’ EMV prepaid debit card that comes with a CVC/CVV security number from a mastercard issuing agency, similar to private branded credit/debit store cards. Chicago Ventra tried a similar arrangement years ago. Ventra (also managed by Cubic by the way) has a long glitchy open loop history from its debut with the ill-fated mastercard prepaid debit Ventra card. Streets Blog had this to say about it in 2017.
Arguably it’s a good thing that the Ventra prepaid debit card is going the way of the dinosaur. The debit card function debuted with a long list of fees that had the potential to siphon of much of the money stored on the card, including:
A $1.50 ATM withdrawal fee A $2 fee to speak to someone about the retail debit account. A $6.00 fee for closing out the debit balance A $2 fee for a paper statement A $2.95 fee to add money to the debit account using a personal credit card A $10 per hour fee for “account research’’ to resolve account discrepancies
“These fees were probably not any different than other bank cards offered by Money Network or Meta Bank or other predatory banks,” says Streetsblog Chicago’s Steven Vance, who reported on the issue at the time. “But it was shameful for the CTA to be aligned with that.”
After a backlash, most of these fees were reduced or eliminated, but CTA retail outlets were still allowed to charge Ventra card holders a fee of up to $4.95 to load cash on the debit sides of their cards. So maybe it is for the best that the CTA is getting out of the bank card business.
Let’s hope the OMNY card issuer and MTA do a better job of hiding their white-label OMNY prepaid debit card fees. Because let’s face it, even though OMNY card is ‘closed loop’ it still uses the same EMV payment network that open loop cards do. I call it faux closed loop because OMNY doesn’t process their own fare payments, nor does OMNY (as of this writing) offer commuter passes, student discounts, etc. OMNY station kiosks that have yet to be installed will likely be modified ATM machines that take money instead of dispensing it.
A digital version of OMNY was advertised to launch on Apple Pay and Google Pay ‘soon’, although MTA now says it ‘expects’ to launch OMNY iOS and Android apps necessary for adding OMNY to Wallet sometime in 2023. We shall see but I suspect it will take longer due to potential card clash issues. When the OMNY digital card does finally launch, expect the same rebranded version of mastercard closed loop Ventra and Opal digital cards, all managed by Cubic. As most of the open loop systems in North America, UK and Australia are designed and managed by Cubic it’s helpful to compare their ticketing system profiles.
EMV Express Transit Mode card clash When you carefully analyze the different systems and Express Transit mode support listed on the Where you can ride transit using Apple Pay support page, one condition becomes clear: current transit systems do not support Apple Pay Transit cards and EMV Express Transit when the system uses both MIFARE and EMV open loop. It a choice between supporting one or the other, not both. Apple Pay Ventra illustrates the problem: it has Express Mode for the EMV Ventra card in Wallet but not for regular EMV Wallet payment cards.
This is because all EMV cards share the same NFC ID number which results in card clash at the gate reader. When cards share the same ID, only one card can be set for Express Transit Mode at any one time. Apple Pay China T-Union cards (EMV clone PBOC 2.0) do this automatically: turning on one card for Express Transit Mode turns off all other Express Mode Transit cards. Express Transit Mode Card settings will likely turn off any activated EMV payment cards when an OMNY card is added and turned on. Otherwise the complaints from Apple Pay MTA users would be endless.
OMNY is a new system built exclusively on EMV. When Apple Pay OMNY finally launches, and if Cubic or Apple somehow manage to resolve the EMV card clash issue, OMNY will be the first system to support both EMV as an Apple Pay transit card and EMV Express Transit mode for credit/debit cards.
EMV (and PBOC derivative) cards all share the same NFC ID, which results in card clash at the transit gate reader. Express Transit Settings automatically turns off Express Mode for other cards with the same ID to prevent this from happening when setting a new card for Express Transit.
The last big OMNY headache: MTA Railroad ticketing and region integration After OMNY card is launched on Apple Pay and Google Pay, the next OMNY challenge will be integrating Metro-North and LIRR commuter rail ticketing. A difficult task as none of the train line are equipped with NFC card readers. MTA has yet to unveil any commuter rail ticketing integration details. Ventra has the same problem, commuter rail ticketing remains the age old conductor visual inspection, no tap and go contactless. And OMNY will only be as strong as the other important transit pieces that can seamlessly fit into it over time: JFK, PATH, etc. Last but not least there are thorny open loop user data privacy issues.
OMNY truly represents the state of American public transit as it tries to get on board with mobile payments. Progress is good and welcome but instead of real meaningful development, American public transit will continue to be a confused mess of endless broken promises. This can’t change as long as America treats public transit as a subsidized welfare and jobs program instead of essential public infrastructure.
“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.”
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.
So the EU is going ahead with ‘open NFC’ antitrust charges against Apple. As posted back in August 2020, the whole open vs closed debate is not easy to define. It’s probably easier to look at it from the simplistic App Store debate of letting developers bypass Apple’s in-app payment mechanism to avoid paying the ‘Apple Tax’, because that’s the box most people will understand.
We’ve already seen banks and Apple chafing over transactions fees on multiple occasions, the latest being ‘Banks Pressuring Visa to Cut Back on Apple Pay Fees‘ because Apple dared release their own credit card under the Mastercard brand via Goldman Sachs. German banks and Australian banks in particular demand the right to use iPhone NFC in their own payment apps instead of Wallet so they can harvest the user data they can’t get via Apple Pay and drop Apple Pay support all together in favor of their own proprietary payment apps (our exclusive card comes with our exclusive app). But there’s an aspect of the ‘open’ argument that will not be discussed by EU regulators, the banks and credit card companies.
I’ve been watching ‘My Cousin Vinny’ a lot recently. I love the courtroom scenes with Joe Pesci’s Vinny character turning the prosecution arguments upside down. There’s a key scene early on when Vinny uses a pack of cards to convince Ralph Macchio’s character to give Vinny a chance to defend him: ‘the prosecutors are gonna show you bricks with solid straight sides and corners, but they’re going to show them in a very special way’ so that judge and jury see bricks instead of playing cards, which is what ‘open NFC’ arguments are: paper card illusions.
NFC is just hardware, it’s worthless without the software protocols that drive it. NFC also has different definitions. The bank industry defines NFC as NFC A-B ISO/IEC 14443. The NFC Forum defines NFC as NFC A-B-F for device certification. On the protocol side the bank industry defines NFC as EMV because this is their industry standard created and managed by EMVCo (Europay-Mastercard-VISA initially, now collectively owned by American Express, Discover, JCB, Mastercard, UnionPay and Visa).
Are EU regulators going to argue that ‘open NFC’ is defined as NFC A-B-F on the hardware side and EMV, MIFARE, FeliCa protocols on the software side? Of course not. They will narrowly define their Vinny brick as NFC A-B and EMV, and maybe Calypso as the transit protocol is used in France for transit. Why would they do that?
It’s very simple. European banking interests don’t want to pay transaction fees to Apple, the Apple Pay tax. They want to cut out the middle man with their own exclusive apps and harvest user data. They don’t want inconvenient questions such as why there are all those different NFC standards and protocols out there, how this came to be and what really constitutes ‘open’. Why did the ISO/IEC Joint Technical Committee choose Phillips NFC-A and Motorola NFC-B while shutting out Sony NFC-F? Was that part of creating an ‘open’ and level NFC playing field on the global marketplace? Of course not, it was about playing favorites while shutting Sony and Japan out of the game. Now they want to do the same to Apple Pay. I still think Junya Suzuki is right: the EU will never demand the same thing of Samsung Pay or Huawei Pay that they are demanding from Apple.
Sawada Sho tweeted a thoughtful question recently regarding the App Store in-app payment controversy. He pointed out that gaming and other platforms charge developers great deal of money for hardware and software access, nobody questions that. Apple offers a lot of access for a very low price, is it fair to demand free passage on the App Store because it is Apple? Sho san thinks the Apple transaction cut is a fair tradeoff. Some tech writers have occasionally asked the same basic question: what’s fair?
EMV, MIFARE and FeliCa all have licensing and certification fees that all customers (developers) pay. Apple has gone to a lot of expense licensing those technologies in addition to licensing a GlobalPlatfrom Secure Element that they build into their own Apple Silicon. Those costs are recouped by Apple Pay transaction fees and fund future developments like digital keys with UWB, ID and other Wallet goodies we’ll get later on in the iOS 15 cycle. I’ve said it before and say it again: Apple took the time and expense to build a first class restaurant and outsiders are demanding the right to use Apple’s kitchen to cook their own food to serve their own customers in Apple’s restaurant.
I guess EU regulators want to give those away free to EU banking interests and let them have their way in the interest of ‘open standards’ that they define and end up protecting the home turf. That sounds like a good deal to me.
You must be logged in to post a comment.