Showing posts with label google. Show all posts
Showing posts with label google. Show all posts

Thursday, February 9, 2012

Security Vulnerability Found in Google Wallet

Joshua Rubin of zvelo recently explained his research in the security of Google Wallet. Rubin discovers that a lost or stolen Android phone with Google Wallet configured could be as bad as lost a credit card.
Google Wallet is currently the only public available NFC-based payment system. It's officially available in Samsung Nexus S 4G on Sprint network. NFC is using Secure Element (SE) to store/encrypt the sensitive data, such as credit card number. It's designed to resist hacking and protect stored data.
To access SE, Google Wallet requires a 4-digit PIN at the first time launching the application. By design, if the phone is stolen, Google Wallet can lock it up completely after a few failed PIN attempts.

viaForensics first came out with a report questioning the security of Google Wallet. Then zevelo researched more in this topic and indeed found the security flaw in the Google Wallet.
As we investigated the data stored in the per-app (sqlite3) database used by Google Wallet, we became intrigued by the contents of the “metadata” table that contained only 3 rows but a large “blob” of binary data in each. The name alone, “metadata,” just seemed like a poor attempt at “security by obscurity” which as we already know, “is no security at all.”

One row in this table has id ‘gmad_bytes_are_fun’ and this appears to be a sort of encrypted file system used for storing data via the SE. The contents of the binary data in this row likely includes the complete credit card information and certainly needs further vetting, but it was not this row that interested us.

Another row had an id of ‘deviceInfo’ and appeared to have much more non-null data. However, this binary data had to be parsed somehow to uncover its contents. After some more digging, we realized that this data was compiled using Google’s own “Protocol Buffers.” This is an open library for serializing data for messages passing between systems. In order to use this data, we had to define a “message format” in a “.proto” file (Protocol Buffer Basics: Java). With our custom “.proto” file in hand, we were able to uncover the contents of the binary data and were shocked at what we found. Unique User IDs (UUID), Google (GAIA) account information, Cloud to Device Messaging (C2DM, also known as “push notification”) account information, Google Wallet Setup status, “TSA” (this is probably related to “Trusted Services” not the “Transportation Security Administration”) status, SE status and most notably “Card Production Lifecycle” (CPLC) data and PIN information.

The CPLC data is a vital part of the communication with the SE. However, it was yet another binary blob that would have to be deciphered, or perhaps it just acts like a “key” to unlock the SE and has no decipherable data within.

The lynch-pin, however, was that within the PIN information section was a long integer “salt” and a SHA256 hex encoded string “hash”. Knowing that the PIN can only be a 4-digit numeric value, it dawned on us that a brute-force attack would only require calculating, at most, 10,000 SHA256 hashes. This is trivial even on a platform as limited as a smartphone. Proving this hypothesis took little time.

Google Wallet allows only five invalid PIN entry attempts before locking the user out. With this attack, the PIN can be revealed without even a single invalid attempt. This completely negates all of the security of this mobile phone payment system.

I am surprised to hear that Google Wallet is using sqlite db as the storage engine to save data, instead of their own db engine. Sqlite is a very good, light weight relational database, but just not strong enough to be as the base for secure database. Sqlite is open source database and all data is in one data file. It's both good and bad. Here's the link for the report from zevelo.

Thursday, January 26, 2012

Google Releases NFC-Based Wallet

We have heard NFC-based wallet for quite some time. Now reality is close to come true. Fast company reported a rumor that Google will official release its digit wallet based on its Android-powered smartphones. Similar like iPhone changes the way people use phone, NFC based digit wallet can  dramatically change the way making payment using their mobile phone. 

Google's idea goes beyond replacing a credit card in your wallet with a wireless system in your phone--tallying with everything we've predicted about NFC-enabled shopping. Wallet, Google hopes, and the accompanying Offers system is "mobile, local, personalized, serendipitous, and open." Giving an example of walking into a grocery store, Tilenius demonstrated that a Google Nexus S phone could pop up a grocery shopping list because it's detected where you are. When you'd collected the goods, you'd pay at the checkout merely by tapping your phone to the sensor, and the transaction happens instantly, along with loyalty point awards and so on.
The system supports multiple cards (by default Citibank to start with) but there's provision for other providers cards which are all securely stored along with PIN data, and there's also a Google pre-paid credit card which you can "top-up" by using other payments systems. Special offers are also targeted at you, based on your previous shopping history at the store--a trick which leverages Google's vast databases and expertise in targeted advertising--and ultimately Google thinks you'll put "everything" in its Wallet, including digital editions of your driving license and car keys. Google stressed this is a real system, not a proof of concept, with over 300,000 PayPass installations and retailers integrating the tech right now. (Jack Dorsey, are you listening?)
And then comes "Offers," a system to partner the Wallet and add in the extra functionality that makes it a real reinvention of shopping. Offers has been around for a few months and is, basically, Google's attempt to steal Groupon's--and maybe Facebook Deals'--business. While much of clients' interactivity with Groupon happens at home, on a PC with printouts for vouchers and so on, Offers is going to be more about being mobile and tapping into the rich data stream generated by your shopping habits--Tilenius noted Offers would be delivered as a daily email (very much like Groupon) but also through apps. And unlike Groupons coupons it all happens in a single move when you pay for the product you're saving cash on, via Wallet. Plus, as Google demonstrated onstage, there are novel new shopping ideas enabled by this system, like NFC-tagged posters which you'd tap your phone on to collect a coupon.
To appease security and privacy worries, Google's Nexus S phone has a hardware level secure encryption chip, and to prevent your card data from being scanned just when you're walking along (a very 21st Century version of pickpocketing) there's no transmission of your data until you're at a cash desk and have "unlocked" your Wallet app. How this translates to Google's plans to make Wallet "open" for other systems to interact with, we're not sure.

Here is more for the article.