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
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.
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
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 firstname.lastname@example.org ,
and I can try to help you rendezvous with other people who have
Also, here is a list of people who are looking for project
partners and have requested I add their name here:
Send email to me
if you'd like to be on this list.
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
Some other ideas are also listed in Bellovin's paper
on the Internet.
- 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
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
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
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
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
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
(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.