Month: December 2013

Meaningful choice: AppOps, Android permissions and clashing interests (part I)

The recent furor over Android 4.2.2. removing AppOps is a great example of Lawrence Lessig’s idea of regulation-by-code, when design decisions in technology are used to promote the interests of one particular group– in this case application developers– over another disfavored group, namely users.

First some background on this debacle. Android implements a relatively coarse-grained permission model, controlling what can be done by applications installed on the device. For example an app can be prevented from reading address book, making phone calls, sending text messages, accessing the camera/microphone or using Bluetooth. When this model debuted circa 2007, it represented a significant advance in terms of security models implemented for an off-the-shelf consumer device.

Sure, the academic literature did not lack for examples of elaborate fine-grained sandboxing schemes to control not only whether an application could access local storage but specify exactly which files it could read/write. Yet the state-of-the-art for  PCs and Macs continued to rely on user accounts as the fundamental security boundary. The assumption was any application user runs automatically inherits all access rights available to that user. For example when a Windows application is installed and run, that application executes with the full privileges associated with that account. (In fact since installers typically required administrator privileges, at least for a limited period of time the application had full reign over the machine.) User-account control in Vista, the first attempt to challenge that assumption, ended in disaster with its often ridiculed elevation prompt constantly asking users to make security decisions.

Luckily Android took a different route: applications declare the permissions they require to function, the user only gets to review & approve that once at the time of installation. There are very few situations beyond that when consumers were confronted with security prompts otherwise. (Authenticating with user credentials saved on the device being the primary exception.)

Meaningful choice

But there is a difference between mechanism and policy. While Android allowed specifying permissions at a granular level, it did not allow users to assign permissions at will. There was a very simple negotiation model. The author of the application specified exactly which permissions were required. The user either agreed and installed that application, or they disagreed and walked away. In other words: take it or leave it. This was clearly not a case of “meaningful choice,” in the same way that passengers can opt out of TSA security screening if they agree not to board the airplane. (Strictly speaking if one does not board the flight, they are not a passenger.)

Many people– both inside and outside Google– wandered out loud why Android did not give users more control. For example, why not allow an application to be installed but also remove some egregious privilege requested by the developer? This provides the best of both worlds for the user: she gets the benefit of running the application and avoids the potential privacy harms caused by granting the dangerous permission..

AppOps

And that is exactly what AppOps offered. A hidden feature inside the familiar Android Settings application, it allowed users to view and edit permissions granted to each application.

Too powerful for its own good apparently. Not long after EFF wrote a glowing review calling it “awesome privacy tools” and guiding Android users to third-party applications for unleashing this hidden functionality, a minor system update to Android quietly removed the feature completely. Before the functionality was present but hidden: not exposed to users directly through the standard Android user interface, suggesting that perhaps Google did not consider it ready for prime-time or only intended it for internal experiments. After installing the update it was gone for good, with work-arounds only available on rooted devices.

So what was the problem with AppOps? This question can be answered on two levels: technology and business.

Technology view

Privacy-infringement apologists may point out that allowing applications to be installed with a subset of requested permissions would greatly increase the complexity of writing applications. Instead of a simple model where the application either never gets to run or runs with all requested permissions, the developer has to worry about in-between states where some operation may fail because the user decided to deny that permission. At an implementation level, that translates into added complexity. Permission errors translate into an exception in code, so now the developer is stuck writing additional code to catch this error condition and respond appropriately. (Typically one of: exit the application in disgust, shame the user into granting missing permission or move on without the requested information.)

Why not fabricate data?

There is a simple counter-argument to that objection: if the user declined permission, let’s not trigger a fatal error but instead return bogus or empty data. The application wants to learn the current location but the user does not want to be tracked? Have “GPS” report a random location around the globe. Developer wants a list of all the contacts in the address book? Fabricate “John Doe” friends or report that this user has no contacts. Developer is asking for Bluetooth access? Appear to grant access, but pretend there are no other Bluetooth devices paired to connect to.

[continued]

CP

NFC card emulation and Android 4.4 (part IV)

Part III sketched the mechanics for host-based card emulation (HCE) in Android and how AID routing is used to create an open ecosystem for user-mode applications to offer NFC services. This post will look at some edge-cases of HCE and some differences from the embedded secure element.

Feature parity

