Full Block Accessibility Test

Apple held its annual developers conference last week to showcase its new features within iOS8. One area that still needs clarification is Apple’s intent for mobile payments. Cherian Abraham, Experian Decision Analytics mobile payments analyst, shares what he thinks Apple might look to do in the mobile payment space going forward. In my first post, I touched upon Apple’s program for third party hardware attachment market as being significant and likely to be a key aspect of its payments approach. In this post I discuss these three things: 1. How Apple’s new security paves the way for mobile payments 2. Bluetooth being secured enough where Payments is a use-case 3. Why the iPhone 6 will not have NFC Last week, 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 and 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. What about the latter? Apple’s new security blanket Well, first let’s look at 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: • An Apple certificate • Requisite cryptographic capabilities — preferably in hardware to comply. 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-the-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-the-middle attacks for Bluetooth in scenarios including payments. A cynical view of the MFi program would be to consider it 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 Apple is entirely justified in its role as the ecosystem owner to be at the front of the curve, to ensure security is not an afterthought – and instead to – mandate that data in transit or at rest is fully secured at all end-points. In fact, interest in Wearables, Home automation, Healthcare and Telematics are completely rewiring the rules of what it means to be an accessory anymore 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 to 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 do the MFi program, Bluetooth, iOS Security fit in within Apple’s plan to tackle retail payments? For that, let’s start with NFC. 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 it as they couldn’t scale with the costs that it confronted. 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 network’s definition of a payments future. Thus the current NFC impasse was born. 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 (for example, 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 until 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. Yet, with EMVCo publishing draft standards around tokenization one can argue that non-NFC modalities now are 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. Where is the opportunity among all this for Bluetooth? Let’s tackle 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’être, then in contrast Bluetooth had to worry about man-in-the-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 suboptimal. 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-the-middle attacks easy to implement and harder to detect. The approach to device pairing also differs from Bluetooth to BLE. Needless to say, it is 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 use here? It can. 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). This is far more secure than using Bluetooth alone and derives 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. This is another reason why if you are a BLE accessory maker Apple excludes you from having to participate in the MFi program. How can Apple secure Bluetooth and make it the standard of choice for a retail payment use case? 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. So 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? The message is clear. You must curry favor with Apple if you want to be able to securely communicate with the iOS ecosystem. 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 don’t 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, but the end-points are now much 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. Will the iPhone6 have 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 (for example, Isis). The radio will exist, but there will be no global platform secure element. 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. Since the radio becomes the bottleneck, it requires longer than a quick tap for more data to be transmitted. Proximity is a good guarantee for device presence as well as the customer, but it’s a poor vehicle for information. So why wouldn’t one try to relegate it to the initial handshake to enable authentification of 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. This data may include any and all tokenized payment credential along with loyalty, couponing and everything else. By 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. Yet, if NFC’s role is limited to the initial key negotiation, then the case can be made that NFC has very limited utility, it exists only to serve Apple’s security narrative, and utilizing NFC for the initial pairing strengthens the encryption and makes it harder to snoop. If it has only derived incremental value, would Apple care to put it on iPhone6 — and split its utility among customers using iPhone6 versus all others? With more than 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?  So where do I fall within this debate? I believe iPhone6 will not have NFC. Learn more about our Global Consulting Practice.  

There are some definite misunderstandings about the lifecycle of fraud. The very first phase is infection – and regardless of HOW it happens, the victim’s machine has been compromised. You may have no knowledge of this fact and no control. All of that compromised data is off in the ether and has been sold. The next phase is to make sure that the next set of fraudsters can validate those compromised accounts and make sure they got their money’s worth. It’s only at the last phase – theft – that any money movement occurs. We call this out because there are a lot of organizations out there who have built their entire solution on this last phase. We would say you are about two weeks too late as the crime actually began much earlier. So how can you protect your organization? Here are five take-aways to consider: User / device trust. Do this user and device share a history? Has this user seen of been associated with this device historically? It may not be fraud but it is something we watch for. User / device compatibility. Does the user align with devices they’ve used in the past? What are the attributes of the device with respect to user preferences, profile and so on. Device hostility. Look at its behavior across your ecosystem. How many identities has it been associating with? Is it associated with a number of personal attributes or focused on risky activities? Malware. Does this device configuration suggest malware? Because we have information about the device itself, we can show that it’s been infected. Device reputation. Has this device been associated with previous crimes? There are some organizations who have built their entire solution around device reputation. We believe this is interesting to include but it’s more important to look at everything in the context across your entire ecosystem rather that focus on just one area. Want to learn more? Listen to this on-demand webinar “Where the WWW..wild things are – when good data is exploited for fraudulent gain”.

FICO, a leading predictive analytics and decision management software company, has partnered with 41st Parameter®, a part of Experian® and a leader in securing online relationships, to fight fraud on card-not-present (CNP) transactions, the top source of payment card fraud today, while letting more genuine transactions proceed in real time. FICO is integrating 41st Parameter’s TrustInsight™ with the FICO® Falcon® Platform, which protects 2.5 billion card accounts and is used by more than 9,000 financial institutions worldwide. Authenticating the device being used in a transaction provides yet another layer of detection to the Falcon Platform, which includes proprietary analytics based on more than 30 patents. 41st Parameter’s TrustInsight™ solution provides a real-time analysis of a transaction, crowd-sourced from a network of merchants, that produces a TrustScore™ indicating whether the transaction is likely to be genuine and should be approved. TrustInsight helps reduce the number of “false positives,” or good transactions that are declined or investigated by the card issuer. The TrustScore, integrated with the FICO Falcon Fraud Manager Platform, provides a link between data the merchant knows and data the issuer knows to enable issuers to utilize additional information that is not currently available in their fraud detection process, including the identification of a cardholder’s “trusted devices.” Read the entire release here.