Comp 527: Final Project Ideas
up to final project page
A course similar to this one was done at U.C. Berkeley. You might
want to visit their final
project ideas page as well as the work
their students actually did.
Below are various ideas you might also consider.
Operating Systems
- Build ACLs
- Windows NT supports fairly complex access control lists, but only
very expensive ``secure'' versions of Unix have ACLs. Build support
for ACLs into the filesystem of a free Unix. How can your ACLs be
backward-compatible with traditional applications like rcs
that read and write the security bits? How should you handle
the sticky bits in traditional Unix? What about umasks?
- MLS
- Classified, secret, top-secret, and so forth. Building a complete
multilevel system for Unix is far too big for a final project, but there
are a number of interesting sub-problems you might consider.
- Add security labels to the file system and to users and build
the appropriate security checks into the kernel.
- Measure the bandwidth of various timing channels. This
could be anything from modulating the system load, the disk load,
the virtual memory load, or even the cache hit rate.
- Firewalls
- Add firewall-style support to an operating system. You could try
developing application-level gateways for several of the common
protocols. You could also look at building an efficient router.
Rather than just hacking away, you might also look at the
software engineering aspect and look at some kind of firewall
architecture that has inherent strengths against attacks on
any of its protocols.
- Replace Setuid
- Too many Unix tools are setuid root. Clark-Wilson recommends
having certain types of data files restricted to only being
accessible by certain programs. Do this for Unix.
Cryptography / Networking
- Login authentication
- Modern Unix systems support pluggable authentication modules
(PAM). Write a PAM that uses a smart card or a PalmPilot or some
other interesting technique.
- Transparent cryptography
- SSL can be added on an application-by-application basis, but it
does not happen for free. Add SSL (or equivalent) to the shared
library to make all networking calls encrypted. Find a way for
the client machine to interrogate the server machine to see if
it supports transparent encryption and gracefully fall back to
non-encrypted communication (or optionally fail, depending on
an environment variable).
- High performance ciphers
- How fast can you go? RC4 can theoretically be tuned to go
the speed of memcpy(3C). What if you wire together
gzip (or some other compression system) with an
encryption system? Can you go faster with the two systems
optimized together than running them separately? Compare
the performance of several different ciphers (either with
code you get from the net or from Schneier's book). Fine
tune the inner loop at the raw assembly level if you have to.
- One-time pad management
- Assume the worst case: all traditional cryptosystems have been
broken, P=NP, and evil attackers are actively in control of
every network. This means the only remaining cryptosystem is
the one-time pad. How would you do the equivalent of digital
signatures? How would you do the equivalent of public key
infrastructure? How would you securely exchange pad bits?
Work out the models on paper and write a program that
implements them.
- TCP/IP protocol stuff
- Generic TCP/IP is vulnerable to all kinds of attacks.
Design and implement other protocols that might be stronger,
but still preserve the efficiency of TCP/IP.
For example, an attacker can emit a RST packet which closes the connection. That's a denial-of-service attack. Can you
build an efficient networking protocol that's resistant to
this attack? What about session hijacking?
Language Security
- Security through code rewriting
- Many researchers are adding new security semantics to Java
these days by rewriting Java bytecode. You can use this trick
to force the program to observe some behaviors. In the
case of Java, a number of nice libraries are available that make
it relatively easy to manipulate Java bytecode. For something
like Scheme, it's already pretty easy to manipulate the code.
Pick a class of security policies you're interested in and
investigate adding those semantics to Java, Scheme, or whatever.
- Malicious code detection
- Can you parse a program and statically detect if it will misbehave?
Anti-virus programs usually use a long list of patterns that they
try to match in the software. Build something similar.
- Agent systems
- In agent systems, multiple agents are running together in the
same language runtime and interacting with each other. Example
agent systems include MUDs (multi-user dungeons) and stock market
trading systems. One possible project is working on resource
management and security issues here (to control misbehaving
agents). Another class of projects is to build an agent system
that take advantage of somebody else's mechanisms. Ariel Backenroth,
one of the Comp527 students this semester, is working on a stock market
simulator that has some fairly complex security needs. You could
make a project proposal with him on that.
PDA / Mobile computing platforms
Palm Pilots, cel phones, and other gizmos that have (a) CPUs,
(b) screens, (c) user input, and (d) antennas are becoming
increasingly ubiquitous as their prices and weight drop and
their functionality increases. If they were truly everywhere,
you could consider building systems around this.
- E-cash systems
- Beam money to your friends. Beam money to the Coke machine.
Use cryptography to protect the data, of course, but you
also need to worry about double-spending, non-repudiation,
and all that. Your job gets easier because the phones are
always on-line, but you should be able to have one of the
parties be offline (e.g., the Coke machine), and have everything
else still be secure.
Software Engineering for Security
- Security lint
- In the same way that you might detect malicious code, you can detect
well-known bad programming practices. This might cover everything
from C buffer overflow conditions to common misunderstandings of
Unix system calls. Mudge (at L0pht.com) has a list of over 100
common bad practices. Build a C source analyzer that can detect
these practices. (See Dave Wagner's paper, as well.)
- Fault injection
- Software is pretty fragile stuff. If you deliberately break it
a little bit, or if you deliberately feed it unusual input, you
can often coerce software to fail. You could investigate building
a general-purpose tool, or you could focus on specific classes
of programs, such as network servers (i.e., e-mail, Web, Usenet).
Privacy
People often have secrets. While they're straightward to protect on
computers (i.e., mark a file as readable only by its owner), things
get much more difficult on the net.
- Web privacy
- Cookies can be used to track you. URLs with funny extensions can
be used to track you. Web pages load images from third parties
like DoubleClick. They're not just advertisements, they're tracking
you as well. There are many opportunities to build projects here.
You could build Web proxies that do anything from ad filtering,
like WebWasher to
ad jamming (feeding back bogus cookie information). You could
also build systems where privacy emerges as a property of a
lot of people surfing at the same time, such as Crowds. On the flip side,
you could analyze systems like these and try to systematically
break them.
- E-mail anonymity
- Most of the anonymous e-mail systems out there can be described
as follows: you send your e-mail into this cloud and later on an e-mail
pops out of the cloud at your destination. A sufficiently determined
snooper can watch the end-points and figure out who wrote what. Even
if encryption is being used, traffic analysis can detect people who
are conversing with each other. One possible project is to use Usenet
as a transmission media. Post an encrypted message that means nothing
to anybody but the intended receiver. Among other things, you'd have
to deal with scalability problems. Conversely, you could build
some traffic analysis tools and try to break existing anonymity
systems.
Applications
- Auditing infrastructure
- The DIDS paper discussed a networked audit facility
for intrusion detection. But what happens if the centralized
audit machine is successfully attacked? Build a truly decentralized
system where, even if some number of systems go down, you still
have a complete record of what happened.
- Spam filtering
- Write a classification system that can distinguish spam from normal mail.
I have several years of spam saved that you can use to train your
system. Another related project would be writing a Web proxy
server that filters out advertisements.
- Chat systems
- You're talking to somebody on the chat server today. Tomorrow,
you get an e-mail from somebody claiming they're the same person.
Build a way for people who don't know each other to be able to
identify each other later with some kind of cryptographically
strong authentication.
- Calendaring systems
- I want to schedule a meeting with people from different companies.
The computer should be able to look at my free time and the free
time of everybody else and come up with the best time we can all
meet. Can you do this without me being able to read the full
calendars of everybody else? Can you do it without a central
calendar server (i.e., using some cryptographic primitives to
arrive at a time we can all meet without anyone revealing too
much of their private schedule information)?
Dan Wallach,
CS Department,
Rice University
Last modified: Fri Jan 28 00:47:43 CST 2000