A natural question is whether HCE is “equivalent” to embedded SE or UICC from a functional perspective. (It is clearly weaker in terms of security guarantees, a subject for the next post in this series.) There are two different interpretations of that criteria:

  1. Can any application implemented with hardware SE also work with HCE?
  2. Is it possible to distinguish externally whether HCE or hardware SE is in use?

In the first scenario we assume external NFC readers interacting with the device remain fixed. No changes are envisioned to the deployed readers while we switch the phone from using eSE to HCE. This is the model relevant for compatibility. In the second case the NFC reader is going out of its way to try to distinguish between hardware and software-backed implementations.

Edge-cases

Short answer to #1 is yes in principle, but not the way it is currently implemented in Android due to some edge-cases. SELECT semantics in Android HCE are subtly incompatible with the way a Global Platform compliant card-manager behaves.

  • If an application with given AID exists, card manager switches the active context to that one. This is outside the control of the currently selected application.
  • If such an application does not exist, the SELECT command in its entirety is delivered to the currently active application. This is required  because ISO7816 “overloads” SELECT command for simulating a file-system on smart cards. The command corresponds to “directory” traversal (eg change directory) as well as opening a “file” for reading, depending on the currently selected “file.”

The second part does not work with HCE in Android. SELECT routing is handled by the OS and for unknown AIDs a simple error is returned instead of giving the current application an opportunity to respond.

Another difference is that in Global Platform, an application can be installed as “default-selected” meaning that it is automatically activated when the chip is powered on. There is no SELECT required, readers can start sending application-specific commands right away. Several smart card standards including PIV mandate that cards are configured in this manner. Android HCE does not support this. Trying to interact with the phone in HCE mode as if the intended application was already activated (without an explicit SELECT containing the AID as hint to Android) is an error.

Neither of these are fundamental limitations. SELECT behavior can be changed and NFC stack can also define a notion of “default selected application,” along with conflict-resolution rules.

Distinguishing externally

By similar reasoning, distinguishing HCE from hardware SE is trivial in the current Android incarnation: try to select the card manager, either by using its explicit AID (slightly different for each manufacturer such as NXP vs Oberthur) or with empty SELECT per Global Platform. Hardware SE will return the response from the card manager describing its functionality, HCE mode will return an error.

But as noted above this is not a hard limitation. A “card manager” replacement complete with cryptographic keys, secure channels and lifecycle management (so it will appear to be bricked after too many failed authentication attempts) can be implemented at Android level, set as default selected application. To an observer looking only at the content of messages flowing over NFC, this emulation will behave identical to hardware SE.

Of course there are side-channels such as the timing of request/response pairs and other meta-data that can give away the source. For example if eSE supports extended-length APDUs (HCE in Kitkat does not) that discrepancy can be used, or the buffering behavior when reading large APDUs can be different since the host has lots of memory and won’t exhibit a sharp discontinuity when the data suddenly exceeds the size of the limited buffer in eSE.

Coexisting with hardware SE

Interesting enough, Kitkat still allows using the embedded-secure element alongside HCE, perhaps in a nod to backwards compatibility. This mode leverages the AID-routing feature built into the NFC controller, which allows picking a card-emulation route on-the-fly based on AIDs at the hardware level. (Same mechanism used to support applets on both UICC and eSE when multiple chips are connected to the controller.)

All AIDs for applications residing on the secure element need to be declared in the  manifest. Android passes this information straight to the NFC controller; the routing decision is made at hardware level. SELECT commands for these applications will not make it to host operating system. NFC controller internally maintains a table of AIDs and associated routes. It is the responsibility of Android to populate that table based on information collected across all manifests. Any application not explicitly listed is sent up the default route.

There is a catch. NFC controllers have a limited amount of space available for maintaining such tables. The ideal scenario has most applications residing at the default route and not requiring a table-entry, with only a few exceptions listed for redirection. Seen in this light,  decision to use HCE as default and embedded SE as the exception reaffirms the change in emphasis from relying on hardware SE towards host-based designs.

CP

NFC card-emulation and Android 4.4 (part III)

[continued from part II]

Opening the platform to third-parties

