CS513 Project

CS513 students this semester are expected to participate in a group project that has non-trivial security content. There is some flexibility in what you do and how you do it. This note outlines what is expected and when.

Schedule of Deliverables

The project is divided into 3 phases. This division into phases provides well defined points for us to give you feedback (and facilitate mid-course adjustments in your group's effort). Here are details of what is expected for each phase.

All submissions should be made through CMS. CMS provides a way for you to define your group. Be advised that your group cannot submit anything through CMS until the group has been created. It is a good idea to create your group early.

Grading. This project effort accounts for 30% of the final course grade, allocated as follows among the three phases: Phase I (5%), Phase II (10%), Phase III (15%).

Phase I: Problem and Group Definition [Due 9/15 (11:59pm)]
Submit a typeset document (.doc or .txt are best, so that we can easily add comments in-line) of at most 4 sides long (11 point type, 8.5 x 11 inch pages) that includes the following information.
  • A name for the system to be built.
  • Members of the project group.
  • Explanation of what your system will do. (Note, significantly more detail is expected here than you will find in the Project Idea Suggestions at the end of this document.)
  • Explanation of what properties will hold if your system works correctly. This is the place to talk about what kinds of security is of consequence. Your Phase III grade will be determined, in part, by the extent to which your system involves consequential security properties and in part by the extent to which you succeed in implementing these properties.
  • Explanation of what technical areas you will study in order to identify protocols and techniques for your project. This section should contain specific references to sections of textbooks or other published scientific literature. (Here, the web does count as "published" scientific literature.)
  • Description of the programming language, program development environment, and target platform planned for your project.

We will assess the proposed effort, and if we believe it to have suitable scope and difficulty, then we will give a go-ahead for the next phase. If we deem the proposed system unusable as a CS513 course project then we will try to suggest modifications that would make it usable; you may then be required to resubmit a revised document.

Phase II: Functional Specification and Design Discussion [Due 10/14 (11:59pm)]
Submit two files, as follows.
  • revPhase1.doc: Create this file by adding comments to the Phase I submission that was returned with our annotations. Where appropriate, either add text to our comments or add text to the main body (in a way that is easily distinguished, either by using Track Changes or a separate color) explaining how you handle the concern. The result should be a document that can serve as a baseline for us to understand what it is that your Phase II Functional specification discusses. In a few cases, groups will have elected to switch and implement radically different projects. Here, you should include as an appendix to your original Phase I submission a new document (same length restrictions) that is what you would have originally submitted for this new project.

  • Phase2.doc: A typeset document (.doc is best, so that we can easily add comments in-line) at most 7 sides long (11 point type, 8.5 x 11 inch pages) that outlines the design you will build. Devote more space to what you think are the tricky parts, explaining what are the pitfalls and how you will avoid them. Include citations to sources of protocols and sketches (i.e., the sequence of messages sent, where you give which principal sends what information to which other principal for each message sent) of any protocols you design; also include descriptions of interfaces (at a level of detail suitable to convince the reader that your design is sensible). Think about this document as being a "term-project assignment handout". That is, we should be able to concatenate your Phase I submission (after it has been cleaned-up) and Phase II submission to obtain a document that could be distributed next year to CS513 and serve as the sole specification for their semester-long programming assignment handout. (The expected level of detail can be seen in electronic voting system.)

Phase III: Presentation and Demo [December 6-12]
Sign-up [December 1] Decide where (CSUG or MEng Lab) you want to conduct your final presentation and when. Then, schedule a Presentation/Demo meeting slot for Dec. 6, Dec. 8, or Dec. 11-12, using CMS. You must sign up by Dec. 1.

Preparing for the Presentation/Demo Meeting. The Presentation/Demo meeting will take 45 minutes, and will be structured as follows.

  • An uninterrupted presentation that one or more members of your group give using Powerpoint slides [10 minutes]. Plan to display the slides using the same computer screen that you use later to demo your system. Rehearse the presentation well---the time limit will be strictly enforced, and the quality of your presentation counts.

    Slides should contain short telegraphic phrases, figures, algorithms (in an easily understood pseudocode), and performance numbers. Use the Powerpoint "speakers notes" feature to amplify what appears on a slide. The "speakers notes" should be prose (i.e., sentences and paragraphs) that is sufficiently complete so that we can read them and understand the crux of the slide they accompany. What is said when presenting a slide and what is written in the "speakers notes" is unlikely to be the same---spoken language is less efficient and therefore requires repetition that written notes don't.

    Your presentation should: (i) remind us what your system does, (ii) discuss the "security content" of this effort, (iii) describe what (if any) design or implementation innovations were required to complete the project, (iv) explain why your design is a good one, and (v) explain why we should believe that your system is secure.

  • A demo of your system [8 minutes]. Make sure you have an easy way to transition from the Powerpoint presentation to your demo. The demo itself should show that your system works and should convey a sense of what functionality your system implements. A fancy GUI will not impress us; a robust system will impress us, since lack of robustness implies the presence of code vulnerabilities.

  • A question/answer session [10 minutes]. We ask; you answer. Anything about your system---functionality, design choices, related work---is fair game. Plan to convince us that you are truly the experts on subject matter concerning your system. Questions may be directed to any member of the group.

  • Evaluation of the source code with a TA [15 minutes]. Be prepared to help a TA take a "guided tour" of portions of your code that interest him. Code that you have written should be clearly identified so that it is quickly located and cannot be confused with other code that is used in your system. We will look over excerpts of your code to see whether your project is based on a clean design and was implemented using good software engineering practices (including secure coding practices). Projects containing code vulnerabilities will be severely penalized.

What to Submit. You need not submit anything until the start of your Presentation/Demo meeting. At that time, you should provide us with:

  • Two printed (either black and white or color is fine) copies of your power point presentation, where each page contains a slide image and associated speakers notes. (This is called "notes pages" on the Powerpoint Print menu.)
  • Submitted to CMS or included on a CD:
    • the ppt file used for your Presentation/Demo meeting,
    • all the code and other files for your system and demo, including a README file that explains how to install your system and how to run the demo.

Grading for Phase III. Your grade for Phase III will be computed as follows:

  • presentation content (slides and "speakers notes"), delivery and adhering to time limit [15%]
  • demo---does the demo and underlying system work [10%] and does it illustrate the security functionality [15%]
  • performance during the question/answer session [10%]
  • code and design review [20%]
  • how difficult an undertaking was this project [15%]
  • other subject factors about project goal, implementation, and presentation [15%]

Some Project Idea Suggestions

Here are some suggestions for projects. Don't feel compelled to choose one of these. In fact, we encourage you to devise your own project idea---reading this list might provide inspiration that leads to a project idea that excites you.