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 quality of the project is expected to be of similar calibre to any project in a 3-unit systems class.

You may work in groups of 2--3, or you may work alone. The expectations will be adjusted according to the number of people in the group.

A list of possible topics can be found below, but don't feel limited to those suggestions. Pick a problem that you are interested in. Aim high! The best projects could well lead to publications.

The process

You will write a concise (1--2 page) project proposal that should clearly state the problem you will be solving, your plan of attack (including milestones and dates), and any resources you might need from us. The project proposal is due Wed 7 October, so you should get started on finding a topic, selecting partners, etc. now.

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 cs261-homeworks@joseph.cs.berkeley.edu by Wed 7 October.

We will provide feedback on your project proposal by scheduling a brief (10-minute) meeting with your group for the following week.

In early November you will write a concise status report so we can make sure the projects are on-track. We will also be available to meet with any groups who would like to discuss their project, request additional resources, or ask for advice; meeting with us is entirely optional.

You will also be required to present your project at a poster session, which we expect to schedule for sometime during the last week of classes.

Finally, a project report is due by 9:00am Monday 14 December (no exceptions); see here for instructions on the final writeup.

Finding project partners

If you are looking for a project partner, send email to me at daw@cs.berkeley.edu , and I can try to help you rendezvous with other people who have emailed me.

Also, here is a list of people who are looking for project partners and have requested I add their name here:

• Ron Avnur ronathan@cs

Other information

If you are taking a second project class this semester (such as CS262), you may select your projects to overlap. However, it is still two projects, and you will need to pass our project review, so don't think you can get off without any extra work. Think of this as requiring more work than just one project, but less than two.

Example project topics

New attacks

Find new security weaknesses in any widely-deployed system.

Analysis of Kerberos

Analyze the security of Kerberos 5. Are there any significant weaknesses? (Or look at K4; but make sure you read the paper by Bellovin and Merritt first. Talk to David for more details.)

Pilot authentication

Build a secure authentication infrastructure for the Pilot. This infrastructure should support authenticated, encrypted HotSync, as well as support for use in physical access control (e.g. replace your cardkey with a Pilot) and possibly support for pay-per-use services (e.g. buy a Coke from a soda machine with just your Pilot). Alternatively, you could build for the handheld device of your choice, instead of the Pilot. This could make an excellent project; talk to Ian for more details.

Countering techniques for eluding attack detection

Read Ptacek and Newsham's paper on eluding network intrusion detection, and develop practical countermeasures against the attacks they present. We have some ideas; see Ian and David. (One possible approach is to sanitize all traffic, reassembling fragments, re-ordering out-of-order packets, removing suspicious TCP options, and so on.)

Reactive attack detection systems

Study and implement active responses that an intrusion detection system might take after detecting an intrusion, e.g. RSTing a connection from a hacker trying to exploit a buffer overflow in sendmail, or countering SYN-flooding by ACK-ing the outstanding SYN packets. Ian has done some work on this for his master's thesis; talk to him or David for more information.

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. Given inter-keystroke timings, is it possible to recover some information about the keystrokes despite the fact that they are encrypted? Talk to David, who has some ideas on this subject.

Sniffer detection

Design and implement a tool to detect whether a remote machine is running a sniffer. (This might sound impossible at first, but there are some tricks which seem likely to work, based on statistical analysis of packet response times and so on.) If you do a good job and release your code, there is a good chance that a fair number of other folks might use it; and there is the possibility for a publication. Talk to David for more details if you are interested.

Traffic analysis of SSL-encrypted web browsing

Some people advocate using SSL to protect the privacy of their browsing session: in other words, to protect not just the content of the html data, but also to prevent eavesdroppers from being able to tell what web pages they are browsing. However, there is some theoretical reason to believe that statistical analysis of encrypted packets (analyzing the length of the encrypted GET request to learn the length of the URL visited, taking advantage of the temporal locality in web browsing, etc.) might be able to track the user's web browsing with excellent success rates. The problem is that noone has studied these ideas in detail or implemented the attack to gain practical experience with it, so the risk level is at present largely unknown; your job would be to fill that gap. See Section 3.2 of a paper on SSL by Wagner and Schneier for more details, or talk to David.

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. Make sure you narrow down the topic substantially and propose something concrete and focused.

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. If you would like to discuss this in more detail, you can talk to David.

Security for multicast groups

Currently multicast security is quite weak; but one could imagine it might be possible to improve the situation with a clever choice of cryptographic group membership protocols and solid engineering. Just be careful to narrow your focus; in full generality, this problem is known to be hard.

Research in Java security

Java security has been of intense interest recently, and research in this area might well net a publication. You might, for example, undertake a formal analysis of Java's type-safety guarantees. As another example, there is currently a gap in the literature: there is no good survey paper on pitfalls and principles for coding security-critical programs in Java, so a well-written paper that distills the lessons from all the flaws found in the past two years might be appropriate.

Research in privacy or anonymity

Design and implement or analyze techniques to improve the privacy protections of some important computing or communications resource. (As an example, you can see the project Ian and David did in their CS268 networking class here.)

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.)

Practical security for the CS department

Design and implement a security architecture to help protect the CS department against hostile attack. Consider policy issues (e.g.: who is responsible for responding to attacks?), social issues (e.g.: assuming academics will not tolerate any restrictions on their use of the network, what does that leave?), implementation issues (e.g.: will an intrusion detection system suffice?). Develop and present a concrete proposal; implement and deploy it; and most importantly, describe your experiences. An important part of the results would be a characterization of real attacks. (This would require getting started early, so that you can have the system running for a month or so.)

Eliminating cleartext passwords over CS networks

The goal of this project is to eliminate cleartext passwords, by replacing all network services which send passwords in the clear (e.g. telnet, rsh, rlogin, ftp) with encrypted versions. You will need to write their encrypted counterparts (potentially as a wrapper around existing services). Then, you will develop some techniques to detect any use of cleartext passwords and send a nastygram to the offending user (as well as raise an audit log event, etc.). A major deliverable is building it in a way which is acceptable enough to users to actually deploy on a large scale; e.g. deploying it on the Millenium cluster is probably doable. One difficult task with this topic will be to maximize the the research portion of the project---brute-force coding without research is not appropriate for a CS261 term project---so you might want to talk with us to make sure it is possible to keep the research component large enough.