EE515: Security of Emerging Systems
Project Information
- Introduction
This course requires a group or individual project. Each project
should have some "attacking or analysis research" aspect in that your
aim should be to learn
something we couldn't learn just from reading a few papers. As an
example, you can implement an attack on a small scale system. Another
example
project would be to measure some security-relevant large scale
phenomenon that hasn't been measured before. We'll list some more
ideas below.
- Important dates:
- Pre-proposal: 9/29/2024, 11:59 PM
- Full Proposal: 10/20/2024, 11:59 PM (Modified on 10/07!)
- Midterm Report: 11/17/2024, 11:59 PM (Modified on 11/05!)
- Final Report: 12/23/2024, 11:59 PM (Modified on 12/20!)
- Group Size.
Groups should have 1 to 5 members. You have to find your own group
members.
- Grading and detailed schedule
- Pre-proposal (0 %, but required).
One member of each group should submit a one-page preproposal (named
"preproposal.pdf", and in PDF
format) with the following information:
- Who: All
members
of the proposed group, and a group or project name.
- What: A
clear
description of the problem you want to solve. There is no
requirement that this is the final problem, and it can be a somewhat
general area, for the preproposal.
- Why: Why
should we
be interested in the result of your project? What will it tell us
that we didn't know before, or enable us to do that we can't do
now? Why would it be useful to know or be able to do this?
- How: For the
full
proposal, you will need to give a detailed approach that you will
use. For the pre-proposal, you can list some papers and tools
that are relevant, and how and why you think they can help.
- Work distribution:
How many hours each individual member spent to do what
to prepare this proposal. (1 line for each member)
- Within a week, I will give each pre-proposal
some
feedback, possibly including a suggestion that you do something else.
- Full Proposal (5 %). One member
of each
group should submit a (maximum) three-page (in
10pt font, and two-column mode) full proposal (named "proposal.pdf" in
PDF format) that incorporates the feedback to give the following
information:
- Who:
(same as last time; perhaps if there was a merger a new project name)
- What:
A clear description of the exact problem you wish to solve. It is
important that based on the feedback you received, you pick the proper
scope of your project. Part of your final grade will be whether
you accomplish your goal; another part will be whether you accomplished
enough!
- Why:
A fairly detailed "motivation" and "related work" section - perhaps one
full column. Expand on the why
from your preproposal, and be sure to answer any questions raised in
your feedback.
- How:
A detailed account of your approach. What data will you
gather? How will you evaluate your results? Cite relevant
papers. What resources will you use?
- Management
plan: Who will do what? (This is especially important for
a larger group) You should try to give a realistic
timetable. This section should also propose your project
milestone: if everything goes according to schedule, what will be
accomplished by Midterm report? For example, if your project is to
make some measurements, you should probably have the tools and access
you need by that time. If your project is to analyze some data,
you should have the data and be able to parse it; if your project
is to build a tool you should have a fair amount of implementation
finished and tested.
- Work distribution:
How many hours each individual member spent to do what
to prepare this proposal. (1 line for each member)
- Midterm Report (5 %).
Exactly one member of each group should submit at least 6
page report ("report.pdf", in
10pt font, and two-column mode). Please make sure to start organizing
your
report following the final report guideline, while you can leave some
of the sections empty. Also, please use format following IEEE
guideline. Also do not forget to include the followings:
- If you are way ahead, what extra work will you
do?
- If you are behind, what difficulties did you
encounter?
- Do you have a plan for what work to drop, if
necessary?
- The report should give a brief summary of what
work was
completed by each member and how many hours the member spent.
- Presentation (5 %). Each group will give
an
in-class presentation of their work during the last week of class or
some other days. This could be a demo, or a formal
presentation. The entire group has responsibility to ensure the
best possible presentation. Presentation
evaluation criteria
- Final
Report (20 %). One member of each group should submit
a (minimum 10 pages, maximum 12 page, in
10pt font, and two-column mode) report ("report.pdf") on the
project. This report should be in the style of a scientific paper
(e.g. a conference paper) and should present the project's motivation,
approach, results, contribution, related work, and conclusions. A
separate file ("contrib.pdf") should summarize the hours spent, and
contributions of each group member.
- Project Ideas
You may choose any project that interests you as long as it satisfies
the basic requirements listed above and is related to cryptography in
some
way. To get an idea for what current research is like in
security, you should look through the last several proceedings from Oakland, Usenix Security, CCS, Crypto/Eurocrypt/Asiacrypt, and NDSS. However,
if you are having trouble coming up with ideas, here are a few examples:
- Implement or extend an attack on a security mechanism
described
in a recent paper. Succesfully deploy the attack against your own machine only.
Measure the performance of your attack.
- Investigate the security of some ad-hoc protocol.
For
example, many peer to peer protocols are not designed with security
features in mind. What should be the security goals? Do the
protocols meet them or are there attacks? (e.g., BitTorrent
claims to be "secure" in that it prevents freeloaders. Is there a
way to circumvent this mechanism? Can a torrent be attacked in
other ways, e.g. can we successfully co-opt a torrent, or perform
denial of service on a torrent at the protocol level? There are a lot
of open-source project and standard that lack security analysis.)
Note
- To get the full credit, the project should contain new
ideas
(new attack, new analysis, new implementation, new measurement), which
could be publishable in academic conferences (not necessarily top
notch).
- For example, simple implementation (e.g., re-do
previously
implemented system without new analysis, or no comparison) will not get
the full credit.
- For example, simple summary of papers will not get
full
credit. A survey paper should be written so that it conveys information
to the reader. When grading the paper we will ask ourselves whether
other students in the class might learn about the topic you choose by
reading your paper. The paper should contain original analysis of the
the papers you choose to cover, and ideally suggest directions for
future research on the topic.
- Misc: (Partially borrowed form HPCC Seminars webpage:
http://www-users.cs.umn.edu/~zhai/hpcc-seminars/)
How
to Give a Bad Talk by David Patterson
Mark
Hill's Oral Presentation Advices.
Robert
Drysdale's slides on Giving Technical Talks.
How
to read a paper? Not from our field, and the rules still apply.
Some
comments on how not to write a good paper.
|