CS261 Projects

General information

Your term project should address a research issue in computer security and consist of the design of some computer security system or technique, or the analysis and possible improvement of some existing system or technique. The main goal of the project is to do original research on a problem of interest in computer security.

You should work in a small group; I expect that teams of approximately 2--3 will be appropriate for most projects. Of course, expectations will be adjusted according to the number of people in your group. I will not categorically rule out solo teams, but I expect that working in groups will allow you to tackle more substantial research issues. If you have trouble finding a project partner, I can help you get matched up with someone else by maintaining a list of people seeking teammates.

Projects will be evaluated on their research contributions to computer security. At the end of the semester, you will write a conference-style paper on your work. See below for more details.

I expect that most projects will fall (more or less) into one of two categories:

  1. Design. Design projects will usually attempt to solve some interesting problem by proposing a design; implementing a prototype; and using the implementation as a basis for evaluating the proposed system architecture.
  2. Analysis. Analysis projects might, for example, study some previously-proposed implementation technique, existing system, or class of systems; evaluate its security properties; and provide new insight into how to build secure systems.
The research should be relevant to computer security, but this will be interpreted broadly. You are encouraged to find topics of interest to you; feel free to be creative in selecting a project topic.

If you're at a loss for a project topic, I've prepared a list of possible project topics that you can peruse as examples of how to a pick a suitable project. See below. But don't feel limited to these suggestions! They are intended only as examples.

A final suggestion: Aim high! The top projects could lead to publication in some security conference.

The process

You will write a concise (approximately 1 page) project proposal that should clearly state the problem you will be solving, the key challenges for new research, your plan of attack (including milestones and dates), and any special resources you might need from me.

The project proposal is due Mon 23 October, so you should get started now on finding a topic, selecting partners, and so on.

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, topic, and proposal. Then just email the URL for your project web page to daw@cs.berkeley.edu by Monday, October 23rd.

In mid-November you will write a concise status report so I can make sure the projects are on-track. I will also be available to meet with any groups who would like to discuss their project, request additional resources, or ask for advice.

You will also be required to present your project at a poster session, to be held on December 11th at 2:00pm in the Wozniak lounge.

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

The final report

You are expected to write a technical paper, in the style of a conference submission, on the research you have done. State the problem you're solving, motivate why it is an important or interesting problem, present your research thoroughly and clearly, compare to any related work that may exist, summarize your research contributions, and draw whatever conclusions may be appropriate. There is no page limit (either minimum or maximum), and reports will be evaluated on technical content (not on length), but I expect most project reports will probably be between 7--15 pages long.

If you are not familiar with writing conference-style papers in computer science (or even if you are), the following resources may help:

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, Dec 18, before 9:00am.

If you submit electronically:

  1. It must be in a format which is easily readable on Unix platforms: that means HTML, Postscript, or PDF is fine (but not Microsoft Word).
  2. Place a link to the file on your project web page (see here for the list of project web pages), and send me email with the URL. I will send you confirmation of receipt.
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

Note: Some examples are very specific. Others are quite generic; for the generic suggestions, be sure to narrow down the topic substantially and propose something concrete and focused.

If you are interested in any of the project topics below, please talk to me about it; I can make some more concrete suggestions.

