The idea of paying for items using your cell phone is not new by any means. Nokia had presented a way of using their phones to pay for items in vending machines quite a while ago and other phone makers had used similar systems. Now, there is a big push to use Near Field Communication (NFC) for making payments. Again these have been around for a while with payment systems like Mobil’s Speed Pass and MasterCard’s PayPass. All you need is an RFID device (Radio Frequency Identifier) that is coded to with your account information and you are good to go. However, these systems have zero security. If you lose the credit card or your pay token almost anyone can use them.
This is where software programs like Google Wallet are supposed to come in. They will still use the NFC system and an RFID device (built into the Phone) but will also add user interaction as an additional step for security. The problem is that lazy coding in an attempt to keep development AND hardware costs down have resulted in another insecure application. According to Joshua Rubin at zveloBLOG Google put everything you need in simple binary form inside the sqlite3 database used by Google wallet.
By creating a custom .proto file (used to read the binary data) they were able to skim Unique User IDs (UUID), Google account information (GAIA), Push notification information, Wallet setup status, Trusted Services Status, SE Status, Card Protection Lifecycle and best of all the PIN number needed to access your Google Wallet. To add insult to injury the PIN included the Salt and Hash information (just to make the failure complete).
All of this was found in a table called DeviceInfo. Now, to me it seems that the lack of true hardware encryption (AES256 or similar). Now Google can move the PIN into the CE but that could possibly mean that the card issuer (the bank) would have to approve the security of the PIN which could take considerably longer to gain approval on. It may also cost Google some extra money if the banks want to impose that one them (and many banks will).
Fortunately there are only two phones that have the NFC system and Google wallet running right now and those are the Google Nexus S on Sprint’s network and the Galaxy Nexus. Another solace is that this attack is unlikely to be run remotely as it requires the phone to be rooted to work. Now, that is not to say there are not other vulnerabilities that could allow a piece of malware to access the Google Wallet database it is just less likely. The down side is that this exploit would be easy to put into place if the phone was stolen.
There are the usual steps to protect yourself from this; update your phone, enable a lock screen with a password or pin, disable USB Debugging, enable full disk encryption, and do not root the phone. Personally we feel that these moves are being rushed without proper concern for security and data protection. This is in an effort to be first to market all in the interest of making money at the expense of the consumer.
Discuss this in our Forum