[continued from part I]
Next up in the discussion what attackers can achieve by getting NFC admin privilege with FakeID vulnerability, we turn to information disclosure from Android notifications. Certain notifications are only delivered to these privileged applications, as defined in NfcExecutionEnvironment and NfcAdapterExtras classes:
- AID selected. Generated when an external NFC reader activates a particular application on the secure element, by issuing a SELECT command. The full application ID or AID for short is included in the notification.
- APDU received. Note that while the source-code defines an extra parameter for delivering the APDU contents, that payload is always empty. In general NFC controller does not stash aside all incoming APDUs addressed to the secure element and deliver another copy to the host-operating system. This would amount to spying on traffic directed at the SE. (That said the host could always switch the controller into host-card emulation mode and receive the traffic directly but then SE will not be receiving that traffic over NFC itself.) Only exception is the SELECT command as noted earlier, where AID from the command payload is surfaced to Android apps. This would have been useful if there were different applets co-existing on eSE with different use-cases (payments, physical access, identity…) each of them with an associated Android app that may need to take action when that specific applet has been invoked.
- EMV card removed. This is not generated by the NFC controller in Android.
- Mifare access detected. Applicable when SE has Mifare emulation enabled to also emulate a Mifare Classic tag in addition to ISO7816-style card. Early incarnations of Google Wallet on NXP PN65N/O used this feature for storing coupons. Intended use-case was redeeming a coupon and making a payment in one tap transaction. Later offers were moved out of Mifare sectors into ordinary Android land. Future iterations of the NFC hardware– specifically the Oberthur SE coupled to the Broadcom controller– had Mifare emulation disabled, even when the underlying hardware supports it.
- RF field on/off. These notifications indicate when the phone comes into the presence of an NFC field or is removed out of the field. This is useful to gauge the beginning and end of a transaction. Since external NFC readers communicate directly with the eSE without the bits flowing through Android itself, there is no other way of reliably identifying those points. (Polling the SE over contact interface is not a good solution, because doing so disables card-emulation and possibly interrupt a transaction in progress.) For example Google Wallet acquires a wake-lock when the NFC field is initially detected, to prevent the screen from going dark in the middle of a transaction.
An application with NFC admin privileges could receive all of these notifications, subject to the caveats noted above. In principle this would allow an application to infer when payments happen. For example the presence of an RF field alone is strong indication, since the only application present on most Android SE are payment applications. But there is even more unambiguous signal returned by the AID-selected notification: PayPass and PPSE applets invoked during the NFC payment transaction have unique AIDs that are easily recognized.
In short receiving these notifications discloses information about when a user conducts a payment transaction and which type of card is used based on the AID chosen by the terminal. (In the case of Google Wallet, it is always a MasterCard so there is no new information revealed.) But it reveals no information about the contents of the transaction, such as the merchant or amount. In fact it does not even allow differentiating between successful and failed transactions, because the traffic after the initial SELECT is not visible.
Remainder of this series will review risks associated with rogue Android applications accessing the embedded secure element via NFC extras APIs.