Part IV in this series sketched how it is possible to build a mobile wallet using NFC that can protect its secret keys even against an adversary executing code with Android root privileges. But there is one subtlety not explored in that discussion: keeping an attacker from getting hold of cryptographic keys is not the same as preventing unauthorized spending. The logical implications holds in one direction. If payments are authorized based on possession of cryptographic secrets– as is the case with EMV chip & PIN suite of protocols– being able to extract the key from the mobile device is game-over. But while key-recovery is sufficient for the hypothetical attacker to go around printing money compliments of another user, it is not necessary.

Remote relay attacks

Consider a less ambitious attack that relies on merely interacting with the secure element, to simulate a payment operation. Legitimate transactions take place by having a point-of-sale terminal send commands to the secure element over NFC. What if malware resident on the mobile device emulated that behavior but then relayed the responses from SE to another phone controlled by the attacker? More specifically:

• Attacker walks up to the cash-register and begins to pay for a purchase using NFC using his own Android phone.
• But when the point-of-sale terminal sends a command to the attacker phone, these are not routed to the secure element. Instead they are delivered to a special application running on the phone via host-card emulation. (It used to be that rooted devices running Cyanogenmod were required for this; starting with Kitkat it can be implemented on stock Android.)
• This special application receives the command from the merchant terminal, then forwards it over the Internet to malware running on the victim’s device
• That malware uses its root privileges to deliver the command to the secure element– necessary since Android only allows whitelisted applications to interface with SE.
• When SE responds to the command, the response is likewise ferried over the same network connection back to the attacker, who promptly forwards it over NFC back to the point-of-sale terminal.

In effect the POS at the store is communicating with the victim phone, although these communications are taking a rather circuitous route through the Internet instead of simply traversing a short distance as usual with NFC.

Relay attack visualized

Implications for security model

What has the attacker achieved after all this effort? If payments implemented in hardware secure element were still susceptible to attacks from local malware in this fashion, it would violate our earlier assumption that the Android operating system does not have to be trusted. With remote relay attacks, Android malware could still conduct unauthorized payments by channeling SE communications to a remote attacker, allowing them to make purchases without physical possession of the targeted device. That would also reduce one of the main advantages of SE-based implementation over HCE. Clearly an HCE solution implemented in pure software has no defense against root-level malware; secret keys can be permanently extracted out of application memory. In that sense HCE is an easier target. You only need to run the exploit once to extract keys; it is not necessary to maintain persistence on the victim device to continue making fraudulent payments. But relay-attack implies that even when cryptographic keys are safely tucked away in a dedicated chip, they can be exploited remotely as long as the phone itself is reachable over the network.

Are such attacks feasible? At first two practical limitations jump out, both related to network connectivity in real-time. (“Real-time” is the operative phrase. EMV protocols involve challenge/response interaction with the terminal. It is not possible to collect and store all possible responses from the SE ahead of time before starting a new transaction.) That presents the first obstacle for successful exploitation: the victim device may not be reachable at all. If the legitimate user turns off their phone or wanders outside the coverage area, it is not possible to relay commands in real-time this way. Likewise the attacker also needs connectivity for their own device, although that part is easier to control by carefully choosing the retail location where the scam will carried out. Second problem is around the quality of the connection measured in bandwidth and latency. Bandwidth turns out not to be a problem since the amount of data exchanged is on the order of hundreds of bytes. Latency is a bigger concern. There are timeouts at different levels of the protocol stack, from the raw NFC exchange– which also has an option to request an extension to buy more time– to application logic in the NFC reader. For example MasterCard recommends a limit of around 200 milliseconds for completing the entire tap & pay transaction, and that includes multiple command/response round-trips. (Granted some of the expected responses are predictable and do not require relaying the command all the way to the remote SE to find out the required answer.) But suppose the stars line up and our enterprising attacker does indeed have access to a high-bandwidth, low-latency connection to the victim device controlled by his malware? Or perhaps the point-of-sale terminal is very lenient and does not mind waiting longer than expected to complete the transaction?

It turns out there is a more fundamental defense available for preventing relay attacks against secure element applications: interface detection. That will be the topic of the final post in this series.

[continue to part VI]

CP

[continued from part III]

Continuing the security comparison between HCE and secure-element based NFC applications, this post expands on an earlier theme around attack-surface, focusing on one massive piece of vulnerable code: the Android operating system itself.

When root means game-over