New attacks
Find new security weaknesses in any widely-deployed system.
Security auditing
Audit a widely-used and under-scrutinized open-source package that is security-critical. Report on your experiences and lessons. How would you re-structure/re-implement the system to make it more robust? What tools would have made your auditing task easier? See the security-audit mailing list to get started.
Tools for vulnerability detection
Study ways to build tools to help automate the process of reviewing security-critical source code. Can you use runtime testing, static analysis, model checking, formal verification, or other techniques to detect any interesting classes of common security holes? I can give you some concrete ideas to get you started, if this interests you.
Timing attacks on encrypted telnet sessions
Explore whether it is possible to mount timing attacks on encrypted telnet sessions, by noting that you typically can get inter-keystroke timings from packet timings (since each keypress event is typically recorded in a separate encrypted packet). inter-keystroke timings, is it possible to recover some information about what the user has typed despite the fact that the connection is encrypted?
Evading intrusion detection
Study the difficulty of evading host-based intrusion detection, in the spirit of the ENIDS and Bro papers (which showed general techniques for evading network-based intrusion detection). Propose ways to strengthen host-based intrusion detection systems, or suggest a way to quantify their resistance against your evasion attacks.
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? This is a cryptographic design problem.
Formal modelling of security systems
Build a formal model of some aspect of a security system, and rigorously evaluate its properties. For instance, you might focus on the uid, euid, and other userid's associated with each process in some Unix operating system, and model how the various transactions can affect this process state. You could build a formal model of actual behavior by working from the OS source code or by exhaustively testing the possibilities. Then you might build a formal model of intended behavior (e.g., by working from the Posix specification) and check whether the specification matches the verification. Or you might build a second model from a second operating system, compare where their behavior differs, and study whether this has any consequences for how to write portable security code. Such models might also be useful for intrusion detection as well.
Passive OS fingerprinting
An OS fingerprinting tool, such as queso or nmap, can usually identify the OS running on a remote host by sending it various probes and analyzing the form of the responses. (e.g., checking which TCP options it accepts; what default values does it set in the TCP header; and other features which identify the TCP/IP stack on the remote machine and thus its OS) Can you build a passive tool that works simply by eavesdropping on existing connections and deducing the OS of each endpoint of those connections?
Secure coding
Improve (somehow) the state of the art in coding of security-critical projects. You might explore the relevance of various techniques from software engineering or programming languages, for instance.
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.
Sandboxing untrusted code
We saw in class a number of mechanisms for building a sandbox to prevent untrusted code from affecting the rest of the system in any way. This is a useful primitive, but in practice we often want to allow some amount of controlled sharing or limited interaction. You might study how to securely allow this limited interaction in some application context of interest. For instance, active networks or extensible operating systems might provide an interesting source of problems.
Inlined reference monitors
Proof-carrying code takes a reference monitor (expressing some security policy) and injects it into the program during compilation, in integrated; 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. Can we build a more lightweight implementation of this functionality by, e.g., using the mprotect() system call to emulate user-level call gates? (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.)
Enforcing resource bounds on malicious code
Can we use proof-carrying code techniques to ensure that malicious code never exceeds a fixed resource bound? For instance, we might insist that it terminate within a given number of clock cycles; we could insert checks to a global timer whereever we cannot prove a satisfactory upper bound on the running time of the program, and omit the checks in regions (e.g., acyclic control-flow graphs) where we can verify statically that the time bound will not be exceeded.
Security of peer-to-peer systems
Peer-to-peer systems (e.g., Gnutella) have been a hot topic recently. You might study the security challenges inherent in peer-to-peer systems, either by proposing techniques for building secure peer-to-peer systems, or by analyzing an existing peer-to-peer system.
Information retrieval for audit logs
Suppose you have audit logs of, say, network events. How would you design a search engine so you could retrieve security-relevant events after the fact? What network events would you want to have logged, and in what format? For instance, imagine tomorrow CERT announces a new attack, and CS admins discover that one of their machines has been broken into. It would be nice if we could just search all audit logs over the past year to see if any other CS machines had been broken into using the same attack. What can you do in this area?
Distributed firewalls
Imagine taking the enforcement mechanism found on a firewall and replicating it on all inside machines. (This would require installation of new software on all internal machines, but suppose we can handle that administrative burden.) How do we maintain centralized control over security policy? How do we specify policies? How do we maximize assurance in such an environment? How do we handle multi-organization scenarios, where a machine is a member of multiple organizations and thus multiple parties would like to add security restrictions?
Virtual machines for security
Recently, software has become available to implement a virtual machine for modern operating systems (e.g., Windows). This seems to provide a powerful mechanism for executing dangerous actions in an isolated environment. Does this idea work, and if so, how can we best take advantage of virtual machine techniques? Is there any way to structure the the virtual machine implementation to isolate the security-critical functionality and thereby make the TCB simpler and easier-to-verify?
Side channel attacks meet mobile code
Typically the easiest way to break a cryptosystem is not by directly attacking the mathematics but by "cheating" (e.g., bypassing the crypto entirely), and one way to do this is to use side channel attacks. Java and other forms of mobile code give attackers a convenient way to run code on targetted machines, which might give the attacker a way to measure timings or memory operations by observing scheduling or swapping decisions. The goal of the project would be to investigate whether it is possible to mount side channel attacks within the constraints imposed by Java or some other widely-deployed mobile code system.
Verifiable distributed computation
The Internet is a vast resource of idle machines; we might like to harness these spare CPU cycles by offloading our lengthy computations to other computers. But in any such distributed setting, how do we know that the result that comes back is the correct one we wanted? Careful engineering combined with some recently-proposed cryptographic techniques might go a long way here in solving some cases of interest.