CS5430 Project: Spring 2010

CS5430 students are expected to participate in a group project to build a system that has non-trivial security functionality, as follows:

• Phase I: Form a group of 2 - 4 students, and decide on what system you will build.
  Deliverable: [March 5 at 9am via CMS] A proposal describing your system.

• Phase II: Implement a system that satisfies the project description submitted in Phase I.
  Deliverable: [Week of April 26] A presentation to the course staff, showing your system in action and explaining what you have built and why. The course staff will use this opportunity to ask questions about your system and to review the system design and code.

MEng Project Option. MEng students may use their CS5430 project as the basis for the required MEng project. If this is your intention, then your group members 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 will 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.

Forming a Group. Groups of size 3 seem to work best. Groups smaller than 3 almost always produce lower-quality projects and, consequently, get lower grades; groups larger than 3 have difficulty coordinating among members---for example, finding times that all members can meet.

Beyond these pragmatics, working in groups offers other benefits:

• Discussing ideas with others is a powerful tool that far offsets the additional time required for coordination within a small group.

• Working in a group affords the opportunity for parallel development activities (although all members of your group are ultimately responsible for understanding all aspects of the system you build).

• Working in a group helps hone skills needed to be effective in the workplace (where groups are the norm) and impresses potential employers.

Project Choices

You have considerable flexibility in choosing what system to build. But because the course project is intended to provide an opportunity for you to use the material we cover in lectures, projects are acceptable only if the following elements are necessary for the system to fulfill its mission:

• Authentication. The system must authenticate its clients and/or allow its clients to authenticate the system (as appropriate for the mission).
  • If your system will be used by humans, then it must implement reasonable means to authenticate human users, including initial registration of users.
  • If your system will be used by executing programs, then it must implement authentication they require, including the means for generating and distributing any secrets or keys your solution employs.

• Authorization. The system must enforce some non-trivial authorization policy to control some subset of its operation. Some systems will require DAC; others will require MAC. Implement an access control mechanism that is appropriate and natural. Don't implement some simplified scheme that is awkward to manage at the expected scale.

• Confidentiality and/or Integrity. The system must involve data that resides in long-term storage or that is transmitted over a network, where that data must be kept confidential and/or have its integrity protected against corruption. You must use existing cryptographic building blocks, as implemented in available toolkits, to implement this functionality.

Your system should also involve other security functionality. Most systems, for example, will provide infrastructure for audit or other means of establishing accountability for actions. So the list above defines only a subset of the security functionality your project must implement. What is the rest of that functionality? Answering that question is one of the tasks in Phase 1.

Here are sketches for a few example systems that could involve all of the above required elements. Each sketch has important elements missing, as befits a sketch. Nevertheless, we are confident that each could be refined into an acceptable course project, and you should feel free to do so. But also feel free to invent your own project idea if none of the sketches is appealing.

• Grade Management System. This system allows student grades to be stored by graders and retrieved by students. Only certain users are allowed to display or alter certain information. For example, a student may not see the grades of other students and may not alter any grades; a TA may view all grades but alter the grades only of those assignments the TA has graded; the professor can view or alter any grade. Grade information is stored in a back-end file system.

• Networked Banking System. This system manages the bank accounts of customers for a multi-branch bank. Each branch has a separate computing system, connected to the Internet so communication with other branches is possible. The bank allows a customer to deposit funds in any account, to withdraw funds from an account for which the customer has privileges (provided sufficient funds are available), and to transfer funds from one account for which the customer has privileges to another (possibly at a different branch).

• Multi-player Game Service. This system might implement a game, where clients are players; or it might implement a virtual world, where clients control participants. There might or might not be a back-end server.

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). Java and C# are safe choices.

If you elect to program in C or C++ then we will be interested in how you ensure that buffer overflows and other vulnerabilities that frequent C programs have been eliminated. There are tools for analyzing C and C++ source code for vulnerabilities, but running these tools (if you can get access to them) is a non-trivial undertaking.

When building a system in industry, it is generally a good idea to extend existing components rather than build your own. For example, there are many 3rd-party systems and tools available for building web services (including web servers) and for implementing databases. But using these tools in CS5430 would preclude activities the project is supposed to cover. This is because, when you use a 3rd-party tool, you must: (i) accept somebody else's choices about what is useful security functionality and (ii) accept somebody else's assurance argument. We therefore impose the following rules about using code or systems written by others:

• Standard libraries (i.e., those part of the distribution) for Java and C# may be used. This includes various cryptographic routines, which you shouldn't be writing yourself anyway. It also includes GUI-builders that are distributed by Microsoft and Java.

• Operating systems installed on the CS department public machines may be used. This includes the networking infrastructures and file systems native to those operating systems.

• Web browsers may be used by humans accessing your system; this includes HTTP and HTTPS.