eSE nd UICC provide a high-level of security and physical tamper resistance. But the locked-down environment also presents a challenge for enabling a third-party ecosystem of developers. As previous posts explored, installing applications on the embedded secure element or UICC is not a free-for-all. Card “content management” in Global Platform terminology requires knowledge of the unique card manager keys for each particular unit. (This is a simplification; for more details see earlier post.) End users and application developers do not have direct possession of these keys. Instead they are wielded by a trusted third-party dubbed Trusted Services Manager or TSM who is called on to perform the privileged operations of installing, configuring and deleting applications. On paper Global Platform envisions many complex business models where an application provider can contract with TSM to install applets on its behalf. The latest iteration GP2.2 permits supplementary security domains to perform content management. TSM could inject an SSD for each third-party and delegate application management to individual providers.

Making such arrangements work in reality has been a different story. At least for Android, with the exception of proofs-of-concept and internal demos, embedded secure element has been used only for contactless payments with Google Wallet. Similarly UICC/SIM is being used only for enabling the same scenario with a competing product called the ISIS Wallet. If secure elements had been deployed in μSD form-factor, chances are they would not fare any better in supporting an ecosystem of third-party developers. While μSD is a removable component  decoupled from handset manufacturer and carrier, there is still some entity wielding the card manager keys.

Another level of indirection

Compared to the tricky machinations required for third-parties to get their application on Global Platform-compliant secure elements, HCE greatly lowers the bar for adoption. Installing a vanilla Android app is sufficient, accessible to many developers unlike the more stringent criteria of earning the good graces of a wireless carrier. There is no need to coordinate with TSM or get permission from the handset manufacturer. Developers simply declare NFC services implemented by their code. When the phone is interacting with an external NFC reader and receives traffic, the operating system picks the intended destination by using the same trick NFC controller uses to juggle applets spread across two secure elements: AID-based routing.

As far as the NFC controller is concerned, all “host card emulation” traffic is delivered to a single endpoint represented by the Android NFC stack. There is no notion of different wallet applications or other user-level distinctions made. It is up to Android to handle that multiplexing by selectively delivering APDUs to the intended application.

AID routing in Android

Android relies on application manifests to work out this association. Every application interested in acting as a card-emulation target declares the application ID (“AID”) for which it can respond to commands. Much like the NFC controller or card manager, Android looks at the payload of incoming SELECT commands and picks an application for routing based on the AID specified in the command. This is a stateful decision. It affects not just that initial SELECT command but all subsequent APDUs. Traffic is delivered to that application until another SELECT command arrives to switch context to a different applet.

Conflict resolution

This model faces a couple of additional complications at Android level: multiple applications can claim the same AID. This can not arise on an ordinary GP-compliant smart-card. Only one applet can be installed with a given AID and the card manager will error-out on attempting to install a duplicate. Since there is no such thing as a “global-platform card manager” on Android, the system does not detect/stop such collisions. Instead they are handled by the familiar Android pattern of ranking user preference. Nothing prevents the installation of multiple “web-browser” applications claiming to handle http:// URLs but Android will resolve the ambiguity by prompting users. AID conflicts are resolved by a similar system although the user-interface is not well-defined at this point, with the curious exception of payment applications which are given their own real-estate in system settings. All other applications make do with an API to check if they are the preferred application and another API to be prompted to that spot.

AID grouping

Closely related to the problem multiple applications registering for an AID, Android allows “bundling” multiple AIDs such that an application will handle all of them or none of them. This avoids getting into a mix-and-match situation where commands associated with one AID is routed to Android application A, while commands for another one are routed to B due to conflict resolution. Such a mix-up can prevent both A & B from working correctly in scenarios when multiple card applications are involved for a particular scenario.

EMV is a very relevant example of what can go wrong if different AIDs are split across multiple Android applications. During a transaction, the point-of-sale readers first selects the PPSE (Proximity Payment System Environment) application to enumerate the available cards. Then it selects an application corresponding to one of the listed cards to carry out the payment, such as MasterCard Paypass. Consider two mobile wallets installed on the same Android device, each managing its own set of payment instruments. If PPSE implementation from wallet A is used to choose preferred credit card, but then Android switches to wallet B when Paypass AID is selected, the POS will be working with an inconsistent transaction state. (In fact the second wallet may not even have a payment instrument available corresponding to that AID, in which case the transaction will fail.)

[continued]

CP

NFC card-emulation and Android 4.4 (part II)

[continued from part I]

Choosing between multiple routes

