HCE vs embedded secure element: attack surface (part III)

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.




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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s