Tags

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

(Reposted from my previous blog)

Near Field Communication has taken a step into the mainstream with Google testing its wallet service for Android phones. The way Google Wallet works, if I have this correct, is that people store their bank details and payment method within a ‘Secure Element’ on their mobile devices, and this is sent to the retailer through an NFC link while other data relating to the transaction are sent to Google’s servers over the Internet.

The payment process (which is bound to hold up queues if it takes off) is something like this:
1. Take out the smartphone
2. Unlock it
3. Run the Google Wallet application
4. Place the smartphone near the NFC reader and authorise the transaction

Unfortunately there’s hardly anything in the way of technical information on the Google Wallet site, and journalists are more concerned with the marketing side of it. Some relevant information can be found at the Nokia wiki, the Sun Java Developer Network and the NFC Forum.

NFC and Smart Card Emulation
There are three modes of communication for NFC-enabled devices, but the one we’re concerned with here is the Card Emulation mode, which basically allows people to store credentials like card details, payment methods, identifiers, etc. in something called the Secure Element, and allow the device to function in place of a smart card. Although the press reports incorrectly claim the Secure Element is isolated from the device’s operating system, there are several APIs that allow applications to read and write to it. Two of them I’ve come across are the Open NFC API and the Contactless Communications API. While it may be difficult for attackers to access the Secure Element directly, a badly developed application that already has access to it can be compromised.

Putting it all together, Card Emulation works just like existing chip-and-PIN, but the mobile device storing the credentials replaces the card. Users authenticate themselves to some application which has access to a memory location in the Secure Element, and this is all on the mobile device, which must be in very close proximity (within 20cm) to the reader to send this data.
In itself, this is reasonably safe, providing the application is well developed and has good security, and providing no sophisticated interception equipment is being used nearby. It’s likely the professionals at Black Hat and DefCon will come up with some exploits before long. Jimmy Shah at McAfee Security has mentioned a couple of data relay and cloning hacks with generic NFC systems.

The Google Wallet system is less secure for several reasons I’ll outline, but the main concern is another party concerned with data collection (Google Wallet Service) is brought into the transaction, which weakens security anyway. Information relating to the transaction is sent to Google’s servers from the Google Wallet application, which means another connection would be opened, and quite possibly exploited during the transaction. Extra security will also be needed to protect the information during transmission and storage.

In a CNET article by Elinor Mills, it’s claimed: ‘Your payment card numbers and transaction information are all encrypted and stored on a tamper-proof chip from NXP Semiconductor on the smartphone, in what Google has dubbed the Secure Element.’
This claim may well be disproved by professional and well-resourced hackers before long. Firstly, tamper-proof hardware doesn’t exist in real life. At best, hardware can only have a strong level of tamper-resistance. The second thing I’d criticise is the idea something’s automatically secure because it has encryption – there’s actually good encryption and crap encryption out there, and NXP’s own encryption has been proven weak in the past. In fact, Bruce Schneier himself claimed every secret algorithm he examined has been found weak.

RFID
NFC is built on RFID, with tags and readers having extra layers for software applications to communicate. I should point out that RFID was originally intended for stock control and tracking of tagged items. An RFID tag, which can easily be cloned, stores a number which usually refers to an entry in a database. They were never intended to be used for authentication, and this is where governments get it wrong with passports and ID card projects. RFID readers, like Bluetooth circuits, are also tacked onto the same old interface used for IR comms, and that has its own vulnerabilities.

Data Collection
The Google Wallet places the company as the middle-man between every transaction, thereby allowing it to gather information about what the holder purchases, buying habits, locations visited, approximate income, and average expenditure per month, number of persons in the household, age, etc. All this can be derived from a basic record of purchases, and used to build a fairly detailed profile.
In fact, the privacy statement says: ‘Upon association of your Google Wallet Application with your Google Account, Google will have access to information that you have stored in the Google Wallet Application or that has otherwise been downloaded to the Google Wallet Application by one or more partners and merchants where you have used your Wallet Application.’

Combine the above with Google’s ‘real name policy’, the invasive data collection, the fact governments and law enforcement agencies can access private cloud service accounts, and the trading of all this data between marketing firms – we have disasters waiting to happen. It’s a system with vulnerabilities and much potential for abuse. Thankfully, for all this talk of ‘consumers’ having a more ‘personalised experience’, people are becoming aware of what that means, and from the comments I’ve read it seems they’re hostile to the further invasion of privacy. Being reduced to a ‘consumer’ is hardly personalisation anyway.

PIN Protection
There is another possible method of breaking the security of Google Wallet I can think of, which could be done just after the owner makes a transaction. This attack involves the four-digit PIN that’s supposed to be a main method of protecting the application. I have manually bruteforced four-digit PINs in the past, and usually within the space of 20 minutes. There are techniques here for narrowing it down to 256 possibilities, some of them ruled out by Google Wallet preventing certain PINs being set. The particular attack I’m thinking of doesn’t require a card, and it can be done without attracting attention.
Another possible attack would involve malware that looked for 4-digit PINs, monitored the outgoing network (not NFC) traffic to Google Wallet servers, and send it to the attacker.