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 the quality of their research
in 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:
- 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.
- Analysis.  Analysis projects might, for example, study
some previously-proposed implementation technique,
existing system, or class of systems;
evaluate its security properties; find flaws, or strengths, in it;
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.
You're welcome to pick a topic that is connected to your
current research: for instance, if your primary research interest
is in digital libraries, you would be welcome to do a class project
on some aspect of security, cryptography, or privacy in digital libraries.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.
You're welcome to come discuss possible project ideas with me,
if you like.  I'm happy to make myself available to discuss projects.
A final suggestion: Aim high!  
The top projects could lead to publication.
In past years, the best two or three projects
have consistently led to publications.
The process
You will write a concise (approximately 1 page)
project proposal.  It should have three sections:
- The problem you will be solving, and any other
relevant information.
- How you will evaluate your work, at the end of the project.
(Performance measurements?  Security analysis?  Usability evaluation?
Simulations?  Analytic results?  Something else?)  This can be brief.
- Related work.
(You should study previously published papers on the subject,
to understand what has been done before and make sure that what you're
proposing to do hasn't been done before.  Then, briefly summarize the ones
that are closest to your work in your project proposal.)
The project proposal is due Friday October 30.
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,
their email addresses, title of your project, and the project proposal.
Then just email the URL for your project web page to
daw@cs.berkeley.edu
by October 30.
In mid-November I might ask you to write a concise status report
so I can make sure the projects are on-track.
I am always available to meet with any groups who would
like to discuss their project, request additional resources, or
ask for advice.
The poster session was held on Friday, December 11, 1-3pm,
on the 6th floor.
Finally, the project report
is due on Thursday Dec 17th at 11:59pm.
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.
If you submit electronically:
- Please use a format which is easily readable on Unix platforms:
PDF, Postscript, or HTML is fine.
- Place a link to the file on your project web page
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 -- 733 Soda).Example ideas for project topics
If you are interested in any of the project topics below,
feel free to talk to me about it; I may be able to make some
more concrete suggestions.
Analysis and attacks
- Security analysis of HTML sanitization libraries
    
- There are many open-source libraries available that aim
    to sanitize HTML (e.g., for RSS feeds).  Following up on HW1 and
    HW2, do a thorough security analysis of a suite of sanitization
    libraries.  What lessons did you find?
- Analysis of OpenSSH
    
- Do a security review of the OpenSSH privilege separation
    architecture.  Assuming there is some way to compromise the slave,
    how effective is OpenSSH at containing the damage that can be
    done by a malicious slave?  What damage could a malicious slave
    do?  How could the architecture/implementation be improved?
- Security auditing
    
- Evaluate the security of some widely-used or
    under-scrutinized open-source package.
    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?
    How effective are existing tools?
- Security review of published schemes
    
- Pick any recently published paper that proposes a new security
    mechanism or scheme.  Ask the authors for the code.  Perform a careful
    security review of the paper's scheme; does it meet the claims
    made for it?  To find recent papers, you could peruse recent proceedings
    of Usenix Security, IEEE Security & Privacy, ACM CCS, ISOC Network
    and Distributed System Security, or other security-related conferences.
Web security
- Defending legacy web apps
    
- Recent work has studied how to protect legacy web applications
    against authentication/authorization bypass attacks.
    A system called
    CLAMP
    has pioneered a fascinating approach for retrofitting defenses
    onto a legacy system, based upon ensuring that web application
    code can only access those parts of the database that should be
    accessible to the current logged-in user.
    However, CLAMP introduces a significant performance overhead,
    due to its use of virtual machines.
    Can you make these ideas perform and scale better, perhaps by
    using some other mechanism for isolation?
    Perhaps SELinux, OS process isolation, or some sandboxing scheme,
    instead of virtual machines?
- Safe-by-default web frameworks
    
- Recently, several web frameworks have started to include
    features intended to ensure that web applications built using that
    framework will be secure-by-default, at least against a class
    of security vulnerabilities.
    In particular,
    Rails,
    Grails,
    and Django 1.0 include some defenses against cross-site scripting
    and/or SQL injection.
    Systematically analyze the security of these frameworks.
    They tend to use a one-size-fits-all escaping function, which escapes
    all HTML content in the same way, no matter where in the HTML
    document it will be used (as text, an attribute value, a URL, etc.).
    You could study whether this is sufficient to be secure.
    Under what conditions is a web application built in each framework
    guaranteed to be free of cross-site scripting vulnerabilities?
    SQL injection vulnerabilities?  other vulnerabilities?
    Can you build a static or dynamic analysis tool to verify whether
    these conditions have been met, for a particular web application?
    Could you extend the framework to ensure web apps are safe-by-default
    against a broader class of security holes as well?
    What are the primary barriers to adoption of these mechanisms,
    for users of earlier versions of Rails/Grails/Django?
    Can you build tools to help migrate code written before the advent
    of these mechanisms to the new safe-by-default version of the framework?
- Taint tracking for Javascript
    
- Can you build efficient taint-tracking mechanisms for
    Javascript, by monkey-patching Javascript prototypical objects
    (e.g., the String class)?  What is the performance overhead?
    Can this be used to detect client-side cross-site scripting
    and other attacks on the client part of AJAX web applications?
    Can it be used to retrofit legacy web apps with defenses against
    client-side XSS?
- Web frameworks
    
