Apple in Payments: Bluetooth Edition


This is the Part II of my Apple in Payments take – and it’s early because of the leak last week around Apple’s MFi program. In the first half of my take, I had touched upon Apple’s program for 3rd 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 Thursday, 9to5mac reported that Apple has 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, an d 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 3rd 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 3rd party accessory by a signed response. These two steps require that a 3rd 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 3rd 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 3rd 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 with-in 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 – Infact, 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.

So how does all these – 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 (approx 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 usecase where I believe that Apple may feel there is utility for NFC, so that an out-of-band key exchange can be possible (vs 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, 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 – who would willingly sacrifice far more to be able to speak to 800M 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 iPhone6 need NFC?

The presence of NFC in iPhone6 – 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 iPhone6 – and split it’s utility between customers using iPhone6 vs all others?

With over 400M 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 iPhone6 will not have NFC.


You can connect with me on LinkedIn here.

Board of Advisors at SimplyTapp - creators of Host Card Emulation driving democratization and open access to NFC in Android. Mobile Commerce & Payments Lead at Experian Global Consulting, serving Experian's clients in Banking, Retail, Consumer Credit & Payments. A strategic adviser w/ over 17 years of international Tech & Business Strategy consulting, advising firms in banking, retail & asset mgmt that seek clarity & insight in to the myriad business models around payments, fraud & commerce. Founded DROP Labs, a mobile payments/commerce strategy & advisory practice. Tweets here. I'm on LinkedIn here.
Cherian Abraham
View all posts by Cherian Abraham
Tagged , , , , , , , , , , , , , , , , , , ,