Technical Information about the SRC Elections

The electoral system itself

A completely new electoral system was developed for the 2009 SRC elections under the auspices of the Information Technology Division, and is being used for these elections. This system is characterised by unprecedented levels of openness and transparency – the entire electoral system has been released publicly to the University community under an open source license. This means that you are able to, and in fact encouraged to, download your own copy of the electoral system, vet the source code in any way you see fit, and satisfy yourself that the electoral system is above board.

SHA1, SHA256 & MD5 checksums of the electoral system code used for this election are created during the pre-election procedures and are made available to you. This allows you to verify that the released version of the code is indeed what's running these elections. The only file you don’t get a copy of is config.yaml, as this contains sensitive information that could compromise the integrity of the election (a sample with the confidential information redacted is provided instead).

Being open source software, we also encourage community participation. If you happen to notice any bugs, or have ideas about how to improve the system for future elections, please feel free to let us have your constructive contributions.

The elections server

Of course an open electoral system is only as good as the computer on which it runs. In the past, the SRC elections have run on the University’s main web server and have therefore been subject to the constraints imposed by a production system shared with other applications. This time around, the elections system (elections.ru.ac.za) is running on a dedicated virtual machine as part of the University’s new high-availability VMware virtual infrastructure. Nothing else runs on the elections server, which means that it can be tailored specifically to the information security needs of an online election.

The entire electoral system runs under open source software (Apache & Perl) on an off-the-shelf open source operating system (FreeBSD). No attempt has been made to compile any software on this server, and only freely available (and thus verifiable) binary packages were used during its installation. During the pre-election procedures, critical components of the operating system were verified against the original installation media thus providing you with the peace of mind that the entire operating system has been vetted by tens of thousands of people worldwide.

Extensive use is made of the underlying operating system’s security features to help ensure that the system isn’t tampered with during an election. In brief, these ensure that the electoral system cannot be altered without rebooting the entire elections server – a remotely auditable event. You can even monitor this yourself: the simplest (and least accurate) way do this is to make sure that the electoral system is available on the network at all times during a running election; a better way is to use SNMPv1 and the public community to check sysUptimeInstance, something like this:

   user@example:~$ snmpwalk -Os -v1 -c public elections.ru.ac.za sysUptime
   sysUpTimeInstance = Timeticks: (2713884) 7:32:18.84

All network communications between the electoral system and a voter’s web browser are secured by the secure sockets layer (SSL). This is the same end-to-end security that is used by, for example, banks and credit card companies to secure online transactions. The SSL certificate used by the elections system is signed by Digicert, a reputable international certificate authority.

In normal operation, the server running the elections is well protected by a local firewall that defaults to denying incoming connections and only allows specific, known services to be accessible from the network. No password-based remote shell logins are permitted; all remote shell access is authenticated via public/private keys. The physical machine hosting the elections system is housed in one of the University's two datacentres, all of which have physical access control, full environmental monitoring, and redundant power & network. During the elections themselves, all non-essential remote access to the machine, including remote logins, is intentionally disabled. In the event of an emergency, console access is available to just four people – the systems & operations staff in the Information Technology Division, all of whom are bound by a professional code of ethics. All logins are audited.

Elections procedures & processes

Software is, however, only part of the story. Equally critical are the procedures and processes that surround the election. These are designed to provide checks and balances for the human component of the elections, and to ensure that the entire electoral process, from start to end, is above board, transparent, and properly audited. The checks are designed to balance the need for comprehensive controls against the time constraints and technical abilities of those involved, and we welcome suggestions for their improvement.

Before any election starts, a detailed pre-election checklist is followed in the presence of a number of observers. Each of these observers is then asked to sign a declaration confirming that the procedure was correctly followed. As part of this process, the parameters of the election are verified. In addition, a number of cryptographic intrusion detection signatures are taken of critical parts of the system. These are available to you, and you are welcome to verify them against your own copies of the electoral system.

In the unlikely event of emergency changes being made to a running election, a strict set of checks and balances ensures that these changes are properly considered, well understood and documented. The processes around this ensure that the security and accountability of the electoral system is preserved in spite of the need to make changes.

During the elections, detailed audit logs are kept of all vote-related transactions. These are separated from the live electoral data and are strictly append-only (i.e. they cannot be changed on the secured system). Whilst these logs do not allow for the identification of individual voters (votes should, after all, be anonymous), they should provide an (albeit somewhat tedious) out-of-band way to recount votes and reproduce the electoral results from raw data in the event of any dispute.

At the end of the election, a detailed post-election checklist is followed in the presence of the same set of observers. Each observer is once again asked to sign a declaration confirming that the procedure was correctly followed. As part of this process, the entire electoral system is checked against the values computed at the beginning of the election to ensure that no tampering has taken place during the election.

Whilst the system is still secured, an electronic copy of all the electoral data is made and cryptographic signatures are calculated. The signatures are recorded in the post-election declaration, and allow this data to be verified again in future. It is intended that this electronic copy be kept along with the results for at least one year (i.e. until the next election), so as to provide a way for the elections to be scrutinised in future.

Only once all of these procedures and processes have been correctly followed are the final election results declared and announce.

Technical Information about the SRC Elections

The electoral system itself

The elections server

Elections procedures & processes

Related Documents & Source Code

Standard Templates

2011

2010

2009