Apple in payments: Bluetooth edition
This is Part II of my Apple in payments take. In the first half of my take, I had touched upon Apple's program for the third-party hardware attachment market as being significant and likely to be a key aspect of its payments approach. So below, I will cover more on the approach, how Bluetooth will be the standard of choice (not NFC) and how Apple plans to secure Bluetooth enough to be able to handle payments.
Last month, 9to5mac reported that Apple had introduced a new specification for manufacturers in its MFi program (Made for iPad, iPhone and iPod) that allows them to create headphones that connect to iOS devices using a lightning connector instead of relying on the 3.5mm audio jack. Why is it important? Because as Apple looks to rid itself of any such remaining legacy vestiges, it's also shedding any ambiguity around who is in control of the iOS hardware ecosystem and what it means to be a third-party accessory maker – once reliant on open standards supported by all devices – to now serving at Apple's pleasure. It is a strategy that fits against the backdrop of an iOS ecosystem that is made up of software that is increasingly becoming more open, and hardware that is slowly being walled off primarily in the name of security. The former is evident in how Apple has opened up third-party access to core authentication services like TouchID.
And the latter? Well, as per what Apple has publicly acknowledged about the MFi program, every iOS device will initiate communication with a third-party accessory by asking it to prove sufficient authorization by Apple to respond with an Apple-provided certificate, which iOS subsequently verifies. Further, the iOS device then issues a challenge, which is then answered by the third-party accessory by a signed response. These two steps require that a third-party accessory must have both an Apple certificate as well as the requisite cryptographic capabilities, preferably in hardware to comply. And that is precisely what Apple does by encapsulating all this in an integrated circuit that it controls where the entire handshake is transparent to the accessory. With this, Apple's role in the third-party accessory market becomes non-negotiable. You think you have a cool accessory that requires a trusted connection and intends to share data with an iOS device? Unless you inherit Apple's controls, you are relegated to speaking analog and conducting a limited set of user-driven operations – Start, Pause, Rewind – standard Serial UART audio playback controls, usable only to headphones using the audio jack. Now, how about them apples?
It's important to note that these steps to validate whether an accessory is authorized to communicate with an iOS device can happen over the lightning connector, Bluetooth or WiFi. The advantage here is that this repels man-in-middle attacks because a malicious interceptor will not have the Apple IC to pass authorization, and subsequently will not have the negotiated key that encrypts all subsequent communication. The whole key negotiation occurs over Bluetooth. It is important because this approach can solve man-in-middle attacks for Bluetooth in scenarios including Payments.
A cynical view of the MFi program would be to view it as a toll that Apple is eager to extract from the third-party accessory makers building accessories authorized to communicate with an iOS device. A more pragmatic view would be to recognize Apple's efforts as an ecosystem owner, whose primary intent is authenticating any and all devices within and in the periphery of the iOS ecosystem and secure all inbound and outbound data transfers. With more iOS device types, and a heterogeneous accessory market (in fact, interest in wearables, home automation, healthcare and telematics are completely rewiring the rules of what it means to be an accessory anymore), Apple is entirely justified in its role as the ecosystem owner to be at the front of the curve, and ensure security is not an afterthought, and instead mandate that data in transit or at rest is fully secured at all end-points.
I believe this approach to security will be the mainstay of how Apple visualizes its role in enabling payments regardless of channel. Anything it does to reduce payments friction will be counterbalanced by serious cryptographic measures that secure devices that have a need to communicate in payments to authenticate, to encrypt and subsequently transfer a payment token. With TouchID today, it does so by verifying the fingerprint before authorizing the transmission of an authentication token from the secure enclave to an Apple server in the cloud. I don't doubt that the authentication token being sent to the Apple server in the cloud is itself signed by the device's unique ID, which is verified before the server completes the purchase with a card on file. Thus, crypto pervades everything the iPhone does, touches or trusts.
Apple and NFC
So how does all this (MFi, Bluetooth, iOS Security) fit in within the Apple's plan to tackle retail payments? For that, we need to start with NFC.
Anointed as the only way forward by networks and other stakeholders, every other approach was regarded as being less secure without much thought given to that classification by way of actual risk of fraud. You could build the best payments whatchamacallit and throw everything and the kitchen sink at it and be still branded as “Card Not Present” and inherit a higher cost. Understandably, merchants passed on, as they couldn't scale with the costs that it accosted. No self-respecting merchant could afford to scale unless they owned all of the risk (via decoupled debit, ACH or private label). All they could do was reject contactless and prevent themselves from being burdened by the networks definition of a payments future and thus born was the current NFC impasse.
And now, with merchants rolling out EMV compliant terminals, many of which have contactless built-in, they are desperately looking to Apple for clarity. If Apple does NFC, then they have the entirety of a terminal refresh cycle (approximately 10 years) within which they hope that common sense may prevail (say – debit as an acceptable payments choice via contactless) and correspondingly toggle the switch to begin accepting contactless payments.
If Apple goes in a different direction, a merchant who has chosen an EMV compliant terminal with or without contactless is locked out till the end of the current refresh cycle. But what if Apple went with Bluetooth? Two factors stand in the way: Bluetooth is not secure enough for payments today. And terminal makers need to comply.
And yet, with EMVCo publishing draft standards around tokenization, one can argue that non-NFC modalities are now being given fair share, where proximity is not the only guarantee for security, and other options such as Bluetooth can begin to address the challenge creatively.
So where is the opportunity among all this for Bluetooth? But before that, we have to tackle for its failings: Bluetooth range and device pairing that limit its utility in payments today.
Range is as much a curse as it is a blessing for Bluetooth. If security via proximity was NFC's raison d'etre, then in contrast Bluetooth had to worry about man-in-middle attacks due to its range. Though Bluetooth communication is invariably always encrypted, the method in which two devices arrive at the encryption key is sub-optimal. Since much of the early key negotiation between devices happens in the clear, brute forcing the shared secret that is key to encryption is a fairly easy and quick attack. And the range makes man-in-middle attacks easy to implement and harder to detect.
The approach to device pairing also differs from Bluetooth to BLE, needless to say even less secure for BLE. Pairing in a payments context brings up further challenges, as it has to be silent, customer initiated and simple to execute. I am not going to pair my iPhone with a point-of-sale by punching in “000000″ or another unique code each time I must pay.
Can NFC be of utility here? It can, And in fact, Bluetooth pairing is the only use case where I believe that Apple may feel there is utility for NFC, so that an out-of-band key exchange can be possible (versus an in-band key exchange wholly over Bluetooth), which is far more secure than using Bluetooth alone and derive a much stronger encryption key. An out-of-band key exchange thus enables both devices to agree on a strong encryption key that can prevent malicious third parties from splicing themselves in the middle. BLE, however, does not allow for out-of-band key exchange, and therefore is limited in its utility. Which is another reason why if you are a BLE accessory maker, Apple excludes you from having to participate in the MFi program.
And so, how can Apple secure Bluetooth and make it the standard of choice for a retail payment usecase?
The answer to that lies inside Apple's specification for MFi participants manifested in the form of the integrated circuit Apple provides to them so that these iOS accessories may authorize themselves to an iOS device and secure the communication that follows. This IC which encapsulates the initial setup, including the certificate, mutual key negotiation and deriving the encryption key, can support Bluetooth. And if all that ails Bluetooth can be cured by including an IC will point-of-sale manufacturers like Verifone and Ingenico line up to join Apple's MFi program?
And would they? The message is clear: you must curry favor with Apple if you want to be able to securely communicate with the iOS ecosystem. And that is no tall barrier for terminal makers that would willingly sacrifice far more to be able to speak to 800 million iOS devices and prevent being made irrelevant in an ever-changing retail environment. So why not include a single IC and instantaneously be able to authorize to that broad ecosystem of devices, and be capable of trusted communication? And if they do, or when they do, how will merchants, networks and issuers react?
Today a point-of-sale is where everything comes together – payments, loyalty, couponing – and it's also where everything falls apart. Will this be considered Card Present? Even with all the serious crypto that would become the underpinnings of such a system, unfairly or not – the decision is entirely that of a few.
Networks and issuers
To answer how they may respond, we must ask how they may be impacted by what Apple builds. Is Apple really upending their role in the value chain? I believe Apple cares little about the funding source. Apple would instead defer to the merchants who believe it should be debit, and the issuers who believe the customer should choose and secretly hope that it is credit. I can't seem to think that Apple would want to get between those two factions. It wants to build simply the most secure, easy way to bring retail payments to iOS devices and allow all within the transaction flow to benefit. The rails do not change, just the end-points are now more secured than they ever were, and they form a trusted bond and a far bigger pipe. A customer who authenticates via TouchID, a phone that announces to the point-of-sale that it's ready to talk, a smart circuit that negotiates the strongest encryption possible while being invisible to all, and a token that stands-in for your payment credential that is understood by the point-of-sale. It is business as usual, and yet. not.
All that, and no mention of NFC. So, will iPhone 6 need NFC?
The presence of NFC in iPhone 6, if it's announced, will not mean that NFC will be utilized in the same manner as it is today (say: Isis). The radio will exist, but there will be no Global Platform Secure Element. The radio will exist, but it won't be used to move the credential to the point-of-sale.
Today the role of the radio is instrumental (in both Secure Element or HCE cases) in transmitting the PAN to the Point-of-sale. When there are coupons that need to be presented and reconciled at the point-of-sale, things begin to get complex. It requires longer than a quick tap as the radio becomes the bottleneck for more data to be transmitted. Proximity is a good guarantee for device presence, and subsequently the customer, but it's a poor vehicle for information. So why wouldn't one try to relegate it to the initial handshake to authenticate the device and therefore the customer with the point-of-sale?
As I mentioned above, if Apple uses NFC, its role will be to facilitate an out-of-band key exchange to secure the subsequent Bluetooth communication so that an iOS device can trust the point-of-sale and securely transmit payment data. Data that may include any and all tokenized payment credential along with loyalty, couponing and everything else. Using NFC for out-of-band authentication in conjunction with the authentication IC (provided by Apple) in the point-of-sale, Apple can run circles around the limitations imposed by a pure NFC approach, exceeding it on usability, security, adaptability and merchant utility.
And yet, if NFC's role is limited to the initial key negotiation then the case can be made that NFC has very limited utility. That it exists only to serve Apple's security narrative, that utilizing NFC for the initial pairing strengthens the encryption and makes it harder to snoop. And if it has only derived incremental value, then would Apple care to put it on iPhone 6 and split its utility between customers using iPhone 6 vs. all others?
With over 400 million iPhones out there that can support Bluetooth LE and iOS8, why ignore that advantage and create a self-induced dependency on a radio that has no subscribers today? And the retail landscape is hardly standing still as it is.
So where do I fall within this debate? I believe iPhone 6 will not have NFC.
Photo courtesy of Sean MacEntee.
Cherian Abraham Cherian is a Mobile Payments Advisor with Experian Global Consulting. He is also an advisor to ModoPayments. As a mobile payments veteran and founder of Drop Labs, Cherian has worked with leading banks, retailers, mobile platform providers and startups in this space. Opinions expressed here are strictly his own, not that of Experian. www