Course project
--------------

Earlier this year, the US Election Assistance Commission (EAC) put out a set of Voluntary
Voting System Guidelines (VVSG), available on the web at http://www.eac.gov/ in pdf and
html format. The guidelines spell out many requirements for voting systems. Section 4 is
about software requirements: http://guidelines.kennesaw.edu/vvsg/vg1/v1s4.htm. This document
falls short of any kind of software requirements that can actually lead to real security.
This semester, the class will collectively attempt to design and specify the software requirements
so that they provide more security.

The goal is to specify rules on program structure and program style that will make it easier
to audit the software for malicious code and more difficult to hide Trojan horses in the code.
The class will attempt to answer the question of whether or not it is feasible to even reduce
the likelihood of malicious code with such restrictions.

The class will divide into teams of 3 or 4 students. The project is split into several tasks
that will be performed by each team.


Task 1
------

Literature Search

Each team will perform a literature search looking for papers that are relevant to 
controlling programming style and structure for security purposes. In addition, every
student in the class must read the Caltech/MIT report and the California report:
http://www.cs.jhu.edu/~rubin/courses/sp03/papers/caltech.mit.pdf
http://www.cs.jhu.edu/~rubin/courses/sp03/papers/california.report.pdf

Deliverable #1:
Due: October 6
Turn in a 5 page report describing the current state of the art in controlling
programming enviornments for security purposes. Cite all the references you found,
and identify the 5 best papers. (bibliography is not part of the 5 pages)

Presentation: On Thursday, October 6, one member from each team will present 
the most interesting research results and will cover all of the material 
in the most important papers found. After each team presents, one member from
each team will lead a class discussion on the previous literature,
what is wrong with the papers, what is missing, and what could still be done. 
If necessary, the discussion will roll over to the next lecture, although I will
be away at a NIST e-voting workshop. The discussion leaders will be expected to have the 
class discussion organized so that there is plenty to talk about. 


Task 2
------

Designing new requirements.

Each team will produce their own set of VVSG guidelines for programming towards secure
audit. This should be done both for JAVA and C. The specifications should be written so that
an outside anlaysis firm could evaluate a program with respect to the guidelines and rate its
conformance. Automated analysis of conformance is a plus but not a requirement. The 
guidelines should include a rationale for each requirement ("Why does this help?"), 
which the current VVSG omits in most cases.

Deliverable #2:
Due: November 3
Turn in a write-up of the team's VVSG guidelines and example code for each guideline in
each language (JAVA & C) that meets and that violates the rules to demonstrate exactly 
what they mean and how they work. Also, turn in a 2-3 page write-up justifying the 
approach taken by the team.

Presentation: On Thursday, November 3, and Friday, November 4, each team will present
their guidelines and their sample code to the class, followed by a discussion.


Task 3
------

The challenge

Each team will be assigned one of the other team's VVSG guidelines. The goal of the team is
to produce a program with hidden, malicious code that conforms to those guidelines. In other
words, each team is assigned the tast of demonstrating the weaknesses in the other team's
guidelines, and in a sense "breaking" their scheme.

Deliverable #3
Due: December 8
Turn in a report detailing the weaknesses in the VVSG guidelines from the other team. Demonstrate
a program that conforms to the VVSG but still has malicious content.

Presentation: On Thursday, December 8, and Friday, December 9, each team will present to the
class. Demo your program and show how it is malicious, and then explain how it meets the VVSG
guidelines. Then provide a critique of the VVSG guidelines. Finally, defend your own VVSG guidelines
and show why your program is not susceptible to the same attack.