Google's PIN Pains: Will Citi Make This Wallet Safer?

Google Wallet's security problems that surfaced last week—two different ways for a thief who has stolen a phone to get access to payment cards in the digital wallet—prompted Google to block new Google Wallet provisioning for several days until the company pushed out a fix. But the vulnerabilities also highlighted a major pain point: Shifting payments from plastic card to smartphone isn't just about technology, it's also about getting partners to cooperate—in this case, card issuer Citi. The big problem: The most logical and secure technology fix—moving PINs to secure hardware—is something Citi seems unwilling to do. Here's what happened: On February 8, security firm Zvelo reported a way that a smartphone thief could use the phone's own hardware to calculate all possible encrypted PINs and determine which one unlocks Google Wallet. Zvelo had already reported the vulnerability to Google, which according to Zveloconcluded that it needed to move PIN verification to the NFC Secure Element, where payment card numbers are stored—but that would require approval from the issuing bank, in this case Citi. That hasn't happened yet. (Google would neither confirm nor deny Zvelo's account.) That was Wednesday. On February 9, a blog called The Smartphone Champreported an easier way for a thief to get through Google Wallet's PIN security: A thief could simply clear the data from the Google Wallet app, which would then ask the thief to name his own new PIN. This would let the thief use the phone's existing Google Wallet prepaid card but not any payment cards stored in the Secure Element. A reminder: The Secure Element's placement is an industry political battle. If it's in the phone, Google controls the system; if it's in the SIM, the carrier controls it; if it's in an SD card, the bank controls it. So, on February 10, Google stopped provisioning new prepaid cards, which effectively blocked the name-your-own-PIN attack. The company pushed a fix out to Android phones and resumed provisioning of prepaid cards on Tuesday (Feb. 14). That fix resolved the name-your-own-PIN hole but didn't close the Zvelo hole, which Google is reportedly still trying to get Citi to help out with. If all this sounds far too complicated compared to the contactless cards that Google Wallet is supposed to replace—well, yes, it is. With those plastic cards, the card number and PIN and the card's software are all stored inside the card's Secure Element. Only one player is involved in that decision: the issuing bank. And users would have to work mighty hard to reduce the level of security. But with Google Wallet, there's a phone maker, an issuing bank, a mobile operator—and Google.But with Google Wallet, there's a phone maker, an issuing bank, a mobile operator and Google, all of which have a say in how the phone works (including any mobile payment scheme it supports). Users get to chime in, too: For convenience, users can set the Google Wallet PIN to last for as long as 30 minutesbefore it has to be keyed in again. That's a long way from the security level of that plastic contactless PIN card. It's because the Google Wallet PIN isn't validated inside the phone's Secure Element that attacks like the ones published last week are possible. The easiest way to make Google Wallet almost as secure as a contactless card is to move PIN validation inside the Secure Element. But that requires the cooperation of the issuing bank, as the Zvelo researchers pointed out. Although Google won't confirm Zvelo's description of the situation, there's no real reason to doubt it: "The fear is that Google might no longer be responsible for the security of the PIN, but rather the banks themselves. If this is in fact the case, then the banks may need to follow their own policies and regulations regarding ATM PIN security which obviously, and rightly, receive a great deal of scrutiny." Zvelo's post continues: "At present, the decision is in the banks' hands. They may actually choose to accept the risk imposed by this vulnerability rather than incur the financial and administrative overhead of allowing Google to release a proper fix” and thereby potentially put the banks on the hook for the PIN security. "The banks" is a generous way of putting it. Right now, Citi is the only bank whose payment cards can be installed in Google Wallet. And it's presumably Citi that is preventing Google from moving PIN verification to inside the Secure Element, so the phone version would be much closer to the plastic version in its security approach. (In fairness, Google may be negotiating with other issuing banks, just as it recently started allowing NFC-equipped Android phones from AT&T to install Google Wallet.) Naturally, it's not just Citi's apparent reticence that would be a problem if the PIN goes into the phone's Secure Element. That would also make it harder for Google Wallet to control other payment card numbers—if, say, the phone also contains a SIM with an additional Secure Element, and maybe an SD card with yet another Secure Element. How would that work?How would that work? Would each card number get its own PIN (the way physical cards do)? Would Google Wallet have to keep track of how long each PIN has before it times out? It's beginning to sound like Google will have to negotiate with multiple issuing banks, multiple card brands and multiple mobile carriers to make this work—and it's already having trouble getting onebank to get with the program. Where does all this leave retail chains who have signed up for Google Wallet—or, for that matter, any retailer who can accept contactless cards (since Google Wallet is supposed to behave like plastic for them, as well)? That's unclear, too. Consider: When a customer walks up to a POS and waves a Google Wallet phone, it may not be necessary for the customer to key in a PIN at the POS, even if it's for a large purchase. That phone could have been stolen and the PIN cracked. Or it might have just been stolen minutes before, with the thief acting quickly to make a big fraudulent purchase before the PIN timeout expires. Does the retailer have card-fraud liability, because there was no physical authentication at the POS? Even Google doesn't seem to be sure. If retailers arein the clear, who's liable? Is it the issuing bank that wouldn't allow the PIN to be stored in the Secure Element? Is it the card processor that agreed to accept what the phone says instead of a number punched into a physical PIN pad? Is it Google, which decided to let PINs last for up to 30 minutes? Or will customers finally fall off the zero-liability turnip truck and have to pay for their own lax security habits? That last one seems unlikely. According to a Google spokesperson, "Google is responsible for fraudulent losses not covered by Money Network [the processor], the consumer's credit card company or the consumer's financial institution that were a result of a security flaw in the application. The consumer's liability is defined in the terms and conditions of the underlying payment account." That still doesn't confirm that retailers are off the hook; just because a card brand or issuing bank nominally covers a fraud loss, that doesn't mean card-brand fines won't happen to siphon funds out of a retailer's merchant account. The good news in all this confusion is that the growing pains of Google Wallet will probably help all of Google's competitors avoid the same problems. The less appealing news: Mobile payments clearly have a lot of growing to do.