Landon Cox

Kahawai at MobiSys

It was great to see former student Eduardo Cuervo present our paper on Kahawai at MobiSys ’15 last week.

Kahawai is a new approach to cloud gaming that allows a computer with an under-powered GPU, such as a mobile device or an older-generation gaming console, to render the same visual output as a computer with a top-of-the-line GPU. There are a number of commercial cloud-gaming systems, such as Ubitus and PlayStation Now, that aim to do the same thing, and these services take a thin-client approach to cloud gaming. That is, the game executes on a server equipped with a powerful GPU, and the game output is encoded as compressed video and streamed to clients. The problem with a thin client approach is that the bandwidth requirements are substantial, with services typically requiring a minimum of 5 Mbps between the server and each client.

Eduardo had two insights about this bandwidth problem. First, even though a computer might not have 300W GPU, it might still have a perfectly capable GPU. For example, smartphones have increasingly powerful GPUs, even if they will never render the same level of detail at the same rate as a dedicated gaming rig. Thin clients leave these perfectly capable GPUs idle since the remote server is completely responsible for generating the game’s output. A better approach might be to use the client’s GPU to reduce the amount of data the server has to stream. Eduardo’s second insight was that games naturally support multiple levels of visual fidelity. Most games allow a player to adjust its settings to match the power of their hardware, so that players with less powerful hardware can play the game with lower-fidelity graphics.

Based on these observations, we developed the idea of collaborative rendering, in which the client generates a low-fidelity version of the game’s graphics using its local GPU, and the server sends only the missing details from its high-fidelity version of the output (rather than the entire graphical output). Kahawai supports two implementations of collaborative rendering, one in which the client generates low-detail graphics at a high rate (a technique called delta encoding) and one in which the client generates high-detail graphics at a low rate (a technique called client-side i-frame rendering).

Experiments with our Kahawai prototype are extremely promising. For Doom 3, Kahawai uses 1/6th of the bandwidth of a thin client, while a user study with 50 Microsoft gamers demonstrated that the gaming experience of Kahawai and a thin-client are essentially equivalent. The upshot is that Kahawai gives players the same gaming experience as a conventional cloud-gaming service without gobbling up their cellular data caps or clogging their home networks, and Kahawai significantly cuts the bandwidth costs for cloud-gaming service providers.

Kahawai took several years to complete and many people contributed. Eduardo started the project while interning at Microsoft Research with Alec Wolman, Stefan Saroiu, and others, made significant progress after coming back to Duke, and tied up all the loose ends after joining MSR full-time.

SpanDex at USENIX Security

We just posted our upcoming paper on SpanDex, which will be presented at USENIX Security ’14 in August.

SpanDex prevents malicious mobile apps from phishing users' passwords by ensuring that a password can only be forwarded to trusted servers. The primary technical challenge addressed by SpanDex is precise, sound, and efficient handling of implicit information flows (e.g., information transferred by a program’s control flow). The long-standing problem of implicit flows is one of my favorites in computer security. It’s an incredibly hard problem (probably impossible to solve in the general case), but I think we’ve made a nice little contribution with this paper. Prior approaches to tracking implicit flows either ignored these flows altogether (e.g., TaintDroid), allowing malicious code to easily leak sensitive information, or induced overtainting in non-malicious apps so that nearly all messages appeared to leak sensitive information.

The key observation underlying SpanDex is that most branching on sensitive data transfers very little secret information. For example, mobile apps typically only branch on password characters to perform simple formatting checks. The aggregate information revealed through these implicit flows is almost always that a password is well formatted, and disclosing that a password is well formatted poses no threat to a user.

Using this observation, SpanDex handles implicit flows by borrowing techniques from symbolic execution to precisely quantify the amount of information a process’ control flow reveals about a secret. So long as the information revealed by an execution path reveals a safe amount of information (e.g., that a password is well formatted), SpanDex does not track the influence of implicit flows on a program's state and thus avoids overtainting. At the same time, quantifying the amount of information revealed through implicit flows during execution allows SpanDex to prevent a malicious app from using control flow to leak passwords. To apply this techniques at runtime without sacrificing performance, SpanDex runs untrusted code in a data-flow sensitive sandbox that limits the mix of operations that an app can perform on sensitive data.

