Monday 30 June 2014

Apple in payments: a disruptor's dilemma (mobilepaymentstoday.com)

This post is an attempt to look beyond what the presence or absence of any specific radio in iPhone 6 may mean to Apple's intent in payments and instead provide some color around three things that are part of this debate: a) Bring 800 million credit cards on file in perspective b) Address the question of radios on the device – a topic that has a disproportionate share of the debate and finally c) Consideration of steps made by Apple to secure both iOS and its devices as waypoints in its payments journey. Oh wait, that last one is not part of the Apple payments debate today. I believe it should be. Read on to see why.
First – the 800 million credit cards on file
The iTunes store counted towards a total of $2.4 billion in net sales during Q1 2014. Apple pays a negotiated card-not-present rate on its iTunes transactions. On hardware sales, Apple made roughly $51 billion in the same quarter, paying again a negotiated card-present rate. Is it any surprise then that Apple's Treasury Group spends more time focused on negotiating favorable card-present rates than worrying about the former? More savings = more time.
A tale of revenues
The 800 million credit cards on file (from 400 million back in Q2 2012) represents an amazing scale and yet completely underwhelming considering these 800 million accounts hardly spend anything of significance within iTunes. In fact, the revenue per iTunes account declined almost half (it was approx $25 in Q3 2011 and near $15 by Q1 2014) – while doubling in the number of accounts – which could be that a significant portion of the 400 million growth since 2012 is outside of U.S. and the lack of any meaningful iTunes content in those markets can explain why revenue has been lackluster.
There is a glimmer of hope in overall iTunes revenues as App-based revenue per user edges above $5 and I would think that when Apple rolls out the tried and true line of “hundreds of millions in cards on file," it's really speaking to the App developers that they have a proven, global card carrying base capable of spending real money on their apps. And less about turning those 800 million cards in to a retail tour de force.
800 million tokens
And even if it did mean the latter, realizing that dream requires banks and networks to play ball, these are not Apple-issued credentials nor where they hold risk, and therefore any rate related savings require a willingness from both those parties to reduce margins. Even as the second largest online retailer in the world (with $18.3 billion in 2013 online sales to boot), Apple faces considerable headwinds when negotiating rates for online hardware sales as it cannot rely on its own golden standard for risk reduction (TouchID in 5S) to assist in this process today. Will we ever see Apple enabling existing 5S customers to authenticate through TouchID to purchase next generation Apple hardware? Possibly, when the time is right.
Much more can be written about what those 800 million credit cards on file means in the context of a global card tokenization framework. Go here to read my own take on the topic.
Second – the radio
As I mentioned, the radio has grabbed a disproportionate share of the expert discourse. And understandably so. I myself am unconvinced that Apple shares the GSMA view of the NFC stack and business model.
Most recently, Morgan Stanley analysts predicted in favor of NFC in iPhone6 (link here), which to me looked as having several flaws in its understanding of Apple's approach to the radio, the Biggest of which is a lack of ability on the analysts part to differentiate between the radio and the secure element where the credential is hosted which inherits from the flawed GSMA view of NFC/SE. I believe Apple will outright reject this view, both because it does not serve its interests and because the payments ecosystem (merchants, banks, networks, Device OEM's) as a whole has largely abandoned this approach. And looking for the smoking gun in Apple's NFC approach, manifested in a secure element is not going to be found because it's simply useless and wasteful.
And yet, Apple's choice of radio does matter
I recently spoke to a couple of major retailers who happen to be less than ecstatic about the appeal of EMV. Despite Walmart throwing its clout behind EMV chip-and-PIN, merchants who have not yet upgraded their terminals know that they will be subservient to these terminals for at least another decade once they upgrade. As terminal makers like Ingenico and Verifone are choosing to package contactless alongside of EMV, merchants worry that if Apple chooses anything but NFC contactless (let's say BLE) then they are going to be locked out for another decade (or till the next refresh). If Apple chooses NFC, then there's hope that whatever Apple chooses to roll out will be supported by their point-of-sale. Payments via BLE finds no support with terminal makers at the moment and that stifles merchants ability to follow Apple in any non-NFC direction it may choose to take, in the short term. What I am trying to say is that payments via BLE or in a manner other than contactless has challenges that cannot be wished away in the current point-of-sale environment. Again, expect a lot of these ambiguities to be addressed with tokenization and respective modernization of risk mitigation procedures at the edges of the network as well as in transit. Read more here.
And then there is Host Card Emulation
That's another question I get these days: Will Apple support HCE? Don't forget HCE exists as a workaround to the GSMA model – and Apple needs no convincing to stay away from it altogether. With NFC, BLE and any other radio, when the time is right and legitimacy is afforded equally to all radios on the phone, Apple will choose the right combination. And the glue that Apple uses to tie radios and credentials together, well, they will just call that some weird iOS name.
Finally – iOS security
A discussion around Apple and payments can be hardly considered complete without a deeper look at how it approaches security. An iOS security discussion that is specifically oriented around the iPhone is very relevant considering how Apple sees the iPhone as a lifestyle device that has endless utility through the apps, services and devices that interact with it in the iOS ecosystem. It speaks to Apple's own aspirations to create a hub and spoke model with iPhone at the center securely communicating with accessories and services that are allowed to interact with it. And much of that intent is evident from how security is fused in to both the device and the operating system. I was not kidding about the fused part, literally, a unique ID is fused in to the A7 processor at the time of manufacturing, a Unique ID that you don't know, the apps running on the device don't know, and even Apple doesn't know, and yet everyone sees the results of its use by the encryption and decryption functions that are performed using this key.
“I am concerned about security”
When Feds conducted the mobile financial services survey in 2013 and asked the question: “What are the main reasons you have decided not to use mobile banking?," 49% of survey participants chose “I am concerned about the security of mobile banking”. On the topic of mobile payments, 38% of the survey participants indicated security as again the primary concern. As Apple enters the mobile payments fray, it has the enviable position that it does not need to define the concept as Google once had to and instead could chose on what matters most to the general public. And security undeniably is at the top of that stack.
So how does Apple attempt to address security as part of what it has already built (iPhone/iOS), and what it's likely to build – around payments?
It does so by building in incredibly sophisticated crypto in to the layers that make up the operating system and the hardware it wraps around (again the hyperbole isn't mine) examining what Apple discusses publicly about its own security efforts led to Steve Gibson calling the iPhone5S a “crypto marvel“. I personally think “a cathedral to applied cryptography” sounds better.
Case in point: the secure enclave.
Remember the unique ID I mentioned above that is fused in to the application processor during manufacturing? Well turns out there are actually two. And together they are used to encrypt every bit of data stored OR in transit. And the most important bits, the fingerprint data, is actually encrypted for the inch and a half of the wire it runs over from the sensor to the processor. And the A7 processor that receives it has no way of unpackaging it and does little more than sliding it in to a shared memory buffer (shared with Secure Enclave) and tripping a flag that alerts the Secure Enclave to its existance and location. The authentication tokens that are sent to authorize payments in iTunes also call the Secure Enclave home. And when you examine the question, will TouchID ever support third party apps or use-cases, one can see that Apple can reliably implement that support without ever sacrificing security. Accessing TouchID does not imply that others can access the Secure Enclave. The latter has no published interfaces other than what’s used by the A7 processor. It’s dead bolted to everyone else. It is built to withstand both calls for interoperability and privacy.
Good Entropy and the EMV Re-Play attack.
Further, every serious crypto requires (ironically) a consistent stream of irreproducible random noise, that is a source of good entropy. Recently a team of UK academics was able to exploit EMV terminals that had poorly designed random number generation towards replay attacks that are indistinguishable to the bank from valid chip transactions. If Apple expects becoming a point-of-sale is a destination in the natural order of evolution for iOS devices, then it certainly has equipped them to tackle the same security requirements. Apart from the two unique keys that are fused to the processor, all other cryptographic keys are created by the device’s hardware random number generator located in the Secure Enclave. Where other devices rely on a lot of non-deterministic input to generate good entropy, the gyro, accelerometer, camera, audio etc., iPhone relies on counting electrons that pass through a diode junction.
An expanding MFi program
Back in 2011, when I was assisting a major U.S. theme park in trialing dongles to replace cash payments in the park, one of the challenges we faced was that it was easy for an employee to swap out the park issued dongle with one of his own and accept payments in to his own merchant account. That fear alone prevented a mass rollout. And yet, the way iOS devices interact with the third-party accessory market is changing. And this has an impact to not only payment dongles that use the headphone jack, but also how iOS devices will communicate with beacons and other BLE devices. The MFi licensing program is soon to be broadened to include more Apple approved accessories (for example, home automation) that desires to communicate with the iPhone or iPad via Bluetooth, Wifi or cable – and must implement a custom integrated circuit provided by Apple. What this means is that Apple has absolute control of the hardware attachment market by means of securing communication between the device and the accessory. If your accessory omits to include the Apple IC, you are stuck using an analog mode to communicate. We are not far away from seeing more sophisticated chip/pin readers that can communicate via BLE with the device with Apple fully securing the transfer end-to-end.
Reading the tea leaves
If one pauses to analyze the careful sophistication with which Apple has chosen to implement security, it’s absurd to consider that it will lower those standards to embrace a Global Platform Secure Element, as being superior to its own methods. Extending the tightly woven blanket of third party attachment support to now include NFC (it currently supports WiFi, Bluetooth and lightning cable) will not pause a problem for Apple. But it’s just another communication channel, just another end-point. Security is pervasive in Apple’s ecosystem and certainly not just a derivative of the type of communication standard it may choose to use to transmit data.

And then one must detach from the payments focus, and step back to view what Apple is building as a whole. And when you do, one cannot omit to admit that payments is but one of the middle chapters that Apple will come to write. That, identity is the problem it’s trying to solve at a device level. Its own deterministic ways of verifying authentication are inherently more valuable than anything else currently available, and though silent but pervasive, it hopes that the fruits of that labor will be evident in the simplicity derived through the third party apps and services that use it, and the consumer will be wise to the reasons why. And that they will resoundingly voice their confidence on the platform with their wallet.

No comments:

Post a Comment