It is only a matter of time until a physical wallet will be like carrying around a watch … these days, all you need to do in order to know the time is to glance at your smartphone. Similarly, all you’ll need to do to pay the bill in your local grocery store is pull out your smartphone.
Google has been working to make this vision a reality – the Google wallet App was invented exactly to capture this future market. Yet, with the comfort that involves easy payments and no need to carry real money, security risks rise. If our smartphone is stolen, can the thief use it as a wallet? Can someone in a crowded subway station scan our smartphone and get our credit card details? Is the App protected by government legislation? Those questions and more were brought to the attention of Google engineers when developing this innovative App. This blog post will follow the vulnerabilities of the Google wallet, and what security measures were taken to overcome them.
The first version of the Google Wallet App was released on September 2011. The user uploads to the App their full credit card details. The details back then were stored in a Secure Element (SE). SE is a new architecture design introduced into the mobile world in order to achieve better securities over PC’s The SE is separate from the phone’s main operating system and hardware; this enables encrypted protocols to enforce access control. Only authorized programs like Google Wallet can access the SE to initiate a transaction. The SE is protected at the hardware level from snooping or tampering”.
In order to use the App, the customer simply opens the phone, starts the App – enters a predefined 4-digit pin number and places the phone on a Near Field Communication (NFC) reader, the transaction is preformed, and details about the event are stored. Security wise, the 4-digit pin is protected by hash (one-way encryption) algorithm. If the wrong pin is entered 5 times the application locks. The NFC is a set of standard protocols developed for smartphones to establish radio communications in close proximity, no more than a few centimeters from each other. The protocol is based on RFID standards. The communication through Google wallet is only enabled if the App is open and the 4-digit pin was entered by the user.
Man in the middle – Google Wallet was well protected against this well-known attack and the access was continuously denied.
Analyze data stored on the device – This attack was more successful and the following details were extracted: Credit card expiration date, Card holders name, Card type, Last 4 digits of card, Current balance, Available to spend, statement balance and payment due date. Moreover, back then they were able to retrieve the data even after Google Wallet reset option was chosen by the user – meaning that if you sell your smartphone and wish to remove all your credit card details they can still be retrieved. It is important to note that most of the data was accessible only after root privileges were created in the android operating system – Google clearly states the Wallet App is not supported in such a case.
Joshua Rubin, a researcher at Zvelo took it one step forward and proved that a 4-digit pin code which only contains 10,000 unique options can be easily hacked using brute force, leaving a stolen smartphone totally vulnerable to money theft.
Google took this threats and vulnerabilities very seriously and evolved the App in many ways. First, it immediately fixed the basic problems such as deleting the credit data upon App reset and getting rid of the name, expiration date of the card and last 4 digits which were all accessible in the past. Furthermore, Google created a “remote control” which enables any user to easily disable the App on his/her phone remotely from any other device.
The most impressive security measurement recently (July 2012) introduced is eliminating the need to store any credit card data anymore on the device! “The credit and debit cards you store in Google Wallet are safely encrypted on secure servers in a secure location. When you pay in-store, Google actually pays the merchant, and then processes the transaction with your selected credit or debit card. So neither the merchant nor the Android operating system ever gets your real payment card information” This solves all the data vulnerability issues, yet the pin retrieval attack is still a threat on phone with root access. Furthermore Joshua Rubin proved that the pin can be breached also by enabling root privileges retroactively. The only current known way to protect from this attack is by moving the PIN verification details into the SE component. Yet this raises several ownership issues as Google wishes that if the PIN is stored in the SE component the banks will take full responsibility over the PIN – just like an ATM PIN.
Our recommendations for the regular smartphone user are first to make sure your phone has a screen locking enabled. Second, you should always keep your applications updated – most of the software updates are concerned with security problems. If you are not a developer there is no reason to root your phone or enable USB debugging, it only makes it much more vulnerable. Also be extremely careful from whom you buy a 2nd hand phone, software which you will never be aware off can easily monitor all your actions and send them to the web.
To summarize Google is well aware that this application is and will probably continue to be a high priority target for cyber-theft. Google is continuously improving the security around this App using the best known practices and inventing new techniques. Hopefully we will all benefit from this improved comfort and security in the near future.
Tag Cloud#Stuxnet android Apple Architecture Cloud Cloud computing cloud security Coursera cyber security cybersecurity database encryption DCS education edX EMR Security facebook Galaxy S III hack Hacking Harvard Healthcare Cyber-Security Healthcare Information HIPAA ICS identity theft malware Mobile MOOC MOOCs Near-Field Communication network NFC password privacy protection Samsung SCADA security spying spyware SQL Injection Udacity virus wep wireless network