Project Overview

CS 5431 students are expected to participate in a group project to build a software system that has non-trivial security functionality. A high-level introduction to the project is given in this overview. More details will be supplied throughout the semester as part of each project milestone. The milestone delivery schedule is given on the course homepage.

Essential Security Elements

You have considerable flexibility in choosing what system to build. But because the course project is intended to provide an opportunity for you to exercise the material covered in CS 5430 and CS 5431, projects are acceptable only if the following "gold standard" security 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. Clients may include human users as well as programs executing on machines. You must implement reasonable means of authentication, which may include passwords, user registration, generation of secrets, distribution of keys, etc.
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 for your system's functionality and expected scale.
Audit. The system must provide infrastructure for audit or other means of establishing accountability for actions. The security of that infrastructure must itself be ensured.

Projects must also intrinsically require information security:

Confidentiality and Integrity. The system must involve information that resides in long-term storage or that is transmitted over a network. The system's mission must require that information to be kept secret and/or be protected from corruption.

The list of essential security elements above defines only a subset of the security functionality your project will implement. What is the rest of that functionality? Answering that question will be the primary task of Milestone 1.

System Ideas

Here are sketches for a few example systems that could involve all of the above essential elements. Each sketch has important elements missing, as befits a sketch. Nevertheless, 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 course staff, which may include TAs and professors, and to be retrieved by students. Grade information is stored in a back-end file system.
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.
Secure Anonymous Communication. This system enables users to communicate with each other secretly, accurately, and anonymously. Users can specify what information other users may learn about them and their communications.
Electronic Voting System. This system enables users to privately express their preferences about some issue. The system produces a verifiably correct aggregate of all the users' preferences.

Implementation

You must use Java to implement your system. Java prevents buffer overflows and other vulnerabilities, and we will be using source-code analysis tools and security libraries that work only with Java.

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 third-party systems and tools available for building web services. But using these tools in CS 5431 would preclude activities the project is supposed to cover. This is because, when you use a third-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:

Java's standard libraries (i.e., those part of the distribution) may be used. This includes various cryptographic routines, which you shouldn't be writing yourself anyway.
GUI builders that are part of, or plug into, Eclipse or NetBeans may be used.
Operating systems installed on the CS department lab machines may be used. This includes the networking infrastructures and file systems native to those operating systems.
Database management systems that function as local, library-level services may be used. This includes the Java interfaces to Berkeley DB and SQLite. However, databases that run as separate servers and are accessed over the network may not be used.
Existing web browsers, web servers, or any other web services infrastructure may not be used. These technologies make too many security decisions for you.

Of course, the above rules are incomplete, and in some cases it may make sense to incorporate other third-party code into your project. To do this, (i) you must have the instructor's prior approval, (ii) the license of that code must be amenable, and (iii) your project documents and presentations must clearly acknowledge the source of that code.

Distribution

Your system should be designed for public distribution. You will create a website for your system as part of a later milestone, and a link to that website will be posted on the CS 5431 course website. You will also give a public demo of your system as part of the final milestone presentation. Our hope is that you will take the project as an opportunity to seriously impress your peers and future employers.

Groups

Part of the purpose of this course is to give you experience in building software, including engineering its security, as a member of a development team. Why? Because...

Working in a group offers you the powerful tool of discussing ideas with others.
Working in a group affords the opportunity for parallel development activities and specialized expertise.
Working in a group helps hone skills needed to be effective in the workplace (where groups are the norm) and impresses potential employers.

All members of your group are ultimately responsible for understanding all security aspects of the system you build.

Group size. Your group must start with four to six members. If through attrition your group size becomes too small, personnel may be re-assigned by "Management" (i.e., the instructor) from another group to yours to ensure that you have the resources you need to complete your project.

Peer reviews. As part of your final milestone, you will submit peer reviews of all the members of your group. These will help the course staff to fairly assess the contribution of each team member to the group.

Grading

Your project grade will be computed as follows:

20%	Presentations
30%	Documents
50%	Completed project

The following grading criteria will be employed:

All presentations are assigned a pass-fail grade, with the same grade being given to all of the members of the group. You will pass if you have a working prototype that demonstrates adequate progress since the last milestone, and if you present that prototype coherently.
All documents are assigned a letter grade, with the same grade being given to all of the members of the group. If a document seems to be taking your project in the wrong direction, we may invite you to resubmit it with substantial improvements.
The completed project is assigned a letter grade, with each group member receiving their own (possibly different) grade. That grade will be determined in part by the quality of your completed project, your peer reviews, and your individual ability to answer questions about the security aspects of your project during presentations. This grade will also be influenced by the originality, difficulty, and non-artificiality of your project.

In an open-ended project, things don't always work out as planned and you have to back up or start over. This grading scheme is designed to encourage you to keep working without penalizing you for "going back to the drawing board."