CS513 Project

CS513 students 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.

• Group Formation. Each project is undertaken by a group comprising 1 to 4 students. Form your group from students who are registered in CS513 this semester. You should consult only with your group members and the course staff in formulating, specifying, designing, and building your project.

  Profit from our past experience: one-person groups almost always produce weaker projects (and get the lowest grades), because all the work falls to a single person and because discussing ideas with others, a powerful tool, is not available to a single-person group. Moreover, after graduation you will likely work in a group. So working in a group now will help you hone skills needed to be effective in the workplace. Single-person groups are thus strongly discouraged.

  MEng students can use their CS513 project as the basis for the required MEng project. If this is your intention, then your group must all be MEng students who are all electing to use the project in this manner. Your group will then not only be expected to satisfy the project requirements outlined below but is also be expected to:

  1. Implement some additional functionality, as agreed upon between your group and the course staff.
  2. Provide a written "project report" for the entire project. This report should document the problem solved, design alternatives, a rationale for design selected, the implementation, the testing strategy employed, and give instructions for both installation and use.
  Plan to start these additional tasks after this semester ends and complete them early in the spring semester.

• Choice of Tools. Select a programming environment, programming language, and target platform that makes sense for your project. Our evaluation of what you build will be based, in part, on your choice of tools (and our ability to understand your source code, so don't pick anything too obscure). Program in C or C++, for example, and we will be interested in how you have ensured that buffer overflows and other vulnerabilities that frequent C programs have been eliminated. Java and C# are usually safe choices.

Deliverables for Each Phase

All submissions should be made through CMS. CMS provides a way for you to define your group. Be advised that each group member must take an action in creating a group, and your group cannot submit anything through CMS until the group has been created.

Grading. The project accounts for 50% of the CS513 final course grade, allocated as follows among the three phases: Phase I (10%), Phase II (15%), Phase III (25%).

Phase I: Problem and Group Definition [Due 9/12 (10:10am)]

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/3 (10:10am)]

Submit two files, as follows.

• revPhase1.doc: Create this file by adding comments to the Phase I submission we annotated and returned. 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 [preferably] a separate color) explaining how you intend to 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: Implement, Test, and Document [Due 11/19 (10:10am)]

Sign-up. Decide where (CSUG or MEng Lab) you want to conduct your final presentation and when. Then, schedule a Presentation/Demo meeting slot for the week of Nov 26. Use the sign-up sheet posted on the door of Upson 4115 to schedule your meeting. The sign-up sheet will be available, starting Wednesday, Nov 14, 11:30am.
Your group must sign-up before Monday, Nov 19, 9:00am.

Preparing for the Presentation/Demo Meeting. The Presentation/Demo meeting encompasses an hour, 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 complete enough so that anyone 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 [30 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.)
• A CD containing
  • the ppt file used for your Presentation/Demo meeting,
  • all the code and other files for your system and demo, and
  • 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 goals, implementation, and presentation [15%]

• Electronic Voting Booth. Build software to replace the systems currently used in U.S. voting booths. Assume that an IBM PC along with I/O devices you stipulate will be installed in each voting booth and that all of these PCs can use the Internet to communicate with a central server, where vote totals are accumulated. Physical access to a voting booth is controlled by a human guard, who will check the credentials (name and address) of the person desiring access; physical access to the central server is limited to trusted insiders but the running software is controlled by an operator interface that should be accessible over the network (presumably by authorized administrators only).

• Secure Bulletin Board. Some web sites (e.g. http://en.wikipedia.org/wiki/Main_page allow clients to edit content. A hostile client can thus corrupt the web site. Devise and implement an authorization system for such a web site. It should allow clients to earn the right to read or write content, and these rights should propagate in a sensible way. Your scheme should minimize the amount of intervention required by humans.

• Verifiable Auction Site. An ebay bidder has no way of knowing whether he is bidding against a real customer or the ebay system itself is generating higher counter-bids in an effort to increase the final selling price. Thus, ebay bidders are forced to trust the ebay website. An alternative would be for the ebay website to implement some sort of verifiable auction protocol, so that a bidder can ascertain that each bid comes from an actual auction participant even though a bidder might not be able to learn the exact identity of that competitor. Two possible designs seem plausible---either (i) the validity of each bid can be checked during the auction (a so-called "on-line" scheme) or else (ii) the validity of each bid can be checked after the auction has terminated (a so-called "off-line" scheme). Choose one of these schemes and build such a site.

• Secure Web Search. Design a crawler and indexer for a corporate web site that respects access control restrictions. Access rights would be associated with pages and users, and search requests would only yield web pages that user can view. No user should be able to run queries whose results allow that user to infer the existence or content of pages that user is not allowed to access directly.

• Distributed Battleship Game. Implement the game of battleship in a way that does not require a central server to manage the board or other game state. Each player runs a separate computer, which accepts moves and disseminates then to other player's computer. Users must somehow be prevented from running non-standard clients and cheating.

• Rights Management System. A rights management systems enforces policies that govern access to digital objects. In such a system, functionality is provided to define policies, bind a policy to an object, and perform operations involving that object (but only if those operations comply with the policy). Policies might constrain read/ or write operations, but they also might be considerably richer prescribing, for example, that operations be performed in a certain order (so-called work-flow management) or that a certain operation be performed only a limited number of times (so-called digital rights management also known as DRM). You should provide middleware that programmers can use to access objects that are controlled by the rights management system, example programs (a viewer, an editor, and perhaps others) to create and update such objects, and define a means to bind policies to objects. Your software should be usable in a distributed system, where objects are communicated and used between different hosts.