You can read the papers to get all the details on this attack. Basically, they have been smart enough to use a salt before hashing the PIN value to avoid brute-force attacks. However, they haven’t been smart enough when they decided to store the salt just next to the hashed PIN value. Of course, with these two pieces of information, it takes at most 10,000 attempts to find the PIN (just check the video of the attack if you doubt that this is a very small number).
But hey, it’s just an attack/vulnerability. Maybe the first one, most likely not the last one. What surprises me most is that all these wallet programs insist on Common Criteria certifications of the Secure Elements, very complex certification programs for SE applications, and yet they leave behind this kind of basic vulberability in the mobile application, whose security does not seem to be formally evaluated by anyone. At least, the SIM/eSE security specialists should be able to sleep well for a while: they are unlikely to be the best target for real attackers, with such low-hanging fruit.
What really puzzled me from the zvelo guys is their analysis of what needs to be done. Their first step is correct: this PIN (which is used to open the wallet, not to validate a transaction) should be stored and verified in the Secure Element. Now, what surprises me more is their next statement:
Basically, by moving the PIN verification into the SE itself, this might constitute a “change of agency” responsible for keeping the PIN secure. The fear is that Google might no longer be responsible for the security of the PIN, but rather the banks themselves. If this is in fact the case, then the banks may need to follow their own policies and regulations regarding ATM PIN security which obviously, and rightly, receive a great deal of scrutiny.
Now, this doesn’t look good. First, about the ownership of the SE. I am not sure what the deal between Google and the phone vendors is, but I would say that the SE is owned either by Google or by the phone vendor. After all, they are the ones who control the SE’s master keys.
Even if we don’t consider that, Google would not store the PIN in somebody else’s application. I am sure that they have their own app in the SE, that they would use this app to manage their little PIN. This is very easy to do with Java Card, and I am sure that they can develop this addendum easily.
Finally, as mentioned above, this PIN is not an ATM PIN, because it is not linked to a specific transaction. When you enter the PIN, it opens the wallet, but it does not authorize a transaction. It is the digital equivalent to putting a four-digit combination lock on your wallet (which is exactly what Google is claiming).
Nevertheless, the story remains interesting, and it reminds us of the complex ecosystem behind NFC payments. For instance, did the banks consider the Google PIN in their risk analysis of the Google wallet? Well, if they did, the Google PIN is now a bit weaker. It is not broken, though: a combination of malware and physical access to the phone is still required to make a fraudulent transaction.
To conclude on a positive note, the end of the zvelo article is a good list of recommendations. If you keep your phone clean and locked, the bad guys will have to find a better vulnerability.