- There are many frameworks and libraries out there
    for building web services (especially for Java).  Pick a handful
    and analyze them in detail.  Do they protect against common types
    of web vulnerabilities?  Compare them: which would be the best
    choice, for a project where security is important?
- Key management for SSL
    
- Today, one of the barriers to deploying SSL on small sites
    is the cost of buying a SSL certificate; and there are questions
    about whether these certificates add much value anyway (as the
    CAs don't always do a lot of verification).  An alternate model
    might be to use a SSH-like key management paradigm (sometimes
    called Key Continuity Management) -- but it's not clear how one
    could make that work well in practice, on the web.  You could take
    a look at possible schemes for this.
Software security
- Evaluation of tools
    
- There are now a number of static and dynamic analysis tools
    for finding security vulnerabilities and reliability bugs in programs,
    including
    Coverity,
    Klee,
    CREST,
    BuzzFuzz,
    SmartFuzz, and
    zzuf.
    Devise and carry out a set of experiments to
    evaluate their effectiveness and probe their relative
    strengths and weaknesses.
    Can you characterize their effectiveness quantitatively?
- Inferring security annotations for C/C++ programs
    
- Microsoft has proposed
    SAL,
    a set of annotations for C and C++
    code intended to help avoid buffer overrun and similar vulnerabilities:
    the programmer annotates their code with information about buffer
    lengths and the like, and a static analysis tool checks those
    annotations to detect possible bugs.  See also
    Deputy, an
    open-source system from Berkeley with similar goals.
    Writing these annotations can get a bit tedious.
    Can you design a dynamic analysis tool that observes code as it
    runs and infers SAL/Deputy annotations from how the code is used?
    For instance, if you run the program on 1000 inputs, and in every
    case, function f() is only called with null-terminated strings, you
    might infer a SAL/Deputy annotating asserting that the argument to
    f() is always null-terminated.
    (See also Daikon,
    though Daikon is a general-purpose tool; you can probably do a lot
    better by focusing specifically on the kinds of properties that
    SAL/Deputy are designed for.)
    Tools like Valgrind, CIL, ltrace, etc. could be a good building
    block for this project.
- Avoiding integer overflow vulnerabilities in Java
    
- Modern type-safe languages like Java improve on C/C++ by
    eliminating many classes of vulnerabilities that have plagued C/C++
    programs, but it does not eliminate integer overflow and integer
    casting vulnerabilities.
    One way to write Java code that is free of integer overflow bugs
    is to use java.lang.BigInteger (infinite-precision integers) instead
    of int.  However, this introduces a notational burden and
    makes code less readable: e.g., instead of writing x*(y+z) - 2, the
    programmer must write x.times(y.plus(z)).minus(new BigInteger(2)).
    Can you come up with an extension to Java that eliminates this
    notational burden?  For instance, you might build a tool that performs
    source-to-source translation to transform the former short version
    into the latter long version before compilation, allowing programmers
    to use the ordinary binary operators with BigIntegers.
- Privilege separation
    
- Pick an interesting security-critical application that is currently
    implemented monolithically.  Investigate how to apply privilege
    separation techniques to reduce the size of the TCB.  Can you
    implement your new design and evaluate its effectiveness?  If you
    were designing the application from scratch, how would you design it
    to maximize its security?  Any network client or server could be
    a good candidate for investigation.
- Software verification tools for security
    
- Researchers have recently made dramatic improvements in tools
    for software verification.  See, e.g.,
    ESC/Java2
    and JML
    (verification tools for Java)
    and Spec#
    (a verification tool for C#).
    These tools allow programmers to verify properties, such as that
    the program will never throw a NullPointerException,
    ArrayIndexBoundsOutofBoundsException, or other runtime exception,
    and that the program will never use uninitialized memory.
    Since unexpected exceptions can cause surprising behavior (which is
    dangerous in a security-critical program), these could be useful for
    secure programming.
    You might study how useful and expensive these are for security.
    For instance, pick one or two security-critical applications written
    in Java or C# and attempt to verify that they satisfy some useful
    property (e.g., free of runtime exceptions).  How many annotations
    did you have to add?  How much time or effort did it take?  Did the
    effort reveal any vulnerabilities?  Or, you might try to see if you
    can express any of the security requirements for those applications
    into the JML/Spec# modelling language and see whether it is possible
    to verify that those requirements are met by the code.  Are the
    JML/Spec# annotation languages rich enough to specify important security
    policies?  If not, what kinds of extensions would be useful for security?
    Are the existing tools powerful enough to verify that code meets those
    requirements?
- Virtual machines for security
    
- Virtual machines (e.g., VMWare, Xen, etc.) seem to
    provide a powerful mechanism for executing dangerous actions in an
    isolated environment.  How secure are existing commercial virtual
    machines?  How hard would
    it be for a malicious guest application to defeat the VM and harm the
    host OS?  (For instance, an interesting project would be to look
    at a few commercial or open source VMs and try to see if you can
    break isolation.)
    How would you design a high-assurance VM to be sure that
    isolation could not be compromised and to make it as easy as possible
    to verify that these security goals have been met?
    
Other
- Automated signature verification
    
- Banks, election administrators, and others use automated
    tools to verify your (ink) signature, to check that your signature
    matches the one they have on file.
    It would be interesting to survey the field and analyze the security
    of the state-of-the-art algorithms for this; how hard is it to forge
    a signature that will pass the automated verification process?
    Alternatively, you could study new algorithms for signature
    verification that are hard to fool.