CSE608 Fall 2005. Advanced Computer Security

Focus: Software Security

Projects

The goal of this course project is to give you the opportunity to explore some area of computer security in detail, to practice conducting research in computer security, and, with any luck, to produce a publishable paper on your research.

The first step in conducting research is to identify an open problem in computer security that you think you may be able to make progress on. If you have a high-level idea of how you will attempt to solve that problem, that's even better. While brainstorming about the problem you're interested in, you should start forming a project team of 2-3 students with similar interests.

You should submit a project proposal to me before you get too deeply comitted to one idea. Feel free to come to my office hours and discuss project ideas with me at any time.

The main artifact you should produce in this project is a 12-16 page conference-style paper describing the problem, your proposed solution, and any experiments or theorems you have to support your solution. If you end up with a "negative result", i.e. you try out a seemingly good idea but it just doesn't work, you should research why the idea doesn't work and write that up in your paper. For guidance on style and presentation, feel free to discuss with me or study any of the papers we'll read in class.

You will also make a 20-minute conference-style presentation in class about your project. When planning your presentation, be careful to consider the level of your audience: informed computer scientists who know a lot about software security but very little about your particular problem. Try to cover the main ideas from your project rather than the technical details.

Since this class spans the fields of computer security and programming languages, your project may be on any topic in either of those fields. It does not have to be in the area of software security. You may combine this project with another class project, assuming the other professor agrees.

Deadlines

• Nov. 1 Project proposals due. Write a one-page summary of the problem you are trying to solve and the approach you intend to follow to solve it.
• Nov. 3 Team meeting. Each team should have a 45 minute meeting with me to discuss your project proposal on this day. Email me to set up an appointment. I can meet anytime except 3:50-5:10.
• Nov. 29 Progress report. Each team should have a 45 minute meeting with me to discuss progress and problems in your project. Email me to set up an appointment. I can meet anytime except 3:50-5:10.
• Dec. 13 Project presentations. Prepare a 20-minute conference-style presentation on your project for the last day of our class. Your projects will probably not be complete at the time of the presentation, but that's ok. Just describe the goals of your project, what you've accomplished so far, and what you intend to do to finish the project. You may elect one member of your team to give the presentation, or "tag-team" it.
• Dec. 20 Project papers due. Submit a 12-16 page conference-style paper to me on your project. You may submit your paper by emailing it to me as a PDF or Postscript file. The submission deadline is 23:59:59, Dec. 20, although I will accept revised submissions after the deadline.

Project Ideas

• Improve an existing security analysis tool. Many of the tools we have discussed in class are open-source. You can download CQual, MOPS, BLAST, CCured, or another tool of your choice and tinker with its internals. Each tool has its strengths and weaknesses. For example, for CQual, you might investigate ways to reduce its false-positive rate. For MOPS, you might look into adding support for automatically handling function pointers or signal handlers. CCured and BLAST may benefit most from performance improvements.
• Apply an existing tool to a new security problem. For example, you might be able to detect integer overflow bugs using type-qualifiers. Double-free bugs may be detectable using model-checking.
• Investigate using BLAST-like algorithms to track object state, as discussed in class.
• Investigate alternative termination conditions for the BLAST algorithm.
• Develop attack techniques to circumvent the protections described in this paper: Protecting Against Unexpected System Calls, Linn, et al.
• Compare several cryptographic filesystems based on the security properties they provide. What properties should they provide? Do they? If not, implement an efficient encrypted filesystem that does provide those security properties.