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.

Group Formation. Each project is undertaken by a group comprising 1 to 4 students. Form your group from students who are registed in CS513 this semester. Consult only with your group members and the course staff in formulating, specifying, designing, and building your project.
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 electing to use the project in this manner.
Profit from our past experience: groups of size 1 almost universally underperform other groups, 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 an effective group member. Single-person groups are thus strongly discouraged.
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.

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.

Network Election. Build a service that runs at a set of client machines and enables a user at each of these machines to participate in an election (say for the next ACSU president). Do not employ a trusted third-party server, although you may use an "untrusted" third-party server.
Electronic Voting Booth. Build software to replace the systems currently used in U.S. voting booths. Assume that an IBM PC will be installed in each voting booth and that all of these PCs are connected to 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 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 propogate 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 competitior. 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 designs and build such a site.
Medical Records Database. Medical records typically involve a rich set of authorization requirements. These requirements have a natural description in terms of sets of (related) credentials. A credential defines a principal to be a doctor; a credential defines a doctor to be qualified in a certain specialty (hence gives access to certain records); a credential defines a doctor to be associated with a hospital; a credential associates a doctor with a given patient; and so on. Define a database system in which such authorization requirements can be stated and enforced. Your system should not implement a fixed policy, but rather should enable the policy to be specified, supporting a reasonably broad set of policies. You should also provide an example policy that is realistic. For example, an allergist probably doesn't need access to psychological records; an emergency room doctor does need access to the record for somebody who has not previously declared this physician an his/her doctor.
Secure P2P Storage. Start with an existing P2P storage system or build your own. Define some reasonable security properties that clients might expect to hold of this system. Provide a means so that clients can exert some measure of control on the security policies that govern their data (eg DAC or MAC or ...). Build the system and measure its performance.
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.
Anonymous Chat. Build a chat service in which a writer can decide whether (and which) readers and others monitoring the network can know who that writer is or even where in the network the writer is located. Be careful: To support 2-way conversation, the reader must somehow be able to send to the original writer (even though writer anonymity is being maintained).