To complicate matters, an NFC controller can support multiple connections and switch between them. For example the PN544 was capable of supporting both the UICC and embedded-SE link. The currently active path is called the “card emulation route.” Until ISIS most Android devices hard-coded this to point to the embedded SE. In principle the setting can be toggled at any time; it is not baked into the controller firmware. But until recently Android NFC stack always issued the command to set the route to eSE during boot and did not provide a way to change that later. (Not that it mattered; on most devices there is no physical wire from UICC to NFC controller. Switching the route would have no effect. More recently the presence of that extra wiring is required for ISIS compatibility.) Conversely an early prototype ISIS device this blogger examined  hard-wired the connection to the UICC, guaranteeing that Google Wallet could not run on the device even if the user managed to work around carrier restrictions.

Supporting multiple routes

The preceding discussion makes a simplifying assumption: while multiple secure elements may exist on the phone and attach to the NFC controller, only one of them will ever be used at a time. For example if the user has a payment application residing on the embedded SE and an identity application on the UICC, exactly one of them is externally accessible to an NFC reader at any given time. At best the user has access to some switch in the mobile operating system to toggle between these two options ahead of time, before the tap event.

Luckily one need not rely on such advance planning from the user. Modern NFC controllers have additional smarts to allow multiple card-emulation targets to coexist at the same time. The trick involves implementing the equivalent of content-inspection on incoming ISO7816 commands. Earlier we mentioned that the controller functions as a router, merely shuttling NFC traffic from another nearby peer to its ultimate destination. In reality modern controllers are not passive conduits; they peek at the messages flowing through and make decisions based on the payload.

Deep-packet-inspection, NFC style

That functionality is useful even when there is a single secure element in the picture. Here is a basic user-experience problem for tap-and-pay: when the user taps their device against a point-of-sale terminal and starts a payment event, it is often necessary for an Android application to intervene. For example the user may need to be prompted to enter their PIN if the operation was declined. After the transaction goes through, the application may want to display a confirmation. Minor problem: in card-emulation mode the host does not have any visibility into traffic being sent to the secure element. Incoming requests are delivered directly to the SE, where the responses also originate without ever bubbling up to the host. The user-interface for our hypothetical wallet application would have no idea that the user just tried to make a purchase.

Getting a handle on SE events

Luckily system designers anticipated that problem and introduced some notifications, which are in turn incorporate to the Android NFC stack in the form of notifications delivered to associated applications. Specific triggers include:

The first two notifications may look promising, without requiring any traffic inspection. RF field presence is about registering the existence of a change in physical environment. If payments were the only application, that would have been sufficient signal to conclude that the user attempted a transaction. (Of course in retrospect that is exactly the only scenario Android eSE was used for on any large scale.) Imagine a more ambitious vision when the SE serves both payment and public-transit scenarios, each of with a corresponding Android user-mode application. Depending on whether the user tapped a cash register or turnstile in the subway, the system needs to wake up the correct app to present additional UI.

That calls for looking at the contents of incoming traffic. Per ISO7816 SELECT commands are used to activate applications. By looking at the application identifier or “AID” specified in that APDU we can determine what type of transaction an external reader attempted. That is effectively the third notification above: it contains the AID for the specific applet selected. (As an aside, on Android only privileged applications whitelisted for NFC-extras receive these intents.) This allows applications to bring up UI– for example PIN entry in the case of Google Wallet– only when they can be certain their own SE applets have been invoked, as opposed to just any random applet.

That was an example where the NFC controller is parsing the contents of a request APDU coming over NFC and bubbling-up a notification to the host. It is also one of the exceptions to a principle described in the first blog post: host does not have visibility into external NFC traffic addressed to the SE in card-emulation mode. (Incidentally Android source code has references to another notification called “APDU received” which promises to return the full contents of an incoming NFC request. It is not implemented, and in fact can not be implemented because most NFC controllers do not have such a capability.)

The next post will describe how this capability in the NFC controlled enables supporting multiple SE simultaneous, as well as allowing SE applications to coexist with host-card emulation.

[continued]

CP

NFC card-emulation and Android 4.4 (part I)

[Full disclosure: This blogger worked on Google Wallet 2011-2013.]

Android version 4.4 dubbed Kitkat has recently introduced a new (at least “new” for the official Android distribution) NFC feature called host-based card emulation or HCE for short. HCE is  the basis for a different approach to contactless payments, a pivot away from the original strategy based on the embedded secure element. The first signs of that shift arrived earlier this summer with a curious change in the Nexus 7 hardware specs. Previous Nexus devices starting with Nexus S all contained an embedded secure element, a critical feature leveraged by Google Wallet for NFC payments. While the tablet form-factor is arguably less convenient for tapping against a point-of-sale terminal– and Wallet even ran on the larger Nexus 10 tablet– the SE was also present in the original Nexus 7 in 2012. Fast forward one year, it was conspicuously absent from the update released in July. Similarly the flagship Nexus 5 launched without an embedded secure element, becoming the first pure Google-experience phone to shed the SE.

