There are 3 project options available this semester. Project teams must schedule a demo session for 12/11-12 (or earlier) and must turn in a final report by 12/15. The report should describe the project and any revisions made in response to feedback during the demo.
Deadlines are:
| Date | Task | Weight of Grade | |
|---|---|---|---|
| 12/11-12 | Demo | 40 | |
| 12/15 | Final report | 60 |
Note: If you would like to do a different class project, feel free to come discuss your project ideas with me.
This goal of this project is to build a system to let Android user's easily control how their private information flows around in their phone or out to the internet.
The project is inspired by two recent research papers:
The first paper describes TaintDroid, an open-source version of the Dalvik virtual machine that can track the source of information as it flows through a program executing inside the virtual machine. Thus, for example, TaintDroid knows where each byte of data in the program came from (e.g. from the GPS, or from the microphone, etc.) and can detect (and potentially block) that information being transmitted over the network.
The second paper describes a method for letting users easily grant applications the access rights they need to perform actions requested by the user. Briefly, the paper proposes to create custom widgets that applications can display in their user interface. These custom widgets are managed by the operating system. The widgets will have clear, easy-to-understand icons, such as a picture of the a microphone, so that the user can understand what privilege they grant to the application. By default, the application does not have access to any special resources (such as the microphone). When the user clicks the microphone widget, the OS receives the user input event. It then grants the application temporary access to the microphone, and forwards the user input event to the application. The application can then begin recording from the microphone. Thus, these widgets make it very easy for users to grant limited privileges to applications: the user only presses a single button to both grant the privilege and to invoke the desired application functionality.
This project envisions combining these two ideas as follows: Applications cannot, by default, transmit user private information over the internet. So, for example, applications cannot read the user's GPS location and then transmit that information over the internet. This policy can be enforced using TaintDroid.
However, the user can grant the application the privilege of transmitting her private information (such as GPS coordinates) over the internet using a trusted widget, as in the User-Driven Access Control paper. Such a widget might look like this (but smaller)
Privileges may be granted for a single use, for a limited time, or permanently. This is up to you in your design. For example, you may choose to only support single-use privileges. Or you may decide to support all the different options, with different icons to let the user know the duration of the privileges they are granting.
The project involves the following components:
The goal of this project is to produce a publication, ideally in time for the USENIX Security 2014 deadline (February 27, 2014). You do not have to complete the entire project by the end of the semester. You only need to complete one of the major components by the end of the semester (i.e. the TaintDroid policy-enforcement system or the OS-managed UI components).
This project is inspired by two recent papers:
The first paper designs an authentication scheme based on skill, i.e. users are able to login if they can demonstrate sufficient skill at playing a game. Since it is very difficult for them to transfer skill to another person, they are immune to threats asking them to reveal their authentication information.
The second paper describes a password scheme based on recognizing images. When presented with a small set of images containing the images in their password, users can log in easily. However, without that prompt (say, when visiting a phishing site), users have a difficult time communicating their password to the server.
This project envisions extending the ideas in the PhorceField paper to see if it is possible to create graphical passwords that users can remember and use to login, given a prompt, but cannot easily communicate to another person. The PhorceField paper demonstrated that users cannot easily communicate their password when using a search-based interface, but it is not clear if they cannot communicate their password using any interface.
For this project, you should collect two or more sets of images, i.e. images of concrete nouns (car, horse stapler, etc), images of human faces, images of landscapes, randomly-generated images, or some other classes of images. Each set should contain at least 10,000 images.
You will then perform a user-study to evaluate each set of images on two criteria: recognizability and communicability.
To measure recognizability, you should assign passwords consisting of a sequence of images from a single class to participants in your study. You should test the participants over a week or two to measure how well they are able to remember their password. You might expect that some passwords are easier to remember than others. For example, passwords consisting of faces may be more memorable than passwords consisting of randomly-generate art or landscapes.
To measure communicability, you should design a two-player system where one subject (the sender) attempts to communicate one or more images in his password to another subject (the recipient). You may provide the subjects with several communication channels, such as:
The one thing the sender is not allowed to do is to simply load their password image onto their screen and show it directly to the recipient. Make sure this doesn't happen in your study.
Measure how long it takes the sender to lead the recipient to find the sender's image. Measure success rates, in case some of your subjects fail to find the image at all. Solicit feedback on the difficulties they faced.
Finally, compare results across image classes. Is there a trade-off between memorability and communicability? Is there one class of images that offers a good trade-off, i.e. easy to remember but difficult to communicate?
You may recruit subjects from the students in our class. Students who serve as subjects will be given extra credit, equivalent to writing two sets of class notes, towards their final grade. You should design your experiment so that participation consumes at most 1-2 hours of subject's time.
Write a tool that uses fuzzing to test the Android APIs. Note your tool is not intended to fuzz android applications, it is intended to fuzz the Android APIs/OS. A related, but simpler tool would be Trinity, a fuzzer for the Linux kernel.
You may write a fuzz tester for a subset of the Android APIs. You should clearly define the subset you are testing and the security properties you intend to test with your fuzzer.
You may also use the Java Reflection API, as in the JavaFuzz tool.
You should implement the fuzzer and run it on an android system. Investigate any crashes or bugs provoked by your fuzzer. Report any real bugs you find to the Android Developers. Try to obtain feedback from developers confirming your bugs.
Be prepared to demo your fuzzer to me, and to explain any security bugs you found.