Google Wallet Hack – a possible lead to EMV in the US

Last week, we’ve seen in the breaking news that the Google Wallet was hacked. The PIN that is required to unlock the wallet is displayed within seconds by using a separate application, Wallet Cracked.

The most brief explanation of the hack is that the encrypted file that the PIN is stored on the file system of the device is comprimised. It was identified that Google uses the most common database engine for mobile applications -the SQLite for storing the PIN. By any security means, this simply is not acceptable. But of course, there is a reason for that. The PIN must be authenticated offline so somehow it must be stored on the device. The options are not that much; either on the file system of the device or on the Secure Element. Secure Element can either be on the handset (embedded) or can be the SIM. If you go for the SIM, it means that the MNO holds the power. If embedded on the device, it is up to the configuration, whoever is subsidizing the phone will have the master keys to access it.

It seems Google went for the most easy way; the file system of the handset. But in the mobile world, accessing the file system of the handset is a piece of cake for anyone who wants to do it. Both Android and iOS devices come with the file systems locked, but jailbreaking (for iOS) or rooting (for Android) enables the user to access the file system without any limitations. That simply means you can browse, view, edit any file you like -including the file that stores the PIN for Google Wallet.

Well, I can say that this would never happen in the EMV world. Here in Europe -or Turkey, to be precise- the wallet itself is not the item to protect. The wallet that the MNO provides is mainly an interface to the mobile payment application running on the SIM. You need to authenticate yourself to the mobile payment application, but this happens within the SIM and there is no way to access it from the outside. The SIM is connected to the handset run time via the Single Wire Protocol (SWP) and this is not something developers can play with. Each mobile payment application has a PIN Try Counter and you can not verify the PIN without using the VERIFY PIN command over this interface. After 3 cocurrent unsuccessful PIN attempts, PIN is locked. There is no way to access the memory of the SIM, yet the mobile payment application is even not accessible by the MNO itself. It is accessed by the bank over a secure channel through a TSM. The role of the MNO is mainly the enabler of the payment application. Customer processes (installation, uninstallation, PIN unlock, etc) for the payment application is handled by the bank over the TSM, over the air.

Google immediately fixed the leak, but I think this incident will lead people to go deeper into the security of a payment application on a mobile device. The file system of the handset is not secure and you can not/must not store any sensitive data there. You need to do it on the secure element and the most mature payment solution to run on the secure element is the EMV path.

Both Visa and MasterCard released their plans for migrating the US to EMV and I hope this unfortunate event contributes to these plans -at least on the mobile platform.

{ Comments are closed! }