Consider the following hypothetical: is it possible to build an EMV payment application that runs on Android and yet can resist attacks from a remote adversary who is running arbitrary code with root privileges? At first this seems theoretically impossible. Payments are authorized based on the possession of a cryptographic key only known to the legitimate card holder. The assumption is if you have possession of the key, by executing a protocol specified by EMV that calls for proving possession of that key without revealing it– you are authorized to spend the funds associated with that account. If our hypothetical adversary has achieved root privileges on the device, they have full access to memory and storage of every application running on that device. That includes the payment application wielding this secret. Even if that secret was protected by a PIN/passphrase (let’s suspend disbelief and assume users pick high-entropy secrets immune to guessing) that PIN/passphrase will be input via phone UI such as an on-screen keyboard at some point. Since we posit that our adversary is running with root privileges, she can watch this interaction and learn the passphrase. Alternatively she can simply wait until after the secret has been fully decrypted locally– necessary for the device to be able to perform the type of computations envisioned by EMV payment protocols– and capture it at that point. No secret managed completely by an Android application can be immune from an attacker with root privileges on that Android device. It’s only a matter of knowing when/where to look for that secret in the target application’s address space; this is security through obscurity at best.

SE difference

Unless of course, the secret is not directly available to the mobile application either. Enter hardware secure elements. If  secrets such as cryptographic keys are stored in the secure element and never available in the clear to the mobile application, even root-level compromise of Android does not help our adversary. The embedded secure element is its own mini-computer, with separate RAM, storage and embedded operating system with its own concept of access control. Being root on Android is meaningless to SE: it grants no special privileges. In much the same way that an HSM can isolate cryptographic keys by offering an interface to perform operations with the key without revealing the raw bits of the key, SE keeps Android at arms-length from secret material.

Safe provisioning

The astute reader might ask how these cryptographic secrets that enable payments reached the secure element in the first place. It is common for provisioning to take place over-the-air, as opposed to the much more impractical alternative of requiring physical presence, where the user must walk into a bank branch and present their phone. That implies that some bits are pushed over the network to the mobile application which relays them to the secure element. (Recall that the only direct network interface SE has access to is NFC which is only good over short distances. All other communication such as accessing the card-issuer API endpoint over the Internet must be pass through the host device.)

Does that create an opportunity for malware running with root privileges to capture the secret, for ever so briefly when it is passing through the Android application? Not if the provisioning system is properly designed. Recall that secure elements compliant with Global Platform standard are “personalized” with unique keys (colloquially known as card-manager keys) required to perform administrative operations. These keys are not known to the owner of the phone or even the operating system on the mobile device; they are managed by a third-party called “trusted services-manager” or TSM. When TSM is installing a payment application and configuring that application with its own set of secrets, the commands sent to the SE for performing those steps are encrypted. Global Platform specification defines a “secure messaging” protocol describing the exact steps for establishing an authenticated & encrypted link between TSM and secure element. This protocol, or more accurately series of protocols since there are multiple variants, is designed to ensure that even when TSM and SE are not in physical proximity, as in the case of provisioning a payment application over the Internet– the issuer can be assured that sensitive information such as payment keys are delivered only to the designated SE and not recoverable by anyone else. While it is true that the commands sent by TSM are visible to the host operating system, where they can be intercepted or even modified by our hypothetical adversary who has attained root privileges, the secure messaging protocol ensures that no useful information is learned by mounting such an attack.

Threat models: ideal vs as-implemented

So this is another fundamental difference between applications implemented in SE versus those relying on host-card emulation. For HCE applications, Android operating system is part of the trusted computing-base by necessity. Any vulnerability that allows defeating the isolation between different apps– such as local privilege escalation to root– is  game-over for scenarios using host-card emulation without a hardware secure element. By contrast, SE based applications can in principle survive attacks in this very stringent threat model, where we posit a remote adversary (eg one who does not have physical possession of the phone but is running her choice of code on the device) has attained root privileges.

“In principle” is the operative phrase. While Global Platform protects secrets en route the secure element, there is a preceding step not covered by GP: authenticating the card-holder. Suppose the consumer is asked to enter the username and password for their online bank account into the Android application to verify their identity and request provisioning from that bank. That design is blatantly  vulnerable to local malware on the device. Those bank account details could be captured and relayed to a remote attacker, who proceeds to repeat the exact same process on a device she controls, with the payment credentials being delivered to her secure element. She could even preempt the legitimate user, by provisioning first and instructing the malware to prevent the original card-holder from completing the task, lest the bank notice the anomaly of two different devices requesting cards in quick succession. Some form of out-of-band authentication is required to thwart this attack, such as logging into the bank website from a different machine to initiate the request. (Ironically calling the bank and answering questions will not work since the audio-stream from the phone is also available to the attacker.) But even in the basic scenario with weak provisioning, SE provides a useful guarantee: if the device is compromised by malware after payment credentials are provisioned, the credentials are safe.

