Lessons from Google Wallet: how wireless carriers undermined mobile security

Apple is expected to launch an NFC payments solution for iPhone. For the small community working at the intersection of NFC, payments and mobile devices, Apple’s ambitions in NFC has been one of the worst-kept secrets in the industry. The cast of characters overlaps significantly: there are only so many NFC hardware providers to source from, so many major card networks to partner with and very similar challenges to overcome on the way. Of the many parallel efforts going on in this space, some played out in full public view. Wireless carriers have been forging ahead with field trails for their ISIS project— now rebranding to Softcard to avoid confusion with the terrorist group. Others subtly hinted at their plans, as when Samsung insisted on specific  changes to support its own wallets. Then there was Apple, proceeding quietly until now. With almost three years since the initial launch of Google Wallet, now is a good time to look back on that experience, if only to gauge how the story might play out differently for Apple.  [Full disclosure: this blogger worked on Google Wallet 2012-2013. Opinion expressed here are personal.]

Uphill battles

There are many reasons why launching a new payment system is difficult and for precisely the same reasons, to pinpoint the root cause for why a deployed system has been slow to gain traction. Is it the unfamiliar experience for consumers, tapping instead of swiping plastic cards? (But that same novelty can also drive early adopters.) Were there other usability challenges? Is it the lack of NFC-equipped cash registers at all but largest merchants? Or was that just a symptom of an underlying problem: unclear value proposition for merchants. Tap-transactions have higher security and less fraud risk, yet merchants are still paying same old card-present interchange rate. For that matter did users perceive sufficient value beyond the gee-whiz factor? Initial product only supported a prepaid card and Chase MasterCards, limiting the audience further. All of these likely contributed to a slow start for Google Wallet.

But there was one additional impediment having nothing do with technology, design, human factors or economics of credit cards. It was solely a function of the unique position Google occupies, both competing against wireless carriers over key mobile initiatives, while courting the very same companies to drive Android market share.

When consumers root their phone to run your app

When the project launched in 2011, it was limited to Sprint phones. That is bizarre to say the least. All mobile app developers crave more users. Why would any software publisher limit their prospects to one carrier alone, and not even the one with largest customer base at that? There is no subtle technical incompatibility involved. There is nothing magical about the choice of wireless carrier that unlocks hidden features out of the same exact commodity hardware that is not available to a different user. It was a completely arbitrary restriction that can be traced to the strained relationship between Google and wireless carriers who had cast their lot with ISIS.

Outwardly Verizon stuck to the fiction that they were not blocking the application deliberately. In a figurative sense, that was correct. Google Wallet itself contained a built-in list of approved configurations. At start-up the app would check if it was running on one of these blessed devices and politely inform the user that they were not allowed to run this application. In effect the application censored itself. This was a way of making sure that even if a determined user managed to get hold of the application package (so-called APK, which was not directly available from Android Play Store for Verizon, AT&T and T-Mobile customers) and side-load it, it would still not refuse to work. That charade continued to play out for the better part of 2 years, with occasional grumblings from consumers and Verizon continuing to deny any overt blocking.

Users were furious. Early reviews on Play Store were a mix of  gushing praise with 5-stars, and  angry 1-star rants complaining that it was not supported on their device. Many opted for rooting their phone or side-loading the application to get it working on the “wrong” carrier. (Die-hard users going out of their way to run your mobile app would have been a great sign of success in any other context.) Interestingly there was one class of devices where it worked even on Verizon: the Galaxy Nexus phones that Google handed out as holiday gifts to employees in 2011. In a rare act of symbolic defiance, it was decided that since Google covered every last penny of these devices with no carrier subsidy, our employees were entitled to run whatever application they wanted.

One could cynically argue that capitulating to pressure from carriers was the right call in the overall scheme of things. It may have been a bad outcome for the mobile payments initiative per se, but it was the globally optimal decision for Google shareholders. Android enjoys a  decisive edge over iPhone in market share but that race is far from being decided. And US carriers have great control over the distribution of mobile devices. Phones are typically bought straight from the carrier at below-cost, subsidized by ongoing service charges. Google made some attempts to rock the boat with line of unlocked Nexus devices, as did T-Mobile with their recent crusade against hardware subsidies. But these collectively made only a small dent in the prevailing model. Carriers still have  a lot of say in which model of phone running what operating system gets prime placement on their store shelves and marketing campaigns. Despite the occasional criticism as surrender monkeys on net-neutrality, Google leadership had a keen understanding of these dynamics. They had intuited that a fine line had to be walked. Keeping carriers happy was priority for #1, while making room for occasional muck-racking with unlocked devices and spectrum auctions. It is simply not worth alienating AT&T and Verizon over an experiment in mobile payments, an initiative that was neither strategic nor likely to generate significant revenue.

The secure element distraction

Curiously the original justification for why Google Wallet could be treated differently than all other apps came down to quirks of hardware. During its first two years, NFC payments on Google Wallet required the presence of a special chip, called the embedded secure element. This is where sensitive financial information, including credit-card numbers and cryptographic keys used to complete purchases were stored. Verizon pinned the blame on SE when trying to justify its alleged non-blocking of Google Wallet:

Google Wallet is different from other widely-available m-commerce services. Google Wallet does not simply access the operating system and basic hardware of our phones like thousands of other applications. Instead, in order to work as architected by Google, Google Wallet needs to be integrated into a new, secure and proprietary hardware element in our phones. We are continuing our commercial discussion with Google on this issue.

