CS261 Projects

General information








A final suggestion: Aim high! The top projects could lead to publication (and in past years, a number of projects have led to publications).

The process


The project proposal was due Tue 15 October.

Here's how to submit your proposal. You should put together a web page for your project; currently all it needs to contain is the project members, title of your project, and proposal. Then just email the URL for your project web page to daw@cs.berkeley.edu by Tuesday, October 15th.


You will also be required to present your project at a poster session, to be held on Monday, December 9th from 2-4pm in the Woz lounge.

Finally, a project report will be due by 9am on Monday, December 16th. No exceptions or extensions will be granted, so get it in on time! See below for instructions.

The final report



You may submit your project report electronically or on paper. I prefer electronic submission, although you may choose either. In either case, the deadline is the same: Monday, December 16, before 9:00am.

If you submit electronically:

If you submit on paper, place it in my mailbox in Soda Hall (in the mailroom, or outside my office -- 765 Soda).

Example project topics



New attacks
Find new security weaknesses in any widely-deployed system.
Security auditing
Tools for vulnerability detection
Resilient aggregation
Build "resilient aggregation" components for TinyOS. Sensor networks (such as the TinyOS-based systems studied here at Berkeley) are often used to aggregate sensor information and use the result to control systems. For instance, we might put a sensor in each room of Soda Hall and use the average temperature to control the air conditioning. However, at present, our aggregation operations are not secure against errors or maliciously chosen inputs (as might happen if a sensor is compromised). For instance, consider computing the average of N data values: an adversary who can control one of those inputs can bias the output by any desired amount, hence the "average" is not a resilient aggregation operation. However, the median is resilient, because changing any one input by any amount will cause only a small change in the output. Build a prototype of a few resilient aggregation operators and study their usefulness in some sensor network application.
Adversarial simulation
Build an "adversarial simulator" for TinyOS. Currently, the TOSSIM simulator runs the system under friendly conditions (no dropped packets, no bit errors, no unfriendly timing of the scheduler). Hence, it can't detect ways that an adversary might try to crash or subvert the system. We might be more likely to find security bugs by running the system on parameters that are chosen to be the worst case for system, or that are likely to cover corner cases. For instance, an adversarial simulator might determine ahead of time all possible dependencies between tasks and then test exhaustively all possible orderings of interdependent tasks, looking to see if any of these orderings deadlocks the system. Build a prototype of an adversarial simulator and study its effectiveness.
Preventing casting bugs
      typedef unsigned short uid_t;
      void dowork(uid_t u);
      main() {
          int x = read_from_network();
          if (x==0)
Validation bugs in Linux kernel
Dawson Engler's group found many security holes in the Linux kernel based on improper input validation (see their paper) based on heuristic compile-time rules. Formalize their rules into a concrete type system, perhaps using flow-sensitive type qualifiers. Then, analyze the Linux source code using your type system, perhaps using Cqual for the type-checking.
Inlined reference monitors
Proof-carrying code takes a reference monitor (expressing some security policy) and injects it into the program during compilation, in an integrated way; then it is possible for the recipient to verify that the desired policy is enforced by the presented code. This allows us to build extremely efficient reference monitors: rather than implementing the reference monitor in a separate process (thereby incurring performance penalties), the reference monitor can be inlined directly into the code that it is supposed to monitor. Sometimes we don't care about the ability of a recipient to verify that code injection was done appropriately, for instance because the injector and receiver are one and the same. Can we build a more lightweight implementation of this functionality?
For instance, maybe we can emulate some notion of "user-level call gates" using the mprotect() system call? (We could imagine storing the reference monitor's state in a write-protected segment of memory; then any call to an interface that is protected by the reference monitor would be replaced with a call to the reference monitor entry point; and the entry point would need to write-enable the special segment and atomically transfer control to the reference monitor code.)
Virtual machines for security
Enforcing resource bounds on malicious code
Side channel attacks meet mobile code
Verifiable distributed computation
Security of peer-to-peer systems
Information retrieval for audit logs
Formal modelling of security systems
Secure coding
Theory or cryptographic work
Projects in theory or cryptography are not necessarily out of scope, if you have some specific ideas you consider relevant. For instance, formal analysis of cryptographic protocols or cryptographic primitives could probably serve as a reasonable topic.
Privilege separation
Distributed firewalls
Encrypted databases
Suppose we want to store our data on a remote server (e.g., so that we can take advantage of the computational power of the server) without requiring full trust in the remote server. What types of database semantics can we support? In previous work, Dawn Song, Adrian Perrig, and I showed a special way to store the data in encrypted form on the untrusted server so that the trusted server can do keyword searches over the encrypted data (on our behalf, and only when authorized by us) with minimal communication complexity. What other types of queries can be supported efficiently? How about if the goal is integrity rather than confidentiality? This is a cryptographic design problem.