Experiments with a SpanDex prototype for Android using 50 popular apps and an analysis of a large list of leaked passwords predicts that for 90% of users, an attacker would need over 80 login attempts to guess their password. Today the same attacker would need only one attempt for all users.

TaintDroid for Android 4.3

Announcement from the NCSU guys:

The TaintDroid team is happy to announce the release of TaintDroid for Android 4.3_r1. The instructions for obtaining and building this version are available as usual on appanalysis.org.

We also have an issue tracker set up at 
https://code.google.com/p/taintdroid/ for reporting bugs with TaintDroid. If you notice any bugs with the new release of TaintDroid, or with any of the previous versions, please submit a bug report on the issue tracker. If you have a solution for the bug fix, please also submit it in the bug report. Since TaintDroid is maintained by a small group of people, your feedback is greatly appreciated and crucial for the ongoing maintenance of TaintDroid.

We are also working on constructing a suite of regression tests for TaintDroid, which will be uploaded to Github as soon as it is complete.

-Ben Andow

ScreenPass at MobiSys

We just posted our upcoming paper on ScreenPass, which will be presented at MobiSys ’13 in June. My group has been thinking about the problem of securing passwords on mobile devices a lot lately, and we think that ScreenPass is a big part of the solution.

Passwords are a critical glue between mobile apps and remote cloud services, and nearly all of the apps that I install ask for one or more passwords. Many people would like us to move beyond password-based authentication, but I doubt that this will happen anytime soon. Given how important and sensitive passwords are, it shouldn’t be a surprise that researchers have already found at least one malicious, password-stealing app in the wild (a very convincing fake NetFlix app). I suspect that we will see more of these kinds of attacks in the future.

The problem is that, right now, I have no idea what happens to the passwords I give to my apps. I’d like to know that if I give my Facebook password to an app, the data will only be sent to Facebook servers. Taint-tracking password data is almost certainly a big part of the solution, but secure password entry is also crucial. This is because password data can’t be tracked unless it is tagged by the operating system beforehand. If a malicious app can trick a user into inputting their password without the operating system’s knowledge, then there is no way for the OS to guarantee that my Facebook password is sent to only Facebook. This is where ScreenPass comes in.

ScreenPass guarantees that whenever a user enters her password, she can always (1) tell the operating system where it should be sent, and (2) know where the operating system thinks it should be sent. We provide these guarantees by ensuring that only a trusted software keyboard handles text input. In particular, ScreenPass performs optical character recognition (OCR) on the display at runtime to detect malicious apps that try to spoof the trusted software keyboard. ScreenPass is unique in that it is the first secure user interface to regulate what an app is allowed to write to the display (instead of regulating only where it can write on the display). There are many more details in the paper, including our ScreenPass prototype’s usability and energy overheads, as well as the results of a small app study (spoiler alert: we found a handful of non-malicious apps that send passwords to places you might not expect, and we easily detected the fake NetFlix app).

ScreenPass took several years to develop; we had a number of false starts early on, and it took a long time to put together a convincing evaluation. However, I’m very happy with the final paper, and am looking forward to presenting our work in Taipei in June!

TaintDroid for Android 4.1

Announcement from Will Enck:
The TaintDroid team is happy to announce the release of TaintDroid for Android 4.1.1_r6. The instructions for obtaining and building this version are available as usual on appanalysis.org

We would specially like to thank Minh Tuan Pham for porting the bulk of
TaintDroid from Android 2.3.4 to Android 4.0.3, which was nontrivial due to the significant changes between the versions. Minh also added tracking support for ByteBuffers.

We would also like to thank Peter Gilbert for porting the "fast" and JIT Dalvik VM interpreters to Android 4.0.3, as well as all of the changes to Android
4.1.1_r6, and preparing the code for release.

Also with this release, we have included a compile-time option for byte-level tracking within Parcel IPC messages, which was implemented by Seungyeop Han at University of Washington. Seungyeop also contributed several bug fixes to
TaintDroid.

Finally, along with this release, we have included the source code for TaintDroidNotify, which was written by Gabriel Maganis at UC Davis.

Happy tracking!
Will Enck and the
TaintDroid Team