, , , , , , , , , , , , , , , , ,

As it turned out, wallet applications on mobile devices are even less secure than I originally thought. The NFC Card Emulation mode, which Google Wallet is based on, works much like an existing chip-and-PIN system, with the card data being stored in a Secure Element (or so we believed) which replaces a card’s chip. The owner makes a purchase by placing the device on a reader and entering the PIN to authorise whatever transaction.

When we’re dealing with bank accounts and huge sums of money, should we entrust security to an ‘app’ and several third-parties intent on selling whatever information about our finances? Would that make the user liable for whatever’s stolen from their accounts?
Ideally the level of complexity should be minimised, and the data encrypted during both storage and communication using an open cryptographic system known to be strong. It’s taken years for banks to get this mostly right, but they still rely on customers not disclosing certain information.

A smartphone should be treated in the same way as a personal computer. Depending on how the security is configured for the specific device, Google Wallet relies on an ‘app’ running on a potentially untrusted device that’s routinely exposed to multiple public networks, and possibly infected with malware (CarrierIQ being an example) before it’s even purchased. A rootkit that broadcasts information unencrypted can undermine practically all security on a device. In addition, a smartphone is far more easily mislaid or stolen. This system will obviously have more complexity and therefore more exploits than the conventonal chip-and-PIN method.

Compartentalisation is Important
Having several bank/credit cards with different PINs does add an element of compartmentalisation. If one card is compromised, the rest are okay. It would also be impractical for an attacker to obtain and memorise the PINs for several cards by threatening the owner, and even then an ATM or card reader is required to verify the PIN’s correct. Alternatively cards can be skimmed, but people have become more aware of it.

On the other hand, if the card details are stored on a single device under a single four-digit PIN, as is the case with Google Wallet, this protection is lost. All the data can be compromised in a single incident, especially where attackers can threaten the owner and quickly verify whether the correct PIN was revealed.

The Wallet’s Application Database
Another possibility is someone with physical access rooting the device and browsing its filesystem, as viaForensics did. They found the following data stored unencrypted in the application’s database:
* Payment method
* Cardholder’s name
* Last four digits of the card number
* Owner’s email address
* Location of last purchase
* Card expiry date
* Analytics data

At the very least, as viaForensics noted, this information would facilitate social engineering and other indirect attacks. It’s also possible to derive most the digits of a card number if the card type and issuer are known. Masking all but the last four digits provides little security here.


On the surface it sounds secure enough – the application requires a four-digit PIN, and the data is wiped after six unsuccessful attempts, but zveloLABS discovered the PIN’s hash value is also stored in the filesystem, and not the Secure Element. If this can be acquired, it can be cracked in less than a second without the application registering an attempt. The problem is a strong password is inconvenient and harder to memorise, and Google would have problems marketing the system.