Secure Systems
Engineering, Spring 2024
Root the (Ballot) Box
- Out on: Tue Mar 5
- Key dates:
- Code due: Mon Apr 15, 10p EDT
- Demo day: Tue May 7, in class
- Presentation slides due: Mon May 13, 10p EDT
- Presentation day: Tue May 14, in class
- Check-ins due: as a part of in-class activities,
see course schedule
- Collaboration: groups of 4
- Grading:
- Code & demo: 15% of final grade, out of 100
points
- Presentation: 10% of final grade, out of 100
points
Please read this description in its entirety before starting
the project!
The goal will be to utilize your knowledge from the course to write a
voting machine in Rust and embed backdoors inside of it that would allow
a knowledgeable attacker to cheat in the election. Then, you will be
given another team’s voting machine to attack, attempting to find all of
the vulnerabilities (intentional or not) in their system. Finally, your
group will present on both your own machine and your experience
attacking the other group’s machine.
Part 1: The voting machine
You will start by writing code for a voting machine. The voting
system must have the following features:
- Be able to compile and run inside the class VM
- If this requires installing external dependencies, include those in
a folder with your project so other teams can easily run your code
- If you need a database, use SQLite for ease of
installation
- This is a hard requirement
- If your code does not compile in the class VM, you will not receive
points!
- A process for an election official to perform the following
functionality:
- Authenticate to an administrator interface
- Regular voters should not be able to access the below functions
- Create a new election ballot
- Ballots should support elections for at least 3 offices
- For example: president, representative, judge, school board,
etc.
- These do not have to be government positions – feel free to get
wacky with them!
- Each office should have multiple candidates
- Each candidate should have the following information: Name,
Political Party
- The election official should input this information for each
candidate added to the ballot for an office
- Register a new voter for the election
- The machine should record the following information about a user:
Name, Date of Birth
- Open an election for voting
- Close an election to prevent further votes
- Tally the votes for a closed election
- A process for a registered voter to cast a ballot in an
open election
- The machine should first check if the voter is registered
- Unregistered voters should not be able to vote in the election
- The machine should then display the ballot, and allow the user to
make selections for each office
- Once the user makes their selections, the user should be able to
cast their ballot for tallying
- Note that a legitimate voting system allows only one casted ballot
per user
The “machine” is not a physical device; we expect your group to
create a Rust software package that provides the above functionality at
minimum. We suggest that the “machine” be a command-line application,
but you may also write a web front-end. Cite any sources you used if you
find code elsewhere to include in your machine.
Note that we require the machine to be written
mostly in Rust. You may, however, include other
programming languages (e.g., C) as sub-components. Also, you can use
whatever Rust libraries you would like to aid your implementation.
We encourage you to be creative, and add additional features!
Building in vulnerabilities
After your group finalizes the voting machine code, the second phase
will be to (covertly) add in vulnerabilities as backdoors to the code.
These backdoors should clearly compromise the integrity of the voting
machine. Remember that the goal of this project is to change the
outcome of the election, not just “break” the application. This
does not just mean changing vote totals – there are many ways to
compromise an election, so be creative!
We expect at least two backdoors explicitly coded
into the voting machine. We encourage you to be creative in this as
well. These should be surreptitious – a regular user should not
be able to accidentally find them! Also note that someone analyzing the
source code should not be able to easily find them either.
What to turn in
Building the voting machines is half of the project. Submit the
following the Blackboard before the code submission due date:
- A
gzip
ped file with…
- All of your source code and installation instructions for
your machine.
- Make sure there are no comments explaining your
vulnerabilities!
- A user manual for an unsuspecting user to use the voting machine
correctly
- Note that this should not include any information on your
backdoors!
Part 2: The red team
For this part of the project, you will be given one
gzip
ped distribution of source code and a user manual for
another group’s voting machine. Your team’s goal is to perform a
security analysis of the voting machine. You will try to find all of the
vulnerabilities that the other team put into their bad voting machine,
plus any other unintentional vulnerabilities. This part is open ended –
be creative in your analyses, and try to find different ways of
dissecting the codebase to find vulnerabilities and backdoors.
The project will culminate in a group presentation in front of the
rest of the class. First, you will describe your voting machines and the
backdoors and vulnerabilities that you inserted. Focus more on the
interesting aspects of your machine: any additional features you added
to the machine over the above requirements, as well as the location and
purpose of your backdoors. Then, you will describe the voting machines
you were assigned to analyze and you will explain what your red team
analysis uncovered. The presentation should cover all of the
analyses you did, even those that did not detect any vulnerabilities or
backdoors. Demos of both systems would be useful, but keep an eye on
your time.
In your presentation, provide a more in-depth exploration of the
backdoors you found. For a found vulnerability to be a
backdoor, you must prove that it will lead to a change in the
outcome of the election. You may discuss any vulnerabilities
that are not true backdoors, but be clear about their impact to the
voting machine.
The presentation should be 12 minutes long. If you
do not have enough to talk about for 12 minutes, then you need to do
more analysis! Each group member should speak for an equal
amount of time (approximately). There may be questions from the audience
afterwards, so be prepared!
What to turn in
Submit the following to Blackboard before the slides submission
date:
- Your final presentation slide deck
- This should be a PDF file, PPTX file, Keynote file, or Google Slides
link
- No modifications are allowed between the submitted version
and the presented version!
Grading
The project will be graded according to the following rubrics.
Please reach out to the instructor if you require any
clarifications on the above requirements or below rubrics.
Code & demo
On the demo day, your group will meet with the instructor to discuss
and demonstrate your (backdoored) voting machine. The
demo will be structured around the following criteria:
- Voting machine completeness (30 points). The
instructor will guide your group through a series of tests designed to
check if your code has the required minimum voting machine functionality
described above. The instructor will also ensure that your code is
mostly written in Rust.
- Voting machine correctness (15 points). The
instructor will stress-test your implementation to see if it performs
incorrect behavior accidentally (e.g., allowing an unregistered voter to
cast a ballot, crashing on unexpected input). You will not be penalized
for your intentional backdoors, of course.
- Voting machine design (5 points). While this is not
a programming course, the instructor will look through the voting
machine code to ensure that it is organized
reasonably well. You may be required to defend your design
decisions.
- Backdoor correctness (20 points). The instructor
will ask to see the backdoors in action. Your group must clearly show –
explaining each step – how a user with access to the voting machine
application can subvert the election using each of your backdoors.
- Backdoor design (20 points). The instructor will
ask your group questions to assess the quality of your backdoors and the
cleverness of your inserted vulnerabilities. It important that the
backdoors are covert enough such that regular users (both voters and
election officials) cannot find them, while knowledgeable ones can. Hide
them well!
- Supporting documents (10 points). The instructor
will install your voting machine from scratch following your submitted
installation manual. The instructor will also check the completeness of
your user manual.
Your total score on the demo, out of 100 points, will form
15% of your final grade in the course.
Presentation
Presentations will occur in class on the presentation day. After each
presentation, the group whose voting machine was red teamed in the
previous presentation will go next. You must attend the entire
presentation day to receive credit for your presentation.
Please remain engaged with the presentations even after yours is
complete. To assist with this, no electronics will be allowed
during presentations.
The presentation will be graded as follows:
- Voting machine discussion (10 points). Your
presentation should include a brief discussion on your voting machine’s
design and features, from the perspective of how legitimate users would
interact with your system.
- Backdoor discussion (20 points). Your presentation
should detail the backdoors you included in your voting machine, such as
where you hid them, how to exploit them, and what they do to compromise
the result of the election.
- Red team voting machine analysis (20 points). Your
presentation should describe the voting machine you received for
analysis. This should focus on its code architecture (rather than its
functionality). Make sure to highlight what techniques you used to
analyze the machine.
- Red team vulnerability discussion (20 points). Your
presentation should identify the vulnerabilities you found as a result
of your analysis. The presentation should emphasize those
vulnerabilities that are potential backdoors, and what impact those
backdoors could have.
- Red team backdoor exploitation (10 points). Your
presentation should prove that the backdoors you found indeed changes
the outcome of the election. This can take the form of a series of
screenshots that go through the process step-by-step, a recorded video
demo, or a live demo.
- Presentation quality (20 points). The instructor
will assess the effort you put into your presentation. Make sure you
spend some time polishing your slides and practicing your presentation
parts. A rule of thumb: if you are bored giving your
presentation, you are boring your audience!
Your total score on the presentation, out of 100 points, will form
10% of your final grade in the course.
Check-ins
At various milestones in the project, the instructor will assign
small check-in activities in class. These check-ins are designed to see
if your group is on-track to complete the project on time. There will be
4 check-ins, accompanied by in-class work time for your group:
- Voting machine design and implementation
- Backdoors in your voting machine
- Demo practice
- Red team analysis
These check-ins are graded only for completion, and in total
will form 5% of your final grade in the course. If you
are struggling during the check-ins, make sure to reach out for
help!
Attribution
The original version of this project was developed for the course
Security & Privacy in Computing at Johns Hopkins University. More
information can be found in “Root the (Ballot) Box: Designing Security
Engineering Courses with E-Voting”, a poster published in the
proceedings of the ACM
Technical Symposium on Computer Science Education 2024 (SIGCSE
’24).