EE515/IS523: Security 101: Think Like an Adversary


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/25/2019, 11:59 PM
    • Full Proposal: 10/9/2019, 11:59 PM
    • Midterm Report: 11/4/2019 , 11:59 PM 11/10/2019, 11:59 PM
    • Final Report: 12/11/2019, 11:59 PM

  • 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 3 days, 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 Oct 24?  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 tar-gzipped directory including any deliverables (such as implementation source code) mentioned in the proposal, and a 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 (23 %).  One member of each group should submit a tar gzipped directory which includes any "deliverables" and 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.