• You may not use existing web servers, database systems, or any other web services infrastructure.

Phase I Deliverables

The deliverable for this phase is a relatively short document that describes the system your group will build. This document serves two purposes.

1. It allows the course staff to check that what you plan to build is a sensible system and is sufficiently (but not overly) ambitious for a course project. Where there are obvious problems, we will ask questions or make suggestions about how to proceed. If there are severe problems then we may invite you to submit a revised document, which we will also review.

2. It defines what you will be building and establishes the baseline against which your system will be evaluated. If, in the end, you don't deliver a project with your stated functionality then your grade will suffer. However, you will not receive a higher grade for implementing more functionality than is specified in this document.

Your Phase I deliverable should be prepared in Microsoft Word and submitted to CMS as a .doc or .docx. Use 10 point font or larger, "single" line spacing, and at least 1 inch margins. The entire document should be at most 5 pages (single-sided). A document that does not follow these standards will be returned unread to its authors for re-formatting and receive a grade deduction. (Success in life depends, to a surprising degree, on knowing when to follow instructions and then following them.)

Structure your document as follows.

Title: A short descriptive title for your system.

Group: The list of group members. Give the full name and netid for each.

System Description: Give a few paragraphs describing what the system will do (but not how that functionality will be achieved). The "Grade Management System" and "Networked Banking System" sketches given above illustrate the correct tone for a "System Description". But the sketches above are incomplete and would need to be extended with details to serve as a "System Description".

Security Functionality: This should be a bulleted list. Each item in the list should state a security property and explain how the system will enforce that property. For example, in a write-up for the "Networked Banking System" we might find:

• Property: Bank account numbers or information about balances in transit on the network cannot be viewed or changed by wiretappers.
  Enforcement: Each branch has a private key. Messages between bank branches are digitally signed and encrypted using these keys.

• Property: Only the human who has privileges for a bank account can initiate transactions that reveal the balance or cause withdrawals from the bank.
  Enforcement: Human users will be authenticated using 2-factor authentication---a PIN and a USB token. In addition, each bank server implements an authorization mechanism that blocks access to accounts unless the requester is running for an authenticated user with privileges to access that account.

Implementation Target: Explain what programming language will be used, what operating system(s) it will run on, what existing network protocols will be employed, what existing software besides the OS and standard libraries you propose to use, etc.

System Architecture: Briefly describe the software components that will be built, what each does, and how / when they interact. It might be instructive to describe the trajectory of execution in response to an example client request.

Assurance Argument: Explain how you intend to gain assurance that your system works as it should and that your system cannot be successfully attacked. Provide enough details about your testing plans so that we are convinced you have thought about the problem.

The smart way to proceed is to develop a detailed system design before attempting to write your Phase I deliverable. Few, if any, of these details would appear in your Phase I deliverable, but knowing those details increases the chances that what you do describe is something that you can build and that will work. In particular:

• Know what the system components are.

• Know what their interfaces are and what protocols will be used for their interaction.

• Read and understand what types of arguments will be used by the cryptographic library routines used by your components.

We will evaluate your Phase I submission against criteria listed below.

• Whether the document you submit contains the required sections and each section contains the required content.

• Whether the description of functions and features is clear and complete.

• Whether the system needs and involves authentication, authorization, and confidentiality/integrity.

• Whether the security functionality listed is complete and reasonable for the system being built.

• Whether the proposed means of enforcement are sensible.

• Whether a reasonable implementation target been selected.

• Whether the assurance argument is feasible to discharge and is compelling.

In addition, clarity and correct American or British language style and usage counts throughout, just as it does in the real world. So non-native speakers are urged to have somebody critique their prose.

Phase II Deliverables

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 April 26. Use the sign-up sheet posted on the door of Upson 4115 to schedule your meeting.

Preparing for the Presentation/Demo Meeting. The Presentation/Demo meeting encompasses an hour, and it 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 clarity of your presentation counts.

  Slides should contain short telegraphic phrases, figures, algorithms (in an easily understood pseudocode), and (where appropriate) performance numbers. Use the Powerpoint "speakers notes" feature to amplify what appears on a slide, so the course staff can review this when later deciding on a grade for your effort. 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" are 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 your project, (iii) describe the detailed design of your system, (iv) explain why your design is a good one (but include short-comings and trade-offs), and (v) explain why we should believe that your system is secure (i.e., what testing you did and any other support for an assurance argument). Hint: Structure your talk as 5 sections that parallel the 5 topics.

• 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 all manner of code vulnerabilities. But be candid about what works and doesn't work---the grade penalty is significant if we discover problems that you didn't warn us about.

• 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) copies of your powerpoint 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 II. Your grade for Phase II will be calculated 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%]
• does your implementation satisfy the functionality specified at Phase I [15%]
• other subjective factors about project goals, implementation, and presentation [15%]