One part of this is undeniably true: the secure element is not an open platform in the traditional sense. Unlike a mobile device or PC, installing new applications on the SE requires special privileges for the developer. This is intentional and part of the security model for this type of hardware; limiting what code can run on a platform can reduce its susceptibility to attacks.  But the great irony of course is that a different type of secure element with exact same restriction has been present all-along on phones: SIM cards. Both the embedded secure element and SIM cards follow the same standard called Global Platform. Global Platform lays down the rules around who gets to control applications on a given chip and exactly what steps are involved. Short version is that each chip is configured at the factory with a unique set of cryptographic secrets, informally called “card manager keys.” Possession of these keys is required for installing new applications on the chip.

For SIM cards the keys are controlled by, you guessed it, wireless carriers. ISIS relies on carriers ability to install their mobile wallet applications on SIM cards, in exactly the same way Google Wallet relied on access to embedded secure element. SIM cards have been around for much longer than embedded secure elements. Curiously their alleged lack of openness seems to have escaped attention. When was the last time Google threw a temper tantrum for not being allowed to install code on SIMs?

The closer one looks at Global Platform and SE architecture, the flimsier these excuses about  platform limitations begin to sound. The specific hardware used in Android devices supported at least 4 different card-manager keys. One spot was occupied by Google and used for managing Google Wallet payments code. Another one was reserved by the hardware manufacturer to help manage the chip if necessary. Remaining two slots? Unused. Nothing at the technology level would have prevented an arrangement for wireless carriers to attain the same level of access as Google. This is true for even for devices already in the field; keys can be rotated over the air. One can envision a system where the consumer gets to decide exactly who will be in charge of their SE and the current owner is responsible for rotating keys to hand off control to the new one. If that sounds like too many cooks in the kitchen, newer versions of Global Platform support an even cleaner model for delegating partial SE access. Multiple companies can each get a virtual slice of the hardware, complete with freedom to manage their own applications, without being able to interfere with each other. In other words multiple payment solutions could well have co-existed on the same hardware. There is no reason for users to pledge allegiance to Google or ISIS; they could opt for all of the above, switching wallets on-the-fly. Those wallets could run along-side applications using NFC to open doors, login to the enterprise system or access cloud services with 2-factor authentication, all powered by the same hardware.

Who controls the hardware?

But that is all water under the bridge. Google gave up on the secure element and switched to using a different NFC technology called “host-card emulation” for payments. There is no SE on the Nexus 5, latest in the Nexus line of flagship devices. With the controversial hardware gone, any remaining excuses to claim Google Wallet was somehow special also went out the door. Newly emboldened, the application was launched to all users on all carriers for the first time. “Google gets around wireless carriers” cried the headline on NFC World, with only a slight exaggeration of that gesture. (It probably didn’t hurt that that competitive pressure on ISIS had eased up, since they were finally ready for launch after multiple setbacks.) Installed-base and usage predictably jumped. Play Store reviews improved, the sharp spread in opinion between angry users denied access and happy ones raving about the technology narrowed. A few questioned whether payments would have been more secure with the SE. Otherwise quirks of Android hardware were quickly forgotten.

A good contrast here is with the TPM or Trusted Platform Module on PCs. Much like the secure element, TPM is a tamper-resistant special chip that is part of the motherboard on traditional desktops and laptops. TPMs first made their appearance with the ill-fated Windows Vista release. They were used to help protect user data as part of the Bitlocker disk-encryption scheme. Later Windows 7 expanded the use-cases, introducing virtual smart-cards to securely store generic credentials for authentication and encryption. The situation here is akin to Microsoft shipping Bitlocker, Dell choosing to include a TPM in their hardware and a consumer buying that model, only to be told by an ISP that customers using their broadband service are not allowed to enable Bitlocker disk encryption. Such an absurd scenario does not play out in PC market because everyone realizes that ISPs simply provide the pipes for delivering bits. Their control ends at the network port; an ISP has no say over what applications you can run.

In retrospect NFC payments were an unfortunate choice of first scenario to introduce secure elements. The contemporary notion of “payments” is laden with the expectation that one more middleman can always be squeezed into the proceed to take their cut of the transaction. It is hardly surprising that wireless carriers wanted a piece of that opportunity. Nevermind that Google itself never aspired to be one of those middleman vying for a few basis-points of the interchange. One imagines there would have been much less of a land-grab from carriers if the new hardware was instead tasked with obscure enterprise security scenarios such as protecting VPN access or hardening disk encryption (Unless backed by hardware, disk encryption on Android is largely security theater: it is based on predictable user-chosen PIN or short passphrase.)

Collateral damage

Hardware technology with significant potential for mobile security has been forced out of the market by intransigence of wireless carriers in promoting a particular vision of mobile payments. This is by no means the first or only time that wireless carriers have undermined security. Persistent failure to ship Android security updates is a better known, visible problem. But at least one can argue that is a sin of omission, of inaction. Integrating security updates from upstream Android code-base, verifying them against all the customizations small and large that OEMs/carrier made to differentiate themselves, takes time and effort. It is natural to favor the profitable path of selling new devices to subscribers over servicing existing ones already sold. But the case of hardware secure elements is a different type of failure. Carriers went out of their way to obstruct Google Wallet. Reasonable persons may disagree on whether that is a legitimate use of existing market power to tilt the playing field in favor of a competing solution. But one thing is clear: that strategy has all but eliminated a promising technology that holds significant potential for improving mobile security.

CP