Introduction
In this semester-long project, students will conduct research on network or systems security in teams of 1-2 people under the instructor's supervision. All teams and project topics must be approved by the instructor. The outcome of this project will be similar to conference-style paper of 10 pages maximum in which you build an argument for studying the open research problems that you advocate investigating — identify why this problem is important and why you believe it is solvable in the near future. The grade will be based on the novelty, depth, correctness, rigor of execution, clarity of presentation and effot.
Project Theme
"Thinking like an adversary" is critial to understand-- (1) the current security and privacy posture of a system; (2) how the existing security policies can be broken; and (3) how to enforce better and robust security policies. In this course, each project, therefore, should be aligned with the following theme: "security analysis of an existing system". The overarching goal of each project would be to design and implement a systematic security evaluation framework using program analysis, sofware testing, formal verfication and applied cryptography. Each project has following two parts and each part in turn has multiple milestones.
Part 1 - Reproducing an existing attack: As the first step of this project, you will reproduce a known attack on an existing system. Your task is to understand a known vulnerability and the corresponding attack, and write an original exploit. You should not contact the paper authors for the exploits or are not allowed to use any pre-packaged attack tools. You may, however, use any open-source and general purpose tools (e.g., gdb, wireshark, and packet sniffers) and scripts. Note that some vulnerabilities may have been fixed in newer sofware or libraries (e.g., Linux, TCP or TLS), so you may need to target an old version.
According to the course ethics policy, you must not test your attack against systems owned by other people. If you need to set up a victim.target, set up your own isolated device/machine/VM as the viticm. You can perform the attack only against your own device/machine.
You need to present a demo of this attack in which you will demonstrate--- (1) what is the vulenrability (2) how it can be exploited and how the attack works and (3) what are the implications of the attack. You will also present how you implemented the exploits, set up the attacks, and while doing so what technical challenges you run into.
Part 2: Based on the insights and lessons you have learned from reproducing a known attack on an existing system, you can extend your project in any of the following directions:
- Identify a new attack on the same system/protocol.
- Desgin a systematic security analysis framework using either formal verification, static or dynamic program analysis, fuzzing or other software testing techniques.
- Propose a verified or high-assurance defenses.
Project Topics
For identifying a known attack on an existing system/network, students are encouraged to check the last few years proceedings of IEEE Security and Privacy (Oakland), ACM CCS, NDSS and USENIX Security. You can also find many interesting attack papers in Blackhat or DEFCON.
- IEEE S&P (aka., Oakland): 2024 , 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016
- CCS: 2024 , 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016
- NDSS: 2024 , 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016
- Usenix Security: 2024 , 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016
- BlackHat: 2024 , 2023 , 2022 , 2021 , 2020
- DEFCON: 2024 , 2023 , 2022 , 2021 , 2020
- January 24: Project group information and project proposal due (meet the instructor to discuss the proposal).
- February 07: Part 1, Attack implementation.
- February 11 and 13: Part 1 Demo and presentation.
- February 18: Part 2, checkpoint 1: part 2 proposal due.
- Area
- Problem
- Solution Idea
- Methodology
- Results
- Take-away
Project Milestones
The following important dates and checkpoints are suject to changes as the semester progresses. All the changes will be notified through CANVAS. For the updated dates, please check the course calendar.
Project proposal
The proposal should not exceed 2 pages (including references). Please use this ACM template on Overleaf for project-related submissions.
What (Problem Statement): A name for the project. Articulate the problem statement and a clear description of your goal (e.g., proposing a new attack, proposing a new security analysis technique for a particular system, proposing a new defense, improving an existing attack/defense, etc.). For part 1 of this project, which particular attack(s) do you like to reproduce?
Why (Motivation for this project): Why should we be interested in the result of the project? A detailed view of motivation and most related work.
How (Design- or implementation-level details): What resources will you use to set up the attack for part 1? What do you plan for part 2? Is there an existing code-base of any related work? How will you evaluate your results, i.e., what will be your evaluation criteria (e.g., effectiveness, efficiency, performance overhead)?
Work load: If your team has two members, who will do what? You also need to provide your own milestone for part 1 in this proposal.
Final Report 1
You need to submit a minimum 8-page (without references) conference- or workshop-style paper. A typical conference/workshop paper has the following sections: Abstract, Introduction, Background, A High-level Design Overview, Design Details, Implementation, Evaluation, Discussion and Limitations, Related Work, and Conclusion and Future Work. To know what to write in each section, you may take a look at any paper (e.g., ATFuzzer) published in IEEE SP. CCS, NDSS, and Usenix Security conferences.
Find below the guideline for how to write the imporant sections of your paper.
Abstract: An Abstract should be relatively short: one paragraph, around 300 words. A wandering and off-topic abstract can confuse the reader. Consider the following template for writing an abstract (approximately one sentence per point):
Background: Provide background knowledge that is necessary to read and understand your paper. Do not provide the details that have never been used or referred to in your paper. E.g., you are writing a paper on X.509 certificate validation. To explain that you do not need to provide details about how public and private keys are generated or what is the length of the key.
Design Overview: In this section, first discuss the security assumptions, capabilities, and goals of the adversary and the trusted computing base. Then summarize what are the design challenges to your proposed solutions. Provide high-level intuitions for how to address those challenges. Finally, write a high-level overview of your proposed system/solution. You may use a diagram to summarize how your proposal. Without giving many details of each of the components in your system, you only mention the functionalities of each major component (i.e., the building block) of your system and the flow/interactions among those components. Use appropriate diagram/figure to provide such high-level details.
Design Details: Discuss in detail all the components of your proposed system. Discuss how you have handled the most critical corner cases of your design. These corner cases are important because this will allow someone expert in the subject area to completely realize your system design. Also, it will help others integrating your solution or replicating your system for future research. Always provide the intuitions for your solutions. Saying why you have done something is more important than how have done it. Note that you should still keep the discussion in this section at the conceptual level, i.e., not at the level of implementation details (e.g., length of the key used in our implementation was 128 or the encryption algorithm we chose are AES, which are too detail). The conceptual-level discussion abstracts away a lot of implementation-level details and presents the ideas in a way that can be instantiated (i.e., implemented) in different ways in your implementations.
Implementation Details: What software/hardware did you use/write/modify for your implementations? What does each module do in connection with the components of your system/solution and how those new modules or add-ons serve the purpose?
Evaluation: The evaluation section can be broadly broken down into two sub-sections: Evaluation setup and results.
Evaluation Setup: How did you set up the experiments for evaluation? What are the evaluation metrics? Make sure the metrics answer the research questions. What dataset (if any) have you used? Mention if you have any baseline results to compare with.
Evaluation results: Present the results with tables and graphs. If you have a different setup for different experiments, describe the experimental setup (e.g., hardware, software, and datasets used). For informal security analysis of your proposed defense/solution, provide justification (with text) on how your defense/solution can prevent the attacks that you mentioned in the threat model.
Related work: One of the most critical and often overlooked portions of a research project is a sufficient investigation of related work. For this milestone, you will write a related work section. A good related work section is not simply a laundry list of papers and corresponding summaries. Rather, a good related work tells a story of how technology and research have advanced to address problems and topics related to that considered by the paper. It is also critical to contrast your paper with the prior work, not just state what the prior work does. While your research is not yet complete, you should have enough of a grasp on the idea to contrast it with the prior work. You may also revise your related work for the final written paper. Finally, during your related work investigation, take note of how the related work section of those papers is written. Many papers have poorly written related work sections. Identify what makes a good and bad related work section.
Conclusion and Future Work: Don’t summarize your work here. That’s what the abstract was for. Instead provide some philosophical ruminations of your work and future possibilities, i.e., conclusions that you have arrived at as a result of your work.
1. [Some suggestions on writing paper have been partially adopted from Prof. William Enck's CSC705]↩