This is unfortunate for mobile device security in general; an embedded secure element has many applications beyond NFC payments. There is a fascinating lesson in market-dynamics here: how a consortium of US wireless carriers invested in a rival payment project called ISIS successfully thwarted the deployment of an important security technology. But that is a discussion for a different time. This post will focus on the mechanics of HCE and subtle interactions from trying to coexist with embedded SE or SIM-based applications on the same device.

Card-emulation options

In card-emulation mode an NFC controller simulates the behavior of an ISO-14443 smartcard. This allows mobile devices to substitute for standalone plastic cards and dongles used in traditional security applications such as EMV payments, US government PIV card, public-transit, physical access with badge-readers and logging into a personal computer. Grossly oversimplified, that involves tunneling ISO7816 commands over NFC  to some application sitting behind the controller. This is where the different hardware options come into play. An NFC controller is just a gateway; it is not a general-purpose computing environment where applications get installed. The actual “card application” lives on some other piece of hardware that is wired to the controller. For example:

  1. Embedded secure-element or eSE for short, typically part of the same hardware as NFC controller. This was the original approach taken with Android devices. For example Nexus S and Galaxy Nexus feature a PN65N chip from NXP Semiconductors, combining the PN544 controller coupled to a SmartMX secure execution environment.
  2. UICC or glorified SIM card with additional  features. Single Wire Protocol (SWP) is the standard for connecting connect UICC & NFC controllers. This is the approach taken by ISIS for its mobile payment application.
  3. Special micro-SD cards containing a secure element. No production Android device operates in this configuration, but µSD cards such as Tyfone SideTap have certain advantages. They are easily moved between devices and they are not tied to the mobile carrier or handset manufacturer.
  4. Host-based card emulation. Originally implemented by SimplyTapp as a patch on top of Cyanogenmod 9, and now independently implemented by Google for Android 4.4. Incoming NFC traffic from external reader is delivered to the host operating-system which generates the response.

Direct connection and security implications

One important detail about the first three options above stands in sharp contrast to host-based card emulation. In these modes data sent/received does not travel through the host operating system. In other words, it is not the case that eSE outputs data to Android which in turn forwards that packet over to NFC controller for transmission over the air. Links to/from  eSE/UICC/µSD are direct. Android never sees that traffic. This is an important security feature. Consider a payment application implemented on the eSE. Such an application communicates sensitive financial information to a point-of-sale terminal during payment transactions, including credit card numbers. If that data was routed through the host OS, malware running on the host could observe it. This property is enforced by the firmware of the NFC controller itself; it is independent of any Android-side behavior. Not even malware running with Android kernel privileges can change that.

Interestingly the converse property for incoming traffic does not hold. Before the user taps their phone against an NFC reader, host malware could have switched the NFC controller into HCE mode to gobble up data intended for the eSE. But even in this scenario a weaker guarantee holds: a given command is delivered either to the eSE or the host operating system, but not both.

Another subtlety: there is also a connection from the host the embedded secure element that allows host OS to speak ISO7816 and exchange APDUs with the SE directly. At first this appears to enable a man-in-the-middle attack executed by host applications: malware receives traffic from external reader in HCE mode, accesses the SE directly over the host-interface and forwards same command as if it were received directly over NFC radio. Incidentally this hypothetical example assumes malware has already breached Android security, and is executing with root privileges. Ordinary apps on non-rooted device are limited to the subset of operations exposed by the NFC stack. There is no permission defined to allow privileged operations such as switching controller state. Even under these generous assumptions, the attack fails for a different reason. Applications running on SE can determine whether any given command is received over the “wired” interface– connected to the host– or “contactless” interface attached to the NFC antenna. So-called interface detection logic is an integral aspect of many standards including EMV. It is critical for keeping the host operating system out of the threat model. (There is also the incidental fact that changing NFC controller mode on PN65N/O will reset the secure element, losing application state and further frustrating attempts to relay commands. But it is unwise to rely on such hardware idiosyncrasies.)

[continued]

CP