Case Study

Digg This!

From the start it seemed obvious. In building an electronic voting system (known to the industry as a DRE, or Direct Recording Electronic), you must follow four key principles:

1. Do not change the social contract with the voter.
2. Design it as a voting appliance, not a voting computer system.
3. Ensure that the system is secure, reliable, and tamper resistant.
4. Keep it flexible yet simple.

The Social Contract with the Voter

This is the founding design principle of the AccuPoll voting system. What we mean by "the social contract with the voter" is the notion that the system should record the intent of the voter, provide the voter with a confirmation that it has correctly recorded his or her intent, and allow that confirmation to be used as an audit trail in the event there is an issue with the electronic results. By doing this you get the benefit of electronic voting (i.e., immediate results, multilingual support, support for voters who are blind or otherwise challenged to vote in privacy) with the benefit of the long-standing practice of having an independent voter-verified audit trail of every vote cast. This meant that the only practical solution was a voting machine that can print a paper record as part of each voter's voting experience. The record is verified by the voter and, if correct, deposited in a ballot box before the voter leaves the polling place. If it's not correct, the voter has a chance to spoil the paper record and any accompanying electronic records and revote.

What this means from a system perspective is that any implementation of the in-precinct voting system must have printing capability, networking between the voting stations, an administrative console that is used to administer the election, and redundancy to allow the reprinting of paper records in the event that equipment on one voting station fails. For reasons of security, flexibility, and cost, Linux was the obvious choice as the implementation platform to help fulfill the contract with the voter.

The Voting Appliance

To build a reliable and trusted voting appliance using COTS hardware and open source system software you need a reliable, trusted, predictable, and secure operating environment. The design called for the voting machine to be an appliance, not a computing system. This meant self-discovery of services and of available peers, startup that is as simple as flipping a switch, and shutdown that is as complex as pulling the plug. To achieve this goal, the AccuPoll voting application runs within a carefully configured Red Hat distribution, on top of a partitioned ReiserFS file system.

All unnecessary services are disabled and startup is tuned to occur as quickly as possible. Reiser was chosen over ext3 for journaling because the journalled ext3 system would not last for more than a few days of abrupt shutdowns. This is critical from an appliance perspective because election workers should not be expected to follow a more complex shutdown procedure all the time.

Data loss was also a primary concern for our design. Thus, all election results are stored in a transactional database and are mirrored to flash on each voting station. To further guarantee system integrity, the system disk is partitioned into a set of system and application-specific partitions, thereby limiting the impact of incomplete writes across power failures and ensuring that application misbehavior does not prevent the system from booting. With these design choices we have been able to minimize the administrative burden of a complex voting application, that is, for all practical purposes running in a nontrivial distributed computing environment.

Security, Reliability, and Tamper Resistance

Perhaps the most important topic aside from the verifiability of elections is the security and, by inference, the accuracy of the voting systems. Security implies everything from the hardware to the software. By using Linux and COTS hardware, the AccuPoll system strikes a practical balance that provides a secure voting system (data is stored in a relational database with real access rights and not a simple flat file in an unprotected file system), with reasonable measures to prevent and, at a minimum, detect tampering. The system is configured to have no login consoles, with password-protected bios and grub boot sequences. The voting system does not run as root, thus the "root" user cannot log in. All events in the system are logged. All nonessential services are disabled and the in-kernel firewall is used to prevent unauthorized port access.

At the application layer we use Java as the implementation language of choice. By choosing Java we obtain all the benefits of its secure and sandboxed execution environment together with its support for cryptography and code verifiability. We therefore ensure that we run only signed executables that have been verified. The built-in cryptography support along with that of PGP allows us to produce election CDs and election result CDs that are verifiably correct, unchanged, and come from the correct source.

Flexible and Simple

As some would say, "In the United States there are 50 states and 50 different ways to run elections." While that's not completely true, election systems are clearly nonuniform from state to state. There are some very fine nuances that ensure you must build flexibility into the system. We use XML to provide the maximum flexibility with the least number of code changes. XML is used in two very different ways. The first is the XML behavior specification that is used to provide the presentation layer that the voter sees. This specification defines the look and feel of the interface, the actions on button press, and all aspects of the voting experience. The second XML specification defines all aspects of an election (i.e., candidate names and contests as well as the mapping of contests to precincts and polling places). By adopting this design, the AccuPoll system now supports election law in all 50 states and is able to make even significant interface changes with minimal impact on the underlying code base.

Why Linux Is the Right Solution

From the outset Linux was the obvious platform choice. It has the flexibility to disable all nonessential services and a firewall on each device to ensure only critically needed ports are open. It provides out-of-the-box networked printing, if needed. It has full Java support with predictable behavior and performance (in an unrelated project we experienced much different behavior and performance profiles when a Java application was run under different releases of Windows). Finally, as an optimization step we saw the possibility to migrate to an embedded Linux solution at some point in the future. This will further reduce costs and allow us to run the system on a smaller hardware footprint. Finally (as is sadly still the case), when we first designed the system, the Windows environment was rife with various attacks. We determined that the risk of deploying a Windows solution with all its clear vulnerabilities was greater than deploying a Linux solution with some unknowns. Two years later we are happy to report that we made the right choice.