DecryptedTech

Tuesday29 November 2022

Google Wallet stores your PIN in readable binary form


Reading time is around minutes.

News_manstealingdataThere is an old saying; buy cheap and sell dear that came about in the Carnegie days and has been in use by corporations for so long that it is just the way they do things. What this means now is that corporations will always look for the quick and easy way to do things. This is not a big shocker; after all most companies will want to minimize costs and maximize their profits. Where this hurts the consumer is that many times minimizing costs ends up being translated to security or product quality. A perfect example would be Apple’s move to Foxconn. Yes they reduced their operating costs, but the product quality realistically has gone down. Another place where we see cuts are in security and network protections of user data. A good example of this can be found in Google Wallet.

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

Last modified on Thursday, 09 February 2012 10:36

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.