FakeID, Android NFC stack and Google Wallet (part III)

[continued from part II]

3. Secure element access

This is probably the most interesting scenario in mind when NFC payments are mentioned as a potential casualty of the Android FakeID vulnerability:

“This can result in a wide spectrum of consequences. For example, the vulnerability can be used by malware to escape the normal application sandbox and take one or more malicious actions: […] gain access to NFC financial and payment data by impersonating Google Wallet; […]”

Before exploring this particular threat vector, let’s reiterate that all Google Wallet instances have been using host-card emulation for NFC payments since Q4 2013.  That includes both new installations and earlier ones migrated from the secure element architecture. With the SE completely out of the picture, the following discussion is largely hypothetical. Still for the sake of this exercise, we will consider a concrete version of Google Wallet that leveraged the secure element from two-years back, circa August 2012. Could a malicious Android app access any financial information from that version using FakeID?

Interface detection, revisited

First observation is that the secure element has 2 interfaces to the outside world: the “contact” (aka wired) interface attached to the host Android operating system and the “contactless” route that is directly attached to the NFC antenna. All communication from host applications arrives via the first path, while external NFC readers communicate over the second one. Relevant to the current problem, applications running in SE can distinguish between these cases and behave differently. Informally this is known as interface detection or interface discrimination. It is one of the corner-stones of the security model against remote-relay attacks.

Payments happen over NFC only

Google Wallet applets are configured to only execute payments over the NFC interface. Barring implementation bugs in the applets’ use of interface detection, it is not possible for an Android application to simulate an external NFC reader to initiate a fraudulent transaction. This holds true even if malware attains root privileges, by-passes NFC stack and interfaces directly with raw NFC hardware. Incidentally FakeID vulnerability does not permit that level of access; it only enables going through the legitimate NFC stack to exchange traffic with SE.

Information disclosure

While executing a payment or reading out track-data containing credit card number, expiration etc. will not work, an attacker can still attempt to interact with SE to get information. As a starting point, it can survey SE contents by trying to select applets using their well-known application IDs or AID. (It is not possible directly to enumerate installed applets. Doing that requires authenticating to the SE with unique card-manager keys.)  Each flavor of EMV payments for Visa, MasterCard, American Express and Discover have unique AIDs that can be used to finger-print whether a payment instrument of that brand exists. In the case of Google Wallet, only MasterCard is supported. The ability to use other payment networks is achieved via cloud-based indirection; the SE only contains a single “virtual” MasterCard, so there is no concept of backing instruments at that level. As such the only information gleamed will be whether the device is set-up for tap & pay at all. Depending on the SE model, there is also an optional controller applet designed to provide additional constraints on the behavior of the payment applet, and its existence can be used to distinguish between versions of Google Wallet.

After locating applets, malware could try interacting with the applet to gain additional information. But there is very little interesting data to retrieve over contact interface.** There is a “log” of recent transactions but this log only contains success/failure state. No information about amount paid, merchant let alone line-level item data is stored. (None of that information was even sent to SE in the original PayPass mag-stripe profile. While  the mobile variant MMPP added support for terminal to relay amount/currency-code, that field is not reliable since it is not authenticated by the CVC3.) In earliest iterations of Wallet, two different types of MasterCard were supported and the controller applet kept track of the currently active card. In a situation with multiple cards present, malware can observe which card is selected. More interestingly it can modify the selection and cause the next transaction to be charged to a different card– still belonging to the current user– than the one originally picked.

Active attacks

The ability to change actively selected card is not particularly useful, but it points in the direction of exploring other ways that SE access can be leveraged to tamper with the state of the payment applications or for that matter SE hardware itself. The final post in this series will look at denial-of-service risks as well as more subtle substitution-attacks around replacing the user wallet with one controlled by the adversary.



** Over NFC one can read out the full credit-card number– that is how the mag-stripe profile of EMV payments work. But that capability is only available to external NFC readers and not local malware, because of interface detection in SE applets.

2 thoughts on “FakeID, Android NFC stack and Google Wallet (part III)

  1. On UICC based SE it is possible to retrieve the list of installed applets by means of the CRS applet. Also the transaction log includes the ammount of the transactions.

    Finally, it is theoretically possible to capture the passcode / mPin intruduced by the user if the Wallet application has been modified and signed with FakeID. Once the PIN is know the app can accept payments without the user knowledge. For example with a subtle POS aproximation to the phone. Of course there are still some applets and/or phone that don’t allow paymenys with screen off.

    • Hello Miguel.

      There is nothing unique to UICC about “contactless registry”– it is a Global Platform 2.2 feature that embedded SE can have in principle. AFAIK none of the NXP hardware supported it, so the applet enumeration you are suggesting would not have worked. (Oberthur eSE in Nexus 4 may have CRS support.)

      The attack you are describing is neither a remote attack, nor is it automated. The PIN capture relies on social-engineering user to either PIN into a fake PIN collection dialog. (FakeID does not allow intercepting traffic from other apps, only sending your own traffic to SE)

      More importantly “subtle POS approximation” means the attacker needs to have physical proximity to user for NFC. But if you grant an attacker within NFC range, they have many more options: they can also bump the user with an NFC reader just after completing a purchase, before PIN has timed out. Better yet, they can snatch the device and yank the battery, leaving the SE with PIN state permanently stuck on for future transactions.

      None of these are remote attacks where someone can make payments just by getting user to install a FakeID-signed application.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s