Google Wallet and Android NFC stack are frequently mentioned as one of the casualties from the Android FakeID vulnerability. This post looks at what an attacker can accomplish with forged NFC admin permissions.
“Those who do not understand UNIX are condemned to reinvent it, poorly” — attributed to Henry Spencer.
Spencer’s observation has a parallel for digital signature standards, which can be formulated as:
“Those who do not understand PKI, X509 and CMS are condemned to reinvent it, poorly.”
FakeID is not the first time that a serious implementation error was found in Android’s code signing mechanism. Unlike the earlier incarnation that involves a subtle mismatch between the contents of the ZIP archive making up an application versus what is covered by the signature, the new vulnerability affects a more specific code-path: signature-based permissions. This is one of the options for defining an Android permission, to be granted specifically to other applications that are signed with the exact same certificate as the one defining the permission.
For instance the original NFC administrator aka NFCEE_ADMIN permission in Android prior to ICS operated this way. Google Wallet was signed with the same key as the NFC stack on official builds of Android, obtaining this permission on installation. (Of course an OEM or carrier always has the option to recompile and sign the NFC stack using a different key in order to hamper Google from offering a mobile payment application on their devices.) Starting in ICS, this model was generalized to read out a list of acceptable signing certificates from an XML file which can not be modified by end users on non-rooted devices. The underlying vulnerability still applies to this version, because the same code-path is used by the NFC stack when verifying whether a caller requesting special NFC privileges is any one of the approved signers.
Meaning of NFC administrator privilege
What has been obscured in this discussion so far is what happens if a malicious app could attain NFC administrator privileges. What is the worst case scenario assuming Google Wallet is installed on the device? Can this attack result in fraudulent transactions or access to financial information? Short answer is no.
One important caveat: many of the risks discussed here assume the presence of an embedded secure element being used for NFC payments. While this was the original architecture for Google Wallet from 2011-2013, more recent iterations are built entirely on host-card emulation, leaving the SE unused regardless of hardware capabilities. In fact many flagship devices including the Nexus 5 do not even feature an SE any longer. Yet for the purposes of this discussion, we will roll-back the clock to 2011 and assume the worst case scenario: namely that eSE exists and has been provisioned with active payment applets.
There are three kinds of additional privileges granted by the NFCEE_ADMIN permission:
- Ability to control card-emulation state
- Ability to receive notifications
- Access to the secure element. Note that this specifically applies to the embedded secure element. On ISIS devices, NFC controller is connected to the UICC as secure element. Host communication to that hardware goes through RIL (Radio Interface Layer) as with all SIM access, not the NFC execution environment defined by NFC stack.
Let’s examine each of these in turn.
1. Card-emulation state
Android only defines two possible states for controlling NFC card-emulation status:
1. Off: Meaning the external NFC input is not delivered to the eSE
2. On when screen on: NFC communication to the eSE is tied to screen state.
(Not to be confused with controlling card-emulation route— that is fixed at boot time. It used to be always pointed at the embedded secure element on earlier versions, and later defaults to host-card emulation.)
#2 is the default setting when Google Wallet is installed and tap-to-pay is configured. In that sense, the device is already operating in the most “permissive” state and there is nothing malware can do to move the user into a weaker configuration. Of course malware can interfere with payments by keeping card emulation disabled but this is at best a low-severity denial of service. No access to financial data results from doing that.
Note that the underlying NFC controller hardware supports other options, including always-on as long as the phone is on and in the extreme case, powered-by-the-field where eSE can draw power from an external NFC reader even when the device itself is completely powered off. (In fact, there is no concept of “screen is on” at NFC controller level; synchronizing card-emulation to screen state is orchestrated manually by NFC stack in response to display events.) But there is no way of activating these options by making calls to the NFC extras interface, even when caller gains access to the API by subverting the signature permission.