There is one more subtle attack that does not rely on trying to extract secrets from the local device. Suppose the remote attacker with root privileges abandons their effort to extract secrets from SE but instead attempts to use the SE, exactly as it would have been invoked for a payment transaction? The next and final post in this series will look at how the integration of SE with NFC controller can frustrate such relay attacks, in stark contract from HCE applications which are necessarily vulnerable.

[continued]

CP

In this post we continue the security comparison of mobile NFC scenarios using dedicated hardware  (such as UICC or embedded SE on Android) against the same use-case implemented on vanilla Android application with host card-emulation. In both cases, there is sensitive information entrusted to the application such as credentials required to complete an EMV transaction. This time we will focus on  attack surface and amount of code exposure these sensitive secrets have against software attacks. Borrowing the definition from MSDN:

The attack surface of an app is the union of code, interfaces, services, protocols, and practices available to all users, with a strong focus on what is accessible to unauthenticated users.

Here again it is clear that a mobile application is at a distinct disadvantage because the application and the platform it is built on-top is feature rich with connectivity and sharing functionality. Looking at the typical inputs an Android application may process:

• Inputs from the UI– relevant when the phone lands into the hands of an attacker who can now press any button or otherwise try to bypass some access control
• Network connectivity. At a minimum the application will need Internet access to provision payment instruments and interface with a back-end system for retrieving activity data.
• Inter-process communication mechanisms from other applications installed on the same device. In Android this means intents, listeners etc. that the application responds to.
• Filesystem. If the application relies on any data stored on disk, it must
• NFC, inevitably for an application relying on NFC as transport.

By contrast the typical secure element has only 2 interfaces:

• Wired or contact. For an ordinary smart card or SIM, this would be the physical connection attached to the brass plate on the surface, which receives power and signals form the reader. In the case of secure elements on mobile devices, these are typically hard-wired to the host device. When the SE is removable– for example with UICC or micro-SD based designs– it is possible  to use an external card-reader to access this interface.
• Contactless or NFC, same as before.

While these are the only direct input paths, in many cases there is indirect exposure to other channels. For example there is often a companion user-mode application running on the host Android OS, helping load new application on the SE and configuring them. Such provisioning is often done over-the-air with the Android app simply shuttling data back-and-forth between its network connection and the contact interface of the SE.  This could be  straight through the base-band processor, bypassing the main Android OS or a standard TCP/IP connection. Either way an indirect channel exists where inputs from a potentially hostile network reach the secure element.

This is where a different property of the SE comes in: it is a locked-down environment, where routine operations– such as installing applications or even listing the existing ones– requires authentication with keys that are commonly not available to the owner of the phone. (They are instead held by the trusted-services manager or TSM entity responsible for card management.) This stands in contrast with an ordinary iPhone or Android where the user is free to install applications. Just in case the user makes a bad decision, each app has to worry about other malicious apps trying to subvert their security model and access private data associated with that application. By contrast code running on SE is tightly controlled and much of the complex functionality for managing the introduction of new code is not even accessible to ordinary attackers without possession of diversified keys unique to that particular SE.

Similarly in common secure element designs based on Global Platform, there is no concept of an all-powerful root/administrator with full access to the system. For example even the TSM armed with necessary keys can not read out the contents of EEPROM at will. This means that once an application is installed and secret material provisioned to that application (such as cryptographic keys for EMV chip & PIN payments) even the TSM has no way to read back those secrets from the card if the application does not allow it. One could imagine that TSM can try a different tactic: replace the legitimate application with a back-doored version designed to extract the secrets previously provisioned. But there is no concept of  “upgrade” in Global Platform: one can only delete an existing application instance– which also removes all of its associated data including the secrets– and install a new one. Barring vulnerabilities in the platform responsible for isolating multiple apps from each other (eg Java Card applet firewall) provisioned secrets are forward-secure. By contrast the author of ordinary mobile apps always have the option of upgrading their code in-place without losing data, creating another attack vector when code-signing process is subverted.

A similar risk applies on larger scale for the mobile operating system. Google effectively has root on Android devices, similarly for Apple on iOS and MSFT on Windows Phone. Often times the handset manufacturer and even wireless carrier subsidizing the device add their own apps running with system privileges, including remote update capabilities. These parties are the closest to a TSM incarnation (minus the “trusted” part) except they can snoop on any secret managed by any application on the device. Again the threat here is not that Google, Samsung or Verizon might go rogue, shipping malicious updates designed to steal information. The risk is that the platform includes this capability by-design, creating additional attack surface that others can attempt to exploit.

Finally there is the matter of sheer code-size: SE resources are highly limited, with EEPROM/flash storage on the order of 100KB– that includes code and data for all applications. That does not leave a lot of room for frivolous functionality, rarely used options or speculative features. This is a case where resource constraints help security by reducing total amount of code, and indirectly, opportunities for introducing bugs.

[continued]

CP