Google unveiled details of Google Wallet this week. Google Wallet is an ambitious mobile payment plan designed to let your Android smartphone be your wallet, but you should consider very carefully just how secure your credit card data will be in Google Wallet.
Don’t get me wrong, Google understands the inherent security risks of storing credit card information, and it has gone to great lengths to ensure sensitive data is protected in every way possible. But, at the end of the security chain is an “authorized” Android app, and that is the Achilles heel of Google Wallet security.
Consider the whole system, and the steps of the process. On the processing end, you really have nothing to worry about. The NFC technology used by Google is not any different than the wireless signals used in many credit and debit cards, or gas station swipe-to-pay systems now.
I can already tap properly-equipped payment terminals–like those at most McDonald’s–to make payments with my Chase Bank debit card, so doing the same thing with my smartphone wouldn’t be any less secure per se. On the back end, the processing and storage of my credit card information is still being protected by the PCI-DSS (payment card industry data security standards) rules that govern such things.
That credit card data is also stored on the Android smartphone. But, Android smartphones equipped for NFC mobile payments have a separate chip to store the sensitive credit card data. The credit card information is encrypted and the chip itself is tamper proof. Seems secure enough, even if a thief has physical possession of the smartphone.
Then comes the weak link–the Android app. Here too, Google has done its part and developed a system that relies on a PIN from the user to open the app or initiate a transaction using Google Wallet. That alone represents one weak point in the Google Wallet security. Have you seen the kinds of passwords people use because they can’t be bothered to remember something more complex? How many Google Wallet PINs will end up being “1111”, or “1234”, or something equally trivial to guess?
But, even with a strong PIN in place, if there is one Android app that can access the encrypted credit card data and process payments, then it is possible for malicious developers to create other apps, or spoof the Google Wallet app somehow to access that sensitive data as well.
Jimmy Shah, mobile security researcher at McAfee Labs, points out in a blog post that the secure chip that stores the credit card information uses assymetric encryption for authentication–implying that the Google Wallet app contains the key necessary to authenticate and access the data, and that attackers can hack or reverse-engineer the Wallet app to extract that key.
Shah says, “The next step would be to create a malicious application that emulates the official Wallet app to fool the “secure element” chip into giving up your credentials. From here, the attacker can collect account information for sale or for attempts at cloning the data to new NFC cards.”
On an iPhone this might be less of a concern because of the walled garden approach and the fact that iPhone apps have to get past the Apple gatekeepers first. But, with the “open” environment of Android, and all of the various unofficial Android app marketplaces out there, distributing a malicious app capable of cracking Google Wallet might not be too difficult.
I am not trying to suggest that Google Wallet is completely insecure, or scare you away from using it. I am still looking forward to the day when mobile payments using a smartphone becomes a mainstream method of doing business. But, I do think you need to be aware of the potential security holes in the system so you can exercise an appropriate level of caution when using Google Wallet.
Update: I spoke with Google about some of the issues I mention in this article related to the security of Google Wallet. I want to clarify some of these points here so I am not spreading any misinformation about these issues.
First, Google claims that no Android application–including Google Wallet itself–has access to the credit card credentials stored in the Secure Element. Nor can any Android application read or write credit card credentials from the Secure Element. The key to access the Secure Element is not stored on the phone’s memory. The Trusted Service Manager (First Data) has the key necessary to access the Secure Element to read and write the secure credit card credentials from the Secure Element directly.
Second, the NFC transceiver is only enabled when the phones screen is illuminated. When the screen is powered off, the NFC transceiver is powered down, so it is non-responsive to any reader in its proximity. That means, ostensibly, that would-be attackers will not be able to try and initiate transactions from rogue NFC payment terminals on passersby. Once the screen is powered on, the NFC transceiver can respond to a reader. If it is a payment reader, the phone will prompt the user to enter their PIN. Only once the correct PIN is entered will the Secure Element authorize any payment credentials to be released to the reader. Secure credentials are directly passed from the Secure Element to the reader using Mastercard’s PayPass protocol (the credentials are never seen by the Wallet application or by the Android Operating System).
Third, Google has considered the tendency for users to create weak passwords and has developed logic in the Google Wallet app to detect obviously weak passwords and reject them. So, users will not be able to use combinations such as “1111” or “1